Crash in NewInputDeviceRequest after Suspend/resume

[Connor Imes]

Dell 600m laptop.

The symptom here is the same as bug 157395, but different hardware and is a regression from Intrepid and earlier versions.

After a standby/resume cycle, I am presented with the gnome login screen and can successfully login again, but my previous session is lost.

Hibernate/resume works just fine.

Backtrace:
0: /usr/X11R6/bin/X(xorg_backtrace+0x3b) [0x813280b]
1: /usr/X11R6/bin/X(xf86SigHandler+0x55) [0x80c5db5]
2: [0xb8031400]
3: /usr/X11R6/bin/X [0x80d6ea0]
4: /usr/X11R6/bin/X(NewInputDeviceRequest+0x263) [0x80d71b3]
5: /usr/X11R6/bin/X [0x80ab988]
6: /usr/lib/libhal.so.1 [0xb7f6e739]
7: /lib/libdbus-1.so.3(dbus_connection_dispatch+0x395) [0xb7f370e5]
8: /lib/libdbus-1.so.3 [0xb7f37537]
9: /usr/X11R6/bin/X [0x80aad33]
10: /usr/X11R6/bin/X(WakeupHandler+0x52) [0x8090b52]
11: /usr/X11R6/bin/X(WaitForSomething+0x1bb) [0x813008b]
12: /usr/X11R6/bin/X(Dispatch+0x7e) [0x808cafe]
13: /usr/X11R6/bin/X(main+0x3bd) [0x8071aad]
14: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7c07775]
15: /usr/X11R6/bin/X [0x8070f61]
Saw signal 11. Server aborting.
 ddxSigGiveUp: Closing log
 ddxSigGiveUp: re-raising 11

[lspci]
00:00.0 Host bridge [0600]: Intel Corporation 82855PM Processor to I/O Controller [8086:3340] (rev 03)
     Subsystem: Dell Device [1028:011e]
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] [1002:4c66] (rev 01)
     Subsystem: Dell Device [1028:011e]

[Connor Imes (ckimes)]

Sorry, forgot dmesg!

[Bryce Harrington (bryce)]

 Rocket2DMn: if it is an X crash then there will be a backtrace printed to /var/log/Xorg.0.log or errors to a file in /var/log/gdm/.
 Rocket2DMn: if that's the case, then the next step is to collect a full backtrace via http://wiki.ubuntu.com/X/Backtracing

[Connor Imes (ckimes)]

from /var/log/gdm/
:0.log.1

[Bryce Harrington (bryce)]

Please collect a full backtrace - see http://wiki.ubuntu.com/X/Backtracing for directions.

[Connor Imes (ckimes)]

OK, here is the backtrace.

In case anybody else needs to obtain such a trace in a similar situation, here is how I got this one.
----

Boot computer and login to X. openssh-server must be installed and running, and you must know the computer's IP and be able to access it from another system on the network.
Switch to tty1. Run:
   screen -S xcrash
You may call the session whatever you want, I called it "xcrash".

Now inside the screen session, run:
   pgrep Xorg
   sudo gdb /usr/bin/Xorg
Now
   (gdb) attach <the process ID you found above>
   (gdb) handle SIGUSR1 nostop
   (gdb) cont
The second line is required in order to be able to switch back to X.
Now detach from the screen session (ctrl+a+d).

Switch back to X (usually tty7, sometimes tty9). Activate suspend/standby. Wait a few seconds, then pull the system out of suspend.
Screen is blank.

From a remote computer, open an ssh session. Run:
   screen -x xcrash
Now you have recovered your screen session and you will see some output in gdb.
Enable logging:
   (gdb) set logging on
Get the backtrace:
   (gdb) backtrace full
Enter your way through the backtrace.

Now open another terminal and grab your log file, this is easiest with scp:
   scp:username@ip:gdb.txt .
example (not real name/IP)
   scp connor@192.168.1.100:gdb.txt .
You now have the gdb.txt file with the backtrace on the machine you made your remote connection from.

[Bryce Harrington (bryce)]

Thanks Connor, good sleuthing.

[Bryce Harrington (bryce)]

Committed to git; it's queued up to go next time Timo does an xserver release which should happen fairly soon.

[Connor Imes (ckimes)]

Bryce, this appears to be fixed in Jaunty Alpha-3 - can you confirm that Timo included this fix and it's now available? If so, we can mark this as Fix Released.

[Timo Aaltonen (tjaalton)]

fixed at least in 1.5.99.901 which is now in jaunty.

[m0sia (m0sia)]

everything works correct in intrepid, but after updating to jaunty i have same bug.