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
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
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 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
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:
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
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
24 matches
Mail list logo
