Created attachment 484043 [details] xorg log file Description of problem: Desktop becomes completely unresponsive; although the mouse-cursor still tracks, nothing responds to input. This requires a hard power-off to resolve. Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.10.0-3.fc15.x86_64 How reproducible: I can't reproduce this on demand yet, but it invariably happens after 1-2 hours of desktop use. Most (perhaps every) time this has happened, Firefox has been running. Steps to Reproduce: Unable to reproduce on demand, although it does happen reliably after using the desktop for a while. Actual results: Desktop freezes up. Expected results: Desktop doesn't freeze up. Additional info: See end of attached Xorg.0.log.old for backtrace.
I'm assuming the lock-up is due to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=26980
Backtrace: [ 21735.234] 0: /usr/bin/Xorg (xorg_backtrace+0x2f) [0x4a105f] [ 21735.234] 1: /usr/bin/Xorg (mieqEnqueue+0x1e9) [0x4a0579] [ 21735.234] 2: /usr/bin/Xorg (xf86PostMotionEventM+0xa3) [0x47d833] [ 21735.234] 3: /usr/bin/Xorg (xf86PostMotionEvent+0xda) [0x47da6a] [ 21735.234] 4: /usr/lib64/xorg/modules/input/synaptics_drv.so (0x7f4fdb2f4000+0x3069) [0x7f4fdb2f7069] [ 21735.234] 5: /usr/lib64/xorg/modules/input/synaptics_drv.so (0x7f4fdb2f4000+0x4d26) [0x7f4fdb2f8d26] [ 21735.234] 6: /usr/bin/Xorg (0x400000+0x6b308) [0x46b308] [ 21735.234] 7: /usr/bin/Xorg (0x400000+0x1188d0) [0x5188d0] [ 21735.234] 8: /lib64/libpthread.so.0 (0x3436e00000+0xf4e0) [0x3436e0f4e0] [ 21735.234] 9: /lib64/libc.so.6 (ioctl+0x7) [0x3436ad8787] [ 21735.234] 10: /usr/lib64/libdrm.so.2 (drmIoctl+0x28) [0x3446203318] [ 21735.234] 11: /usr/lib64/libdrm.so.2 (drmCommandWrite+0x1b) [0x34462053fb] [ 21735.234] 12: /usr/lib64/libdrm_nouveau.so.1 (0x7f4fdddf0000+0x2eb7) [0x7f4fdddf2eb7] [ 21735.234] 13: /usr/lib64/libdrm_nouveau.so.1 (nouveau_bo_map_range+0x109) [0x7f4fdddf34d9] [ 21735.234] 14: /usr/lib64/xorg/modules/drivers/nouveau_drv.so (0x7f4fddff5000+0x6ddb) [0x7f4fddffbddb] [ 21735.234] 15: /usr/lib64/xorg/modules/libexa.so (0x7f4fdd3a7000+0x614e) [0x7f4fdd3ad14e] [ 21735.234] 16: /usr/lib64/xorg/modules/libexa.so (0x7f4fdd3a7000+0x8b99) [0x7f4fdd3afb99] [ 21735.234] 17: /usr/lib64/xorg/modules/libexa.so (0x7f4fdd3a7000+0x13d10) [0x7f4fdd3bad10] [ 21735.234] 18: /usr/lib64/xorg/modules/libexa.so (0x7f4fdd3a7000+0xffcf) [0x7f4fdd3b6fcf] [ 21735.234] 19: /usr/bin/Xorg (0x400000+0xd865d) [0x4d865d] [ 21735.234] 20: /usr/bin/Xorg (0x400000+0xd30d5) [0x4d30d5] [ 21735.234] 21: /usr/bin/Xorg (0x400000+0x2eab1) [0x42eab1] [ 21735.234] 22: /usr/bin/Xorg (0x400000+0x22d3a) [0x422d3a] [ 21735.234] 23: /lib64/libc.so.6 (__libc_start_main+0xed) [0x3436a2131d] [ 21735.234] 24: /usr/bin/Xorg (0x400000+0x23021) [0x423021]
(In reply to comment #1) > I'm assuming the lock-up is due to this bug: > > https://bugs.freedesktop.org/show_bug.cgi?id=26980 Yes, it looks awfully similar.
There's two things you can try here. The first would've been suggested in the freedesktop bug (add nouveau.noaccel=1 to your boot options). The second, is to see if the intel_ips module is loaded, and rmmod it after you've booted. See 684907 for more info on that. Let me know how you go :)
Thanks, Ben. I added nouveau.noaccel=1 to my kernel parameters to work around the bug in the external tracker reference, but then ran in to bug #688693 instead (presumably not related to this bug). I will try both accelerated and non-accelerated configurations with intel_ips unloaded and get back with the results.
I am still experiencing the lock-up with the intel_ips module blacklisted and graphic acceleration on.
intel_ips isn't still getting loaded in your initrd?
(In reply to comment #7) > intel_ips isn't still getting loaded in your initrd? No. Adding 'rdblacklist=intel_ips' as a kernel parameter had no effect so I'm assuming it's not in the initrd. Adding the module to blacklist.conf prevented it from showing up in the output of lsmod. At the moment my system is unstable to the point of being unusable (not necessarily related to only this bug) so I will do a reinstall tonight and re-test on a fresh install.
Current configuration: - Fresh install of F15 Alpha on a Thinkpad T410i with NVA8 GPU - Upgraded system from updates repo (not updates-testing) - Using nouveau graphic acceleration - Added intel_ips to /etc/modprobe.d/blacklist.conf and rebooted Still experiencing the freeze. Has happened twice in the last day - I would like to say that's less than normal, but without being able to reproduce it reliably I can't really determine if unloading intel_ips helps at all.
I'm experiencing this issue on my Thinkpad T510 with the GT218 (NVS3100M) graphics card. Should this be a beta/release blocker? This bug, when combined with bug 688693 makes newer nVidia chipsets unusable in F15. So far, the only solution I've found is to suffer with the proprietary graphics.
Rich - are you using a beta-version nVidia proprietary driver or something? I couldn't find one to work with F15's Xorg. On a related note, I haven't experienced a single freeze since yesterday's update to kernel-2.6.38.2-8.fc15.x86_64...
Yes, I'm using the beta version provided in the rpmfusion repositories. I got that kernel update last night, I'll try reverting to nouveau and report back if I still have problems.
(In reply to comment #10) > I'm experiencing this issue on my Thinkpad T510 with the GT218 (NVS3100M) > graphics card. Should this be a beta/release blocker? This bug, when combined > with bug 688693 makes newer nVidia chipsets unusable in F15. So far, the only > solution I've found is to suffer with the proprietary graphics. How are things with nouveau with *at least* the kernel Aaron mentioned, and all the other updates in updates-testing? I have a T510 that I've used without encountering this issue for a long time now.
(In reply to comment #11) > Rich - are you using a beta-version nVidia proprietary driver or something? I > couldn't find one to work with F15's Xorg. > > On a related note, I haven't experienced a single freeze since yesterday's > update to kernel-2.6.38.2-8.fc15.x86_64... Any updates on your particular situation?
I'm running sans-intel_ips with kernel-2.6.38.2-9.fc15.x86_64 and still getting freezes, albeit less often than before (2-3 times per day with heavy usage). I'm holding my breath for http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=25c68aef4e6abcc3c10f593fc565c342ebe2ded8 to hit testing - I'm assuming it hasn't already?
(In reply to comment #15) > I'm running sans-intel_ips with kernel-2.6.38.2-9.fc15.x86_64 and still getting > freezes, albeit less often than before (2-3 times per day with heavy usage). > > I'm holding my breath for > http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=25c68aef4e6abcc3c10f593fc565c342ebe2ded8 > to hit testing - I'm assuming it hasn't already? No not yet. 2.6.38.2-11 in koji has the patch however.
(In reply to comment #13) > (In reply to comment #10) > > I'm experiencing this issue on my Thinkpad T510 with the GT218 (NVS3100M) > > graphics card. Should this be a beta/release blocker? This bug, when combined > > with bug 688693 makes newer nVidia chipsets unusable in F15. So far, the only > > solution I've found is to suffer with the proprietary graphics. > > How are things with nouveau with *at least* the kernel Aaron mentioned, and all > the other updates in updates-testing? I have a T510 that I've used without > encountering this issue for a long time now. I am still experiencing lock-ups with 2.6.38.2-9 installed. The rest of the system is up to date as well.
(In reply to comment #17) > (In reply to comment #13) > > (In reply to comment #10) > > > I'm experiencing this issue on my Thinkpad T510 with the GT218 (NVS3100M) > > > graphics card. Should this be a beta/release blocker? This bug, when combined > > > with bug 688693 makes newer nVidia chipsets unusable in F15. So far, the only > > > solution I've found is to suffer with the proprietary graphics. > > > > How are things with nouveau with *at least* the kernel Aaron mentioned, and all > > the other updates in updates-testing? I have a T510 that I've used without > > encountering this issue for a long time now. > > I am still experiencing lock-ups with 2.6.38.2-9 installed. The rest of the > system is up to date as well. Can you attach your dmesg output please, this bug is ridiculous, there *has* to be something different between our machines!
Created attachment 491118 [details] T510 dmesg output
I'm hesitant to draw any conclusions just yet, but I have been running for 2 days now without a single crash using kernel-2.6.38.2-13.fc15.x86_64 from koji. I'll do my best to break things over the next few days and see what happens.
After another crash last night, I upgraded to the 2.6.38.2-14 kernel from koji. I've been working for the past several hours with several applications open, switching between desktops, etc. and haven't had any crashes. It looks like one of the kernel patches has solved my problems as well, I'll be stress testing over the next few days as well.
Roughly 4 days with kernel-2.6.38.2-13; 2 crashes. The crashes are slightly different however, as the mouse stops tracking now too when the desktop freezes. Both crashes occurred when using the status bar at the bottom of the screen, however I'm not getting tracebacks anywhere these days so I can't provide any more detailed information. In general the driver seems a lot more stable than before.
I've just realised that the crashes described in the previous comment _may_ have occurred while using the wrong kernel. Clever. I have now been running 2.6.38.3-15.rc1.fc15.x86_64 for nearly 3 days without a crash.
Thank you for letting us know.
I still see random hangs / crashes with a GT215 using 2.6.38.3-15.rc1.fc15.x86_64, sadly.
*** This bug has been marked as a duplicate of bug 679319 ***