Processing commands for cont...@bugs.debian.org:
> # Jonathan Nieder wrote:
> #
> # > reassign -1 xserver-xorg-video-ati 1:6.1.14.1-1
> #
> # Typo. Sorry for the noise.
> notfound 626500 1:6.1.14.1-1
Bug #626500 [xserver-xorg-video-ati] xserver-xorg-video-ati: package
description does not mentio
Processing commands for cont...@bugs.debian.org:
> reassign 625521 xserver-xorg-video-fbdev 1:0.4.2-4
Bug #625521 [xserver-xorg-core] causes segfault in Xorg
Bug reassigned from package 'xserver-xorg-core' to 'xserver-xorg-video-fbdev'.
Bug No longer marked as found in versions xorg-server/2:1.10.
reassign 625521 xserver-xorg-video-fbdev 1:0.4.2-4
severity 625521 important
retitle 625521 Xorg: crash in shadowUpdatePacked (fbdev trusts virtual size >
video memory?)
tags 625521 + upstream
forwarded 625521 https://bugs.freedesktop.org/show_bug.cgi?id=37159
quit
Steve M. Robbins wrote:
> Yes,
On Thu, May 12, 2011 at 07:49:26AM -0500, Jonathan Nieder wrote:
> > I did try to downgrade, but I'm not sure I succeeded. Do you want me
> > to try again?
So I did try again with libc 2.11.2-11 and the bug remains: fbdev
crashes.
> The other loose thread I'm curious about is what triggered t
Processing commands for cont...@bugs.debian.org:
> clone 625521 -1
Bug#625521: causes segfault in Xorg
Bug 625521 cloned as bug 626500.
> reassign -1 xserver-xorg-video-ati 1:6.1.14.1-1
Bug #626500 [xserver-xorg-core] causes segfault in Xorg
Bug reassigned from package 'xserver-xorg-core' to 'xse
clone 625521 -1
reassign -1 xserver-xorg-video-ati 1:6.1.14.1-1
# documentation
severity -1 minor
retitle -1 xserver-xorg-video-ati: package description does not mention it is
needed for autoconfiguration
tags -1 + patch
quit
Hi Steve,
Steve M. Robbins wrote:
> I did try to downgrade, but I'm n
On Fri, May 06, 2011 at 03:46:35AM -0500, Jonathan Nieder wrote:
> Michel Dänzer wrote:
>
> > [ Dropping the libc6 list from CC, as this doesn't seem to have anything
> > to do with libc6 after all ]
>
> Yes, sorry for the misdirection.
>
> Actually I have a question in mind still. The origina
On Fri, May 06, 2011 at 10:30:01AM +0200, Michel Dänzer wrote:
> So, where does that leave this report? I still suspect the bug is that
> the fbdev driver doesn't properly handle the virtual directive in
> SubSection "Display", but before reassigning to xserver-xorg-video-fbdev
> (and most likely
Michel Dänzer wrote:
> [ Dropping the libc6 list from CC, as this doesn't seem to have anything
> to do with libc6 after all ]
Yes, sorry for the misdirection.
Actually I have a question in mind still. The original report pinned
it on libc6 confidently, and I didn't think to question that (sha
[ Dropping the libc6 list from CC, as this doesn't seem to have anything
to do with libc6 after all ]
On Don, 2011-05-05 at 23:14 -0500, Steve M. Robbins wrote:
> On Thu, May 05, 2011 at 09:33:45AM +0200, Michel Dänzer wrote:
> > On Mit, 2011-05-04 at 23:41 -0500, Steve M. Robbins wrote:
> > > O
On Thu, May 05, 2011 at 09:33:45AM +0200, Michel Dänzer wrote:
> On Mit, 2011-05-04 at 23:41 -0500, Steve M. Robbins wrote:
> > On Wed, May 04, 2011 at 10:08:47AM +0200, Michel Dänzer wrote:
> >
> > > Steve, can you provide the output of fbset -i and the
> > > "/etc/X11/xorg.conf file as well? An
On Thu, May 05, 2011 at 09:56:03AM +0200, sean finney wrote:
> Maybe valgrind already does checks like this [...]
It does.
--
·O· Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org
--
T
Hi,
On Wed, May 04, 2011 at 10:56:27PM -0500, Steve M. Robbins wrote:
> > And furthermore, even if Debian chooses to "fix" this, upstreams will
> > be forced to eventually cater to the default glibc behavior for every
> > other libc distro out there that does not have their own "fix" (and
> > non-
On Mit, 2011-05-04 at 23:41 -0500, Steve M. Robbins wrote:
> On Wed, May 04, 2011 at 10:08:47AM +0200, Michel Dänzer wrote:
>
> > Steve, can you provide the output of fbset -i and the
> > "/etc/X11/xorg.conf file as well? Any reason for not using the radeon
> > driver?
>
> I don't know why the r
On Wed, May 04, 2011 at 02:18:35AM -0500, Jonathan Nieder wrote:
> Thanks, Michel. Steve, could you install xserver-xorg-video-radeon-dbg
> and get a full backtrace (bt full), or even better, run xorg under
> valgrind and see what it says?
OK, I ran valgrind Xorg; note that valgrind was not exit
On Wed, May 04, 2011 at 09:29:53AM +0200, Michel Dänzer wrote:
> On Mit, 2011-05-04 at 02:18 -0500, Jonathan Nieder wrote:
> > Thanks, Michel. Steve, could you install xserver-xorg-video-radeon-dbg
> > [...]
>
> More importantly xserver-xorg-core-dbg, to get debugging symbols
> for /usr/lib/xo
On Wed, May 04, 2011 at 10:08:47AM +0200, Michel Dänzer wrote:
> Steve, can you provide the output of fbset -i and the
> "/etc/X11/xorg.conf file as well? Any reason for not using the radeon
> driver?
I don't know why the radeon driver is not in use. I have two monitors
(1600x1200 and 1920x1200)
On Wed, May 04, 2011 at 01:34:15PM +0200, sean finney wrote:
> And furthermore, even if Debian chooses to "fix" this, upstreams will
> be forced to eventually cater to the default glibc behavior for every
> other libc distro out there that does not have their own "fix" (and
> non-libc OS's where t
On Wed, May 04, 2011 at 12:29:50PM +0200, Julien BLACHE wrote:
> "Steve M. Robbins" wrote:
>
> Hi,
>
> > I'm with Linus on this: let's just revert to the old behaviour. A
> > tiny amount of clock cycles saved isn't worth the instability.
>
> Tiny amount?! The optimized memcpy() variants that b
On Wed, May 04, 2011 at 12:29:50PM +0200, Julien BLACHE wrote:
> "Steve M. Robbins" wrote:
>
> Hi,
>
> > I'm with Linus on this: let's just revert to the old behaviour. A
> > tiny amount of clock cycles saved isn't worth the instability.
>
> Tiny amount?! The optimized memcpy() variants that b
Le 04/05/2011 09:05, Jonathan Nieder a écrit :
> Aurelien Jarno wrote:
>> Le 04/05/2011 07:43, Jonathan Nieder a écrit :
>>> Jonathan Nieder wrote:
>
Sounds like http://sourceware.org/bugzilla/show_bug.cgi?id=12518
which is fixed (sort of) by commit 0354e355 (2011-04-01).
>>
>> Are you s
"Steve M. Robbins" wrote:
Hi,
> I'm with Linus on this: let's just revert to the old behaviour. A
> tiny amount of clock cycles saved isn't worth the instability.
Tiny amount?! The optimized memcpy() variants that break shitty code
bring a 4 to 5x speedup on the processors they've been written
Michel Dänzer (04/05/2011):
> Those are just callback pointers passed to shadowAdd(). The driver
> doesn't call shadowUpdatePacked() directly (in fact you'll note the
> backtrace doesn't have any frames belonging to the driver), but the
> shadow layer is only used as set up by the driver.
Alright
On Mit, 2011-05-04 at 11:08 +0200, Cyril Brulebois wrote:
> Michel Dänzer (04/05/2011):
> > More importantly xserver-xorg-core-dbg, to get debugging symbols
> > for /usr/lib/xorg/modules/libshadow.so .
>
> If fbdev is indeed used (see Michel's other mail about that),
> rebuilding it with debuggi
Michel Dänzer (04/05/2011):
> More importantly xserver-xorg-core-dbg, to get debugging symbols
> for /usr/lib/xorg/modules/libshadow.so .
If fbdev is indeed used (see Michel's other mail about that),
rebuilding it with debugging symbols would be nice.
AFAICT from a quick grep, the entry point to
On Mit, 2011-05-04 at 02:18 -0500, Jonathan Nieder wrote:
>
> Michel Dänzer wrote:
> > On Mit, 2011-05-04 at 00:10 -0500, Jonathan Nieder wrote:
> >> Steve M. Robbins wrote:
>
> >>> Program received signal SIGSEGV, Segmentation fault.
> >>> __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcp
On Mit, 2011-05-04 at 02:18 -0500, Jonathan Nieder wrote:
>
> Michel Dänzer wrote:
> > On Mit, 2011-05-04 at 00:10 -0500, Jonathan Nieder wrote:
> >> Steve M. Robbins wrote:
>
> >>> Program received signal SIGSEGV, Segmentation fault.
> >>> __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcp
Hi,
Michel Dänzer wrote:
> On Mit, 2011-05-04 at 00:10 -0500, Jonathan Nieder wrote:
>> Steve M. Robbins wrote:
>>> Program received signal SIGSEGV, Segmentation fault.
>>> __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:153
>>> 153 ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:
On Mit, 2011-05-04 at 00:10 -0500, Jonathan Nieder wrote:
>
> Steve M. Robbins wrote:
>
> > Xorg now segfaults, with the following in the Xorg.0.log:
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:153
> > 153 .
Aurelien Jarno wrote:
> Le 04/05/2011 07:43, Jonathan Nieder a écrit :
>> Jonathan Nieder wrote:
>>> Sounds like http://sourceware.org/bugzilla/show_bug.cgi?id=12518
>>> which is fixed (sort of) by commit 0354e355 (2011-04-01).
>
> Are you sure this is related? I find strange a recent version of x
Le 04/05/2011 07:43, Jonathan Nieder a écrit :
> clone 625521 -1
> severity 625521 grave
> severity -1 important
> reassign -1 libc6 2.13-0exp1
> retitle -1 glibc: memcpy copies down on amd64
> tags -1 upstream patch fixed-upstream
> # sorry for the noise
> quit
>
> Jonathan Nieder wrote:
>
>> So
Processing commands for cont...@bugs.debian.org:
> clone 625521 -1
Bug#625521: causes segfault in Xorg
Bug 625521 cloned as bug 625522.
> severity 625521 grave
Bug #625521 [xserver-xorg-core] causes segfault in Xorg
Severity set to 'grave' from 'critical'
> severity -1 important
Bug #625522 [xse
clone 625521 -1
severity 625521 grave
severity -1 important
reassign -1 libc6 2.13-0exp1
retitle -1 glibc: memcpy copies down on amd64
tags -1 upstream patch fixed-upstream
# sorry for the noise
quit
Jonathan Nieder wrote:
> Sounds like http://sourceware.org/bugzilla/show_bug.cgi?id=12518
> which
On Wed, May 04, 2011 at 12:10:48AM -0500, Jonathan Nieder wrote:
> Sounds like http://sourceware.org/bugzilla/show_bug.cgi?id=12518
> which is fixed (sort of) by commit 0354e355 (2011-04-01).
Oh my word. So glibc 2.13 breaks random binaries that happened to
incorrectly use memcpy() instead of me
Processing commands for cont...@bugs.debian.org:
> reassign 625521 xserver-xorg-core 2:1.10.1-2
Bug #625521 [libc6] causes segfault in Xorg
Bug reassigned from package 'libc6' to 'xserver-xorg-core'.
Bug No longer marked as found in versions eglibc/2.13-2.
Bug #625521 [xserver-xorg-core] causes se
reassign 625521 xserver-xorg-core 2:1.10.1-2
quit
Hi,
Steve M. Robbins wrote:
> Xorg now segfaults, with the following in the Xorg.0.log:
>
> Program received signal SIGSEGV, Segmentation fault.
> __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:153
> 153 ../sysdeps/x86_64/mul
36 matches
Mail list logo
