Description of problem: During regular use (web browsing, email, 2D stuff) the Thinkpad W510 display freezes. The mouse cursor moves, but the display is otherwise frozen. Login via ssh shows a backtrace in Xorg.0.log and the Xorg binary is still running with 100% CPU utilization. Version-Release number of selected component (if applicable): This is x86_64 Fedora 13+updates as of May 30, 2010. How reproducible: Happens within a couple hours of use. The most recent crash was when switching desktops, dying midway through updating the screen. Steps to Reproduce: 1. Use X 2. Switch displays back and forth 3. Patience Additional info: No special configuration was necessary to cause this crash. There is no xorg.conf. There are no messages indicating a problem in /var/log/messages nor when dmesg is run.
Created attachment 418831 [details] Log file that shows the backtrace
Created attachment 418833 [details] A copy of /var/log/dmesg for general system information
Backtrace: [ 8092.385] 0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x49e708] [ 8092.385] 1: /usr/bin/Xorg (mieqEnqueue+0x1f4) [0x49e0b4] [ 8092.385] 2: /usr/bin/Xorg (xf86PostMotionEventP+0xc4) [0x477e24] [ 8092.386] 3: /usr/bin/Xorg (xf86PostMotionEvent+0xa9) [0x477fc9] [ 8092.386] 4: /usr/lib64/xorg/modules/input/synaptics_drv.so (0x7facf1c4a000+0x3739) [0x7facf1c4d739] [ 8092.386] 5: /usr/lib64/xorg/modules/input/synaptics_drv.so (0x7facf1c4a000+0x5af8) [0x7facf1c4faf8] [ 8092.386] 6: /usr/bin/Xorg (0x400000+0x6aae7) [0x46aae7] [ 8092.386] 7: /usr/bin/Xorg (0x400000+0x117b43) [0x517b43] [ 8092.386] 8: /lib64/libc.so.6 (0x36dd000000+0x32a40) [0x36dd032a40] [ 8092.386] 9: /lib64/libc.so.6 (ioctl+0x7) [0x36dd0d95c7] [ 8092.386] 10: /usr/lib64/libdrm.so.2 (drmIoctl+0x28) [0x36f5e03388] [ 8092.386] 11: /usr/lib64/libdrm.so.2 (drmCommandWrite+0x1b) [0x36f5e0360b] [ 8092.386] 12: /usr/lib64/libdrm_nouveau.so.1 (0x7facf3d5a000+0x2dfd) [0x7facf3d5cdfd] [ 8092.386] 13: /usr/lib64/libdrm_nouveau.so.1 (nouveau_bo_map_range+0xfe) [0x7facf3d5cfee] [ 8092.386] 14: /usr/lib64/xorg/modules/drivers/nouveau_drv.so (0x7facf3f5f000+0x56ed) [0x7facf3f646ed] [ 8092.386] 15: /usr/lib64/xorg/modules/libexa.so (0x7facf2ebe000+0x41a7) [0x7facf2ec21a7] [ 8092.386] 16: /usr/lib64/xorg/modules/libexa.so (0x7facf2ebe000+0x70b2) [0x7facf2ec50b2] [ 8092.386] 17: /usr/lib64/xorg/modules/libexa.so (0x7facf2ebe000+0x4387) [0x7facf2ec2387] [ 8092.386] 18: /usr/bin/Xorg (0x400000+0xd11ba) [0x4d11ba] [ 8092.386] 19: /usr/bin/Xorg (ValidateGC+0x24) [0x43f3e4] [ 8092.387] 20: /usr/bin/Xorg (miPaintWindow+0x10a) [0x455b5a] [ 8092.387] 21: /usr/bin/Xorg (miClearToBackground+0x12d) [0x55c8ed] [ 8092.387] 22: /usr/bin/Xorg (0x400000+0x29bbc) [0x429bbc] [ 8092.387] 23: /usr/bin/Xorg (0x400000+0x2c32c) [0x42c32c] [ 8092.387] 24: /usr/bin/Xorg (0x400000+0x219ca) [0x4219ca] [ 8092.387] 25: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x36dd01ec5d] [ 8092.387] 26: /usr/bin/Xorg (0x400000+0x21579) [0x421579]
OK, I have a suspicion that this is a duplicate of the bug 596330.
I have to wonder if it isn't touchpad related. The touchpad on my w510 is much bigger than the one on my old T60 and it's flush to the palmrest (as opposed to recessed a bit on the T60). I've been seeing sporadic lockups on F13 similar to what Brendan was seeing (but more frequent) and I had tons of problems with the thumb area of my palms inadvertently triggering touchpad events. I have to wonder if I was triggering a flood of touchpad events that eventually overwhelmed the driver. I've disabled the touchpad in the BIOS for now and will see if I encounter another X crash.
It's a different chipset, but at this point we (nouveau devs) are fairly certain that all NVA3/NVA5/NVA8 chipsets will experience this bug, so I'll mark as a dup for now. *** This bug has been marked as a duplicate of bug 596330 ***
just info, I had a lockup on my w510/F13 with the synaptics touchpad disabled so yeah, you're right it's the nouveau chipset. I'm booting now with nouveau.noaccel=1 on my kernel command line.
Putting nouveau.noaccel=1 on my kernel command line has kept the system stable for the last 18 hours. Performance is still decent, too.
Did you tried adding pcie_aspm=off to kernel parameters?
I can also attest to nouveau.noaccel=1 being solid. I didn't know that PCIe was problematic though. Do you guys think that Power Management has something to do with this bug?