Created attachment 815683 [details] Xorg.0.log from boot with kernel 3.11.4-101 Description of problem: When GDM starts, the screen is filled with random garbage. I can switch to a tty and login from there. The machine is otherwise responsive. Version-Release number of selected component (if applicable): kernel-3.11.4-101.fc18.x86_64 How reproducible: Always Steps to Reproduce: 1. Boot in graphical mode. Actual results: Total screen corruption. Expected results: Login screen should be displayed. Additional info: This started with kernel-3.11.4-101.fc18.x86_64. Booting with kernel-3.10.13-101.fc18.x86_64 works correctly. I've attached the Xorg.0.log from a boot with 3.11.4-101, but sadly it looks kind of useless. There were a bunch of error messages being printed to the screen while I tried shutting down that appeared to be coming from the noveau driver---I suspect those would have been in dmesg, which is now gone. If you'd like those, I can boot again with 3.11.4-101 and grab dmesg from a tty.
The hardware on which this is happening is a ThinkPad W520 with both nVidia Quadro 1000M and Intel graphics chiptsets. I am using the nouveau driver for the nVidia card. The BIOS is set to use only discrete graphics (the nVidia chipset).
I have the same problem with both kernel 3.11.4. and 3.11.7 on another Thinkpad W520. Kernel 3.10.10-100 still works fine with X. I get the following error messages in dmesg that might be relevant. Is there anything I can di to help track this down? [ 2.528763] nouveau [ DRM] MM: using COPY0 for buffer copies [ 2.690445] nouveau E[ PBUS][0000:01:00.0] MMIO write of 0x00000401 FAULT at 0x002010 [ IBUS TIMEOUT ] [ 2.744996] nouveau [ DRM] allocated 1600x900 fb: 0x60000, bo ffff8803250bc800 [ 2.745101] fbcon: nouveaufb (fb0) is primary device [ 4.194685] nouveau E[ DRM] GPU lockup - switching to software fbcon [ 4.196655] nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device [ 4.196656] nouveau 0000:01:00.0: registered panic notifier [ 4.196672] [drm] Initialized nouveau 1.1.1 20120801 for 0000:01:00.0 on minor 0 [ 16.694010] nouveau E[ PFIFO][0000:01:00.0] playlist update failed [ 18.769109] nouveau E[ PFIFO][0000:01:00.0] playlist update failed [ 155.078238] nouveau E[ PFIFO][0000:01:00.0] playlist update failed [ 233.217571] nouveau E[gnome-session-c[1612]] failed to idle channel 0xcccc0000 [gnome-session-c[1612]] [ 248.215837] nouveau E[gnome-session-c[1612]] failed to idle channel 0xcccc0000 [gnome-session-c[1612]] [ 263.214083] nouveau E[gnome-session-c[1612]] failed to idle channel 0xcccc0000 [gnome-session-c[1612]] [ 265.213913] nouveau E[ PFIFO][0000:01:00.0] channel 4 [gnome-session-c[1612]] kick timeout
I'm seeing similar problems, though my issues usually start sometime after I log in, and are often recoverable by hitting Alt-F2, then blindly entering 'r' and ENTER -- basically reloading gnome-shell. Other times, I get the 'failed to idle channel' messages and can usually switch to VT, but X is completely wedged and the box will not shut down cleanly. Most recently seen on kernel-3.11.9-200.fc19.x86_64, but I've had trouble since the first few kernel updates on F19, if not on the install kernel. This is gnome-shell-3.8.4-2.fc19.x86_64 with an up-to-date Mesa stack as of today. 01:00.0 VGA compatible controller: NVIDIA Corporation GK106 [GeForce GTX 660] (rev a1) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device 8422
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This no longer happens for me with 3.11.10-100.fc18.x86_64.
Thanks for the info Joel. David, Håvard can you confirm that 3.11.10 or later fixes it for you as well? Thanks, Michele
I've upgraded to Fedora 20, and didn't see this problem there.
It seems that 3.12.5-200.fc19.x86_64 is no longer susceptible to the issue; I still get lockups, but that's another bug. The corruptions were much more frequent, and seem to have stopped. Thanks!
Thanks for the updates guys!
Just updated to 3.12.6-200.fc19.x86_64, and this problem is back. :(