Bug 598711

Summary: Xorg w/ F13 Nouveau freezes on Thinkpad W510 laptop during routine use
Product: [Fedora] Fedora Reporter: Brendan Conoboy <blc>
Component: xorg-x11-drv-nouveauAssignee: Ben Skeggs <bskeggs>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 13CC: airlied, ajax, barbara.xxx1975, bskeggs, mcepl, williams
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-06-01 22:33:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Log file that shows the backtrace
none
A copy of /var/log/dmesg for general system information none

Description Brendan Conoboy 2010-06-01 21:25:16 UTC 
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.
Comment 1 Brendan Conoboy 2010-06-01 21:26:27 UTC 
Created attachment 418831 [details]
Log file that shows the backtrace
Comment 2 Brendan Conoboy 2010-06-01 21:27:52 UTC 
Created attachment 418833 [details]
A copy of /var/log/dmesg for general system information
Comment 4 Matěj Cepl 2010-06-01 21:38:16 UTC 
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]
Comment 5 Matěj Cepl 2010-06-01 22:03:41 UTC 
OK, I have a suspicion that this is a duplicate of the bug 596330.
Comment 6 Clark Williams 2010-06-01 22:18:43 UTC 
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.
Comment 7 Ben Skeggs 2010-06-01 22:33:57 UTC 
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 ***
Comment 8 Clark Williams 2010-06-02 15:40:25 UTC 
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.
Comment 9 Brendan Conoboy 2010-06-02 16:55:25 UTC 
Putting nouveau.noaccel=1 on my kernel command line has kept the system stable for the last 18 hours.  Performance is still decent, too.
Comment 10 Barbara 2010-06-02 23:21:26 UTC 
Did you tried adding pcie_aspm=off to kernel parameters?
Comment 11 Clark Williams 2010-06-03 14:40:10 UTC 
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?