Xserver and gdb
Michel Dänzer
michel at daenzer.net
Mon Jan 30 08:55:33 PST 2006
On Sat, 2006-01-28 at 16:26 +0100, Jacek Popławski wrote:
>
> After each X crash/lock I go to another computer, use ssh to connect, then "gdb
> /usr/bin/X pid", and then store backtrace into the file. I can continue process
> (with "c"), but server doesn't respond to mouse/keyboard input.
The server is probably stuck in an infinite loop then.
> Do I understand correctly that X are not multithreaded?
Yes, hence such a loop appears like a lockup locally.
> #4 0xb7e51e69 in ioctl () from /lib/tls/libc.so.6
> #5 0x080e6530 in xf86ioctl ()
> #6 0xb7a11a92 in drmCommandNone () from /usr/lib/xorg/modules/linux/libdrm.so
> #7 0xb79d0e1a in RADEONWaitForIdleCP (pScrn=0x82139e8)
> at radeon_commonfuncs.c:137
Looks like a classic hardware lockup. The driver is waiting indefinitely
for the hardware to catch up.
> - recompile X/Mesa/drm with debugging symbols because important stuff is "??"
> or symbols are wrong?
>
> - submit such backtraces as bug?
>
> - fix something obvious?
None of this tends to be very useful with hardware lockups, which are
usually caused by 3D (or 2D/3D synchronization) driver bugs. Your best
bet is probably filing a bug with as much information as possible on how
to reproduce the problem, ideally a small test program.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
More information about the xorg
mailing list