Bug#616389: xserver-xorg-video-radeon: Crashes when closing graphical VT ((EE) RADEON(0): failed to set mode: Permission denied)
On Fre, 2011-03-11 at 22:49 +, Thue Janus Kristensen wrote:
2011/3/11 Michel Dänzer daen...@debian.org
On Don, 2011-03-10 at 15:33 +0100, Michel Dänzer wrote:
On Don, 2011-03-10 at 14:13 +, Thue Janus Kristensen
wrote:
Accoding to gdb, the second server is called as
drmDropMaster(fd=9)
and the first server calls
drmSetMaster(fd=9)
Switching between VT7 and VT8 a few times, they also are
both called
with drmDropMaster(fd=9) and drmSetMaster(fd=9).
Then I'm confused why the EBADF... If the file descriptor
was closed
before drmDropMaster, then I would have expected that to
implicitly drop
master as well.
Just in case though, assuming you guys have libgl1-mesa-dri
7.10-3 or
newer, does downgrading that to an older version fix the
problem?
I had 7.10-4. Downgrading to libgl1-mesa-dri_7.7.1-4_amd64.deb seems
to fix the crash.
Mesa upstream Git commit 9b7f3776359640d452697f3a487a345820abebf0
('r600: don't close fd on failed load') might fix the problem with the
r600g driver shipped in 7.10-4 then.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1299957719.6124.21.camel@thor.local
Bug#616389: xserver-xorg-video-radeon: Crashes when closing graphical VT ((EE) RADEON(0): failed to set mode: Permission denied)
2011/3/12 Michel Dänzer daen...@debian.org
On Fre, 2011-03-11 at 22:49 +, Thue Janus Kristensen wrote:
I had 7.10-4. Downgrading to libgl1-mesa-dri_7.7.1-4_amd64.deb seems
to fix the crash.
Mesa upstream Git commit 9b7f3776359640d452697f3a487a345820abebf0
('r600: don't close fd on failed load') might fix the problem with the
r600g driver shipped in 7.10-4 then.
I recompiled the Debian libgl1-mesa-dri_7.10-4 package with that patch
manually applied, and the problem went away :).
Regards, Thue
Bug#616389: xserver-xorg-video-radeon: Crashes when closing graphical VT ((EE) RADEON(0): failed to set mode: Permission denied)
On Don, 2011-03-10 at 15:33 +0100, Michel Dänzer wrote: On Don, 2011-03-10 at 14:13 +, Thue Janus Kristensen wrote: Accoding to gdb, the second server is called as drmDropMaster(fd=9) and the first server calls drmSetMaster(fd=9) Switching between VT7 and VT8 a few times, they also are both called with drmDropMaster(fd=9) and drmSetMaster(fd=9). Then I'm confused why the EBADF... If the file descriptor was closed before drmDropMaster, then I would have expected that to implicitly drop master as well. Just in case though, assuming you guys have libgl1-mesa-dri 7.10-3 or newer, does downgrading that to an older version fix the problem? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1299838793.3707.9.camel@thor.local
Bug#616389: xserver-xorg-video-radeon: Crashes when closing graphical VT ((EE) RADEON(0): failed to set mode: Permission denied)
2011/3/11 Michel Dänzer daen...@debian.org On Don, 2011-03-10 at 15:33 +0100, Michel Dänzer wrote: On Don, 2011-03-10 at 14:13 +, Thue Janus Kristensen wrote: Accoding to gdb, the second server is called as drmDropMaster(fd=9) and the first server calls drmSetMaster(fd=9) Switching between VT7 and VT8 a few times, they also are both called with drmDropMaster(fd=9) and drmSetMaster(fd=9). Then I'm confused why the EBADF... If the file descriptor was closed before drmDropMaster, then I would have expected that to implicitly drop master as well. Just in case though, assuming you guys have libgl1-mesa-dri 7.10-3 or newer, does downgrading that to an older version fix the problem? I had 7.10-4. Downgrading to libgl1-mesa-dri_7.7.1-4_amd64.deb seems to fix the crash. I tried compiling the kernel to debug, but I am having some general problems. Apparently the current kernel in unstable is not compilable with the current binutils in unstable. And the latest downloaded from from kernel.org fails to mount the root filesystem. Grumble. I can find a solution, I just needed to lament a bit to somebody :). Regards, Thue
Bug#616389: xserver-xorg-video-radeon: Crashes when closing graphical VT ((EE) RADEON(0): failed to set mode: Permission denied)
On Mit, 2011-03-09 at 18:04 +, Thue Janus Kristensen wrote: 2011/3/9 Michel Dänzer daen...@debian.org How about if you only set a breakpoint on drmDropMaster in the second server, and on hitting it just 'finish' the function before continuing. Does the first server hit drmSetMaster before drmDropMaster has finished in the second one? No. Nothing happens even after I finish in the second server. Only when I continue after the drmDropMaster finish, does the first server hit the drmSetMaster breakpoint (or crash if there is no drmSetMaster breakpoint). Hmm, weird. Does drmDropMaster return 0, or an error code? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1299747975.5726.59.camel@thor.local
Bug#616389: xserver-xorg-video-radeon: Crashes when closing graphical VT ((EE) RADEON(0): failed to set mode: Permission denied)
finish doesn't display the return value, because there is no debug symbols. And amd64 assembler is not my strong point. A random page on the Internet said that the return value is probably in eax. Doing print $eax after finish on drmDropMaster on the second X server, I get the value -1. Regards, Thue 2011/3/10 Michel Dänzer daen...@debian.org On Mit, 2011-03-09 at 18:04 +, Thue Janus Kristensen wrote: 2011/3/9 Michel Dänzer daen...@debian.org How about if you only set a breakpoint on drmDropMaster in the second server, and on hitting it just 'finish' the function before continuing. Does the first server hit drmSetMaster before drmDropMaster has finished in the second one? No. Nothing happens even after I finish in the second server. Only when I continue after the drmDropMaster finish, does the first server hit the drmSetMaster breakpoint (or crash if there is no drmSetMaster breakpoint). Hmm, weird. Does drmDropMaster return 0, or an error code? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer
Bug#616389: xserver-xorg-video-radeon: Crashes when closing graphical VT ((EE) RADEON(0): failed to set mode: Permission denied)
Googling a bit more, it turns out that the return value on amd64 is in $rax. That value was also -1. Regards, Thue 2011/3/10 Thue Janus Kristensen thu...@gmail.com finish doesn't display the return value, because there is no debug symbols. And amd64 assembler is not my strong point. A random page on the Internet said that the return value is probably in eax. Doing print $eax after finish on drmDropMaster on the second X server, I get the value -1. Regards, Thue 2011/3/10 Michel Dänzer daen...@debian.org On Mit, 2011-03-09 at 18:04 +, Thue Janus Kristensen wrote: 2011/3/9 Michel Dänzer daen...@debian.org How about if you only set a breakpoint on drmDropMaster in the second server, and on hitting it just 'finish' the function before continuing. Does the first server hit drmSetMaster before drmDropMaster has finished in the second one? No. Nothing happens even after I finish in the second server. Only when I continue after the drmDropMaster finish, does the first server hit the drmSetMaster breakpoint (or crash if there is no drmSetMaster breakpoint). Hmm, weird. Does drmDropMaster return 0, or an error code? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer
Bug#616389: xserver-xorg-video-radeon: Crashes when closing graphical VT ((EE) RADEON(0): failed to set mode: Permission denied)
On Don, 2011-03-10 at 12:38 +, Thue Janus Kristensen wrote: finish doesn't display the return value, because there is no debug symbols. Install libdrm2-dbg? :) A random page on the Internet said that the return value is probably in eax. Doing print $eax after finish on drmDropMaster on the second X server, I get the value -1. Can you get the value of errno as well? This does indicate that the DRM_IOCTL_DROP_MASTER may be failing, which could explain the problem. The question why it would fail. Looking at drm_dropmaster_ioctl() in the kernel, I think the only relevant case is if (!file_priv-minor-master) return -EINVAL; but I don't know how file_priv-minor-master could be NULL. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1299761771.5726.102.camel@thor.local
Bug#616389: xserver-xorg-video-radeon: Crashes when closing graphical VT ((EE) RADEON(0): failed to set mode: Permission denied)
2011/3/10 Michel Dänzer daen...@debian.org On Don, 2011-03-10 at 12:38 +, Thue Janus Kristensen wrote: finish doesn't display the return value, because there is no debug symbols. Install libdrm2-dbg? :) Ah, thanks. The return value is indeed -1. A random page on the Internet said that the return value is probably in eax. Doing print $eax after finish on drmDropMaster on the second X server, I get the value -1. Can you get the value of errno as well? (gdb) finish [...] (gdb) print errno $6 = 9 This does indicate that the DRM_IOCTL_DROP_MASTER may be failing, which could explain the problem. The question why it would fail. Looking at drm_dropmaster_ioctl() in the kernel, I think the only relevant case is if (!file_priv-minor-master) return -EINVAL; but I don't know how file_priv-minor-master could be NULL. Perhaps I should insert a debug print in the kernel source code, to verify that it is indeed that one which triggers? Regards, Thue
Bug#616389: xserver-xorg-video-radeon: Crashes when closing graphical VT ((EE) RADEON(0): failed to set mode: Permission denied)
On Don, 2011-03-10 at 13:21 +, Thue Janus Kristensen wrote: 2011/3/10 Michel Dänzer daen...@debian.org On Don, 2011-03-10 at 12:38 +, Thue Janus Kristensen wrote: after finish on drmDropMaster on the second X server, I get the value -1. Can you get the value of errno as well? (gdb) finish [...] (gdb) print errno $6 = 9 That's EBADF, so apparently the file descriptor passed in is invalid. Is it the same one that was passed to drmSetMaster? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1299765643.5726.115.camel@thor.local
Bug#616389: xserver-xorg-video-radeon: Crashes when closing graphical VT ((EE) RADEON(0): failed to set mode: Permission denied)
Accoding to gdb, the second server is called as drmDropMaster(fd=9) and the first server calls drmSetMaster(fd=9) Switching between VT7 and VT8 a few times, they also are both called with drmDropMaster(fd=9) and drmSetMaster(fd=9). Regards, Thue 2011/3/10 Michel Dänzer daen...@debian.org On Don, 2011-03-10 at 13:21 +, Thue Janus Kristensen wrote: 2011/3/10 Michel Dänzer daen...@debian.org On Don, 2011-03-10 at 12:38 +, Thue Janus Kristensen wrote: after finish on drmDropMaster on the second X server, I get the value -1. Can you get the value of errno as well? (gdb) finish [...] (gdb) print errno $6 = 9 That's EBADF, so apparently the file descriptor passed in is invalid. Is it the same one that was passed to drmSetMaster? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer
Bug#616389: xserver-xorg-video-radeon: Crashes when closing graphical VT ((EE) RADEON(0): failed to set mode: Permission denied)
On Don, 2011-03-10 at 14:13 +, Thue Janus Kristensen wrote: Accoding to gdb, the second server is called as drmDropMaster(fd=9) and the first server calls drmSetMaster(fd=9) Switching between VT7 and VT8 a few times, they also are both called with drmDropMaster(fd=9) and drmSetMaster(fd=9). Then I'm confused why the EBADF... If the file descriptor was closed before drmDropMaster, then I would have expected that to implicitly drop master as well. Dave, any ideas? Thue, if you'd like to play with adding some debugging output in the kernel, e.g. starting from why drm_setmaster_ioctl() fails, that might be interesting. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1299767601.5726.131.camel@thor.local
Bug#616389: xserver-xorg-video-radeon: Crashes when closing graphical VT ((EE) RADEON(0): failed to set mode: Permission denied)
On Die, 2011-03-08 at 22:00 +, Thue Janus Kristensen wrote: With both drmDropMaster breakpointed in the second server, and drmSetMaster breakpointed in the first server, drmDropMaster is called first in the second server, and the first server doesn't reach drmSetMaster until after I continue the second server from the drmDropMaster breakpoint. No crash. With only drmSetMaster breakpointed in the first server, but the second server still running with gdb attached for consistency, there is no crash when I continue the first server from the drmSetMaster breakpoint. With both servers running inside gdb, but no breakpoints, it crashes. So, apparently the problem is that drmSetMaster runs 'too early'... How about if you only set a breakpoint on drmDropMaster in the second server, and on hitting it just 'finish' the function before continuing. Does the first server hit drmSetMaster before drmDropMaster has finished in the second one? BTW, did you also get any SIGUSR1 or other signals in either server while doing this? If so, did you do the same for them as for SIGPIPE, to prevent them from influencing the timing between drmDrop/SetMaster? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1299675165.5726.23.camel@thor.local
Bug#616389: xserver-xorg-video-radeon: Crashes when closing graphical VT ((EE) RADEON(0): failed to set mode: Permission denied)
2011/3/9 Michel Dänzer daen...@debian.org On Die, 2011-03-08 at 22:00 +, Thue Janus Kristensen wrote: With both drmDropMaster breakpointed in the second server, and drmSetMaster breakpointed in the first server, drmDropMaster is called first in the second server, and the first server doesn't reach drmSetMaster until after I continue the second server from the drmDropMaster breakpoint. No crash. With only drmSetMaster breakpointed in the first server, but the second server still running with gdb attached for consistency, there is no crash when I continue the first server from the drmSetMaster breakpoint. With both servers running inside gdb, but no breakpoints, it crashes. So, apparently the problem is that drmSetMaster runs 'too early'... How about if you only set a breakpoint on drmDropMaster in the second server, and on hitting it just 'finish' the function before continuing. Does the first server hit drmSetMaster before drmDropMaster has finished in the second one? Will try when I get home. BTW, did you also get any SIGUSR1 or other signals in either server while doing this? If so, did you do the same for them as for SIGPIPE, to prevent them from influencing the timing between drmDrop/SetMaster? Yes, there were a number of other signals I had to stop gdb from breaking on. Regards, Thue
Bug#616389: xserver-xorg-video-radeon: Crashes when closing graphical VT ((EE) RADEON(0): failed to set mode: Permission denied)
2011/3/9 Michel Dänzer daen...@debian.org On Die, 2011-03-08 at 22:00 +, Thue Janus Kristensen wrote: With both drmDropMaster breakpointed in the second server, and drmSetMaster breakpointed in the first server, drmDropMaster is called first in the second server, and the first server doesn't reach drmSetMaster until after I continue the second server from the drmDropMaster breakpoint. No crash. With only drmSetMaster breakpointed in the first server, but the second server still running with gdb attached for consistency, there is no crash when I continue the first server from the drmSetMaster breakpoint. With both servers running inside gdb, but no breakpoints, it crashes. So, apparently the problem is that drmSetMaster runs 'too early'... How about if you only set a breakpoint on drmDropMaster in the second server, and on hitting it just 'finish' the function before continuing. Does the first server hit drmSetMaster before drmDropMaster has finished in the second one? No. Nothing happens even after I finish in the second server. Only when I continue after the drmDropMaster finish, does the first server hit the drmSetMaster breakpoint (or crash if there is no drmSetMaster breakpoint). Regards, Thue
Bug#616389: xserver-xorg-video-radeon: Crashes when closing graphical VT ((EE) RADEON(0): failed to set mode: Permission denied)
On Sam, 2011-03-05 at 18:36 +, Thue Janus Kristensen wrote: As far as I can tell, there is nothing interesting in kdm.log or Xorg.1.log (both attached, for a newly generated crash). Would be interesting if one of you guys could (from a remote login) attach gdb to both X servers and check that the second X server calls drmDropMaster() or dies before the first X server calls drmSetMaster(). -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1299586133.14068.232.camel@thor.local
Bug#616389: xserver-xorg-video-radeon: Crashes when closing graphical VT ((EE) RADEON(0): failed to set mode: Permission denied)
I am behind a NAT from my ISP. Would you be able to access a ssh server if I installed the miredo package (ipv6 tunneling)? (you could perhaps use the miredo package yourself) Regards, Thue 2011/3/8 Michel Dänzer daen...@debian.org On Sam, 2011-03-05 at 18:36 +, Thue Janus Kristensen wrote: As far as I can tell, there is nothing interesting in kdm.log or Xorg.1.log (both attached, for a newly generated crash). Would be interesting if one of you guys could (from a remote login) attach gdb to both X servers and check that the second X server calls drmDropMaster() or dies before the first X server calls drmSetMaster(). -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer
Bug#616389: xserver-xorg-video-radeon: Crashes when closing graphical VT ((EE) RADEON(0): failed to set mode: Permission denied)
On Tue, Mar 08, 2011 at 01:08:53PM +0100, Michel D?nzer wrote: On Sam, 2011-03-05 at 18:36 +, Thue Janus Kristensen wrote: As far as I can tell, there is nothing interesting in kdm.log or Xorg.1.log (both attached, for a newly generated crash). Would be interesting if one of you guys could (from a remote login) attach gdb to both X servers and check that the second X server calls drmDropMaster() or dies before the first X server calls drmSetMaster(). I had the crash only once, I would have to check how easily I can reproduce the problem. OTOH I can easily use ssh access to check, once I have reproduced the issue. I just have so many issues to run after :) Stay tuned -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110308193113.ga4...@home.lan
Bug#616389: xserver-xorg-video-radeon: Crashes when closing graphical VT ((EE) RADEON(0): failed to set mode: Permission denied)
I just tried, and with a gdb attached to both processes, there is no crash. I had to *continue* over some SIGPIPE etc, but I assume that is normal. So I assume that the problem is some kind of race condition? As I said, it is 100% reproducible until I tried it in gdb :). Regards, Thue 2011/3/8 Michel Dänzer daen...@debian.org On Sam, 2011-03-05 at 18:36 +, Thue Janus Kristensen wrote: As far as I can tell, there is nothing interesting in kdm.log or Xorg.1.log (both attached, for a newly generated crash). Would be interesting if one of you guys could (from a remote login) attach gdb to both X servers and check that the second X server calls drmDropMaster() or dies before the first X server calls drmSetMaster(). -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer
Bug#616389: xserver-xorg-video-radeon: Crashes when closing graphical VT ((EE) RADEON(0): failed to set mode: Permission denied)
On Tue, Mar 8, 2011 at 20:31:34 +, Thue Janus Kristensen wrote: I just tried, and with a gdb attached to both processes, there is no crash. I had to *continue* over some SIGPIPE etc, but I assume that is normal. Yes, you want 'handle SIGPIPE nostop noprint' in gdb. Cheers, Julien -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110308211729.gh12...@radis.liafa.jussieu.fr
Bug#616389: xserver-xorg-video-radeon: Crashes when closing graphical VT ((EE) RADEON(0): failed to set mode: Permission denied)
Thanks to the gdb guru :). With both drmDropMaster breakpointed in the second server, and drmSetMaster breakpointed in the first server, drmDropMaster is called first in the second server, and the first server doesn't reach drmSetMaster until after I continue the second server from the drmDropMaster breakpoint. No crash. With only drmSetMaster breakpointed in the first server, but the second server still running with gdb attached for consistency, there is no crash when I continue the first server from the drmSetMaster breakpoint. With both servers running inside gdb, but no breakpoints, it crashes. Hilsen Thue 2011/3/8 Julien Cristau jcris...@debian.org On Tue, Mar 8, 2011 at 20:31:34 +, Thue Janus Kristensen wrote: I just tried, and with a gdb attached to both processes, there is no crash. I had to *continue* over some SIGPIPE etc, but I assume that is normal. Yes, you want 'handle SIGPIPE nostop noprint' in gdb. Cheers, Julien
Bug#616389: xserver-xorg-video-radeon: Crashes when closing graphical VT ((EE) RADEON(0): failed to set mode: Permission denied)
On Don, 2011-03-03 at 10:33 +0100, Thue Janus Kristensen wrote: Package: xserver-xorg-video-radeon Version: 1:6.14.0-1 Severity: important I have a 100% reproducible crash, using these steps: 1) From inside KDE go kde menu-leave-switch user 2) New session 3) log in to the new session, with another user, using gnome 4) Go gnome panel-administrator-log [user] out...-logout 5) The X server crashes, with the following in Xorg.0.log: [...] [ 5654.762] (II) RADEON(0): Modeline 1600x1200x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz) [ 5728.944] (II) AIGLX: Suspending AIGLX clients for VT switch [ 5734.796] (II) Open ACPI successful (/var/run/acpid.socket) [ 5734.796] (II) AIGLX: Resuming AIGLX clients after VT switch [ 5734.797] Unable to retrieve master [ 5734.797] (EE) RADEON(0): failed to set mode: Permission denied(EE) RADEON(0): failed to set mode: Permission denied The question is why retrieving master fails. Most likely the second X server fails to drop master (in time), maybe it crashes or otherwise doesn't shut down cleanly? Anything interesting in the X or kdm/gdm log file for the second X server? Backtrace: [ 5734.797] 0: /usr/bin/X (xorg_backtrace+0x28) [0x45ceb8] [ 5734.797] 1: /usr/bin/X (0x40+0x64cd9) [0x464cd9] [ 5734.797] 2: /lib/libpthread.so.0 (0x7f020cb93000+0xef60) [0x7f020cba1f60] [ 5734.797] 3: /usr/lib/xorg/modules/drivers/radeon_drv.so (0x7f020980c000+0xebff1) [0x7f02098f7ff1] [ 5734.797] 4: /usr/bin/X (xf86ProbeOutputModes+0x146) [0x483316] [ 5734.797] 5: /usr/bin/X (0x40+0x8a044) [0x48a044] [ 5734.797] 6: /usr/bin/X (RRGetInfo+0xd1) [0x4b7cc1] [ 5734.797] 7: /usr/lib/xorg/modules/extensions/libglx.so (0x7f020a34b000+0x40c2c) [0x7f020a38bc2c] [ 5734.797] 8: /usr/bin/X (xf86Wakeup+0x3f2) [0x474902] [ 5734.797] 9: /usr/bin/X (WakeupHandler+0x4b) [0x43aa5b] [ 5734.797] 10: /usr/bin/X (WaitForSomething+0x1d7) [0x465547] [ 5734.797] 11: /usr/bin/X (0x40+0x32b12) [0x432b12] [ 5734.797] 12: /usr/bin/X (0x40+0x2573b) [0x42573b] [ 5734.797] 13: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7f020b8f6c4d] [ 5734.797] 14: /usr/bin/X (0x40+0x252c9) [0x4252c9] [ 5734.797] Segmentation fault at address 0x10 [ 5734.798] Fatal server error: [ 5734.798] Caught signal 11 (Segmentation fault). Server aborting I presume this is basically things going south after the above. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1299233018.14068.28.camel@thor.local
