Description of problem: I use F15 with the new Gnome 3 shell. After some the interface hangs and even if the mouse continue to move I'm unable to get any virtual terminal or perform any shell action. I use two DVI-connected screens with an NV43GL [Quadro FX 550] (rev a2). Version-Release number of selected component (if applicable): gnome-shell-3.0.1-4.fc15.x86_64 xorg-x11-drv-nouveau-0.0.16-24.20110324git8378443.fc15.x86_64 How reproducible: After some time of normal use (~2h or less) Steps to Reproduce: 1. Just use the gnome-shell 2. Move some windows to the second screen 3. Add apps to the favorites Additional info: - reduced dmesg trace [ 54.573753] [drm] nouveau 0000:01:00.0: Setting dpms mode 3 on tmds encoder (output 3) [ 54.593940] [drm] nouveau 0000:01:00.0: 0xA9A7: Parsing digital output script table [ 54.643966] [drm] nouveau 0000:01:00.0: Setting dpms mode 0 on tmds encoder (output 3) [ 54.643971] [drm] nouveau 0000:01:00.0: Output DVI-I-2 is running on CRTC 1 using output C [ 54.653029] [drm] nouveau 0000:01:00.0: Setting dpms mode 3 on tmds encoder (output 1) [ 54.673207] [drm] nouveau 0000:01:00.0: 0xA957: Parsing digital output script table [ 54.723227] [drm] nouveau 0000:01:00.0: Setting dpms mode 0 on tmds encoder (output 1) [ 54.723230] [drm] nouveau 0000:01:00.0: Output DVI-I-1 is running on CRTC 0 using output A [ 54.736463] hda-intel: IRQ timing workaround is activated for card #1. Suggest a bigger bdl_pos_adj. [ 1156.784545] [drm] nouveau 0000:01:00.0: PGRAPH - ERROR nsource: (unknown bits 0x00400000) nstatus: PROTECTION_FAULT [ 1156.784558] [drm] nouveau 0000:01:00.0: PGRAPH - ch 3 (0x000fa010) subc 7 class 0x4097 mthd 0x1818 data 0x3f7f3b32 [ 3632.393261] [drm] nouveau 0000:01:00.0: fail pre-validate sync [ 3632.393266] [drm] nouveau 0000:01:00.0: validate vram_list [ 3632.393280] [drm] nouveau 0000:01:00.0: validate: -16 [ 3632.452307] [drm] nouveau 0000:01:00.0: fail pre-validate sync [ 3632.452310] [drm] nouveau 0000:01:00.0: validate vram_list [ 3632.452330] [drm] nouveau 0000:01:00.0: validate: -16 [ 3957.236620] TCP lp registered
I am having similar problems. Gnome-shell freezes but mouse pointer works ok. I can remotely log into system with no problem. Problem seems to be with the graphical layer.
I'm having the same problem when using Blender, with similar error messages and exactly the same behaviour. I have to reboot via SSH to recover. I'm not using Gnome-shell. lspci -nn says: 01:00.0 VGA compatible controller [0300]: nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300] [10de:01d7] (rev a1) Driver: xorg-x11-drv-nouveau-0.0.16-24.20110324git8378443.fc15.i686 This is on a laptop, with no external screens.
Have to login and kill -9 Xorg to recover. kernel-3.3.8-1.fc16.x86_64 mesa-dri-drivers-7.11.2-3.fc16.x86_64 xorg-x11-drv-nouveau-0.0.16-27.20110720gitb806e3f.fc16.x86_64 This is all DRM related from dmesg [ 1.134364] [drm] Initialized drm 1.1.0 20060810 [ 1.143850] [drm] nouveau 0000:01:00.0: Detected an NV40 generation card (0x046d00a3) [ 1.147027] [drm] nouveau 0000:01:00.0: Attempting to load BIOS image from PRAMIN [ 1.228563] [drm] nouveau 0000:01:00.0: ... appears to be valid [ 1.228568] [drm] nouveau 0000:01:00.0: BIT BIOS found [ 1.228572] [drm] nouveau 0000:01:00.0: Bios version 05.72.22.62 [ 1.228576] [drm] nouveau 0000:01:00.0: TMDS table version 1.1 [ 1.228578] [drm] nouveau 0000:01:00.0: TMDS table script pointers not stubbed [ 1.228700] [drm] nouveau 0000:01:00.0: MXM: no VBIOS data, nothing to do [ 1.228704] [drm] nouveau 0000:01:00.0: DCB version 3.0 [ 1.228707] [drm] nouveau 0000:01:00.0: DCB outp 00: 01000300 00000028 [ 1.228710] [drm] nouveau 0000:01:00.0: DCB outp 01: 01000302 00000000 [ 1.228713] [drm] nouveau 0000:01:00.0: DCB outp 02: 02011310 00000028 [ 1.228715] [drm] nouveau 0000:01:00.0: DCB outp 03: 020223f1 00a0c030 [ 1.228718] [drm] nouveau 0000:01:00.0: DCB conn 00: 1030 [ 1.228721] [drm] nouveau 0000:01:00.0: DCB conn 01: 0100 [ 1.228723] [drm] nouveau 0000:01:00.0: DCB conn 02: 0210 [ 1.228725] [drm] nouveau 0000:01:00.0: DCB conn 03: 0211 [ 1.228728] [drm] nouveau 0000:01:00.0: DCB conn 04: 0213 [ 1.228736] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 0 at offset 0xD242 [ 1.228787] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 1 at offset 0xD571 [ 1.244023] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 2 at offset 0xDB0F [ 1.244043] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 3 at offset 0xDC8A [ 1.245171] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 4 at offset 0xDEE3 [ 1.265958] [drm] nouveau 0000:01:00.0: 1 available performance level(s) [ 1.265963] [drm] nouveau 0000:01:00.0: 0: core 550MHz shader 550MHz memory 800MHz fanspeed 100% [ 1.265971] [drm] nouveau 0000:01:00.0: c: core 199MHz memory 391MHz [ 1.266234] [drm] nouveau 0000:01:00.0: Detected 256MiB VRAM [ 1.274805] [drm] nouveau 0000:01:00.0: 512 MiB GART (aperture) [ 1.274971] [drm] nouveau 0000:01:00.0: Saving VGA fonts [ 1.335466] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 1.335469] [drm] No driver support for vblank timestamp query. [ 1.336570] [drm] nouveau 0000:01:00.0: 0xC641: Parsing digital output script table [ 1.387221] [drm] nouveau 0000:01:00.0: Setting dpms mode 3 on vga encoder (output 0) [ 1.387225] [drm] nouveau 0000:01:00.0: Setting dpms mode 3 on tmds encoder (output 1) [ 1.387228] [drm] nouveau 0000:01:00.0: Setting dpms mode 3 on vga encoder (output 2) [ 1.387231] [drm] nouveau 0000:01:00.0: Setting dpms mode 3 on TV encoder (output 3) [ 1.458071] [drm] nouveau 0000:01:00.0: allocated 1920x1200 fb: 0x49000, bo ffff8800389e9400 [ 1.470359] [drm] nouveau 0000:01:00.0: 0xC641: Parsing digital output script table [ 1.520397] [drm] nouveau 0000:01:00.0: Setting dpms mode 0 on tmds encoder (output 1) [ 1.520402] [drm] nouveau 0000:01:00.0: Output DVI-I-1 is running on CRTC 0 using output A [ 1.530967] drm: registered panic notifier [ 1.530976] [drm] Initialized nouveau 0.0.16 20090420 for 0000:01:00.0 on minor 0 [15101.193410] [drm] nouveau 0000:01:00.0: error fencing pushbuf: -16 [28030.578865] [drm] nouveau 0000:01:00.0: Setting dpms mode 3 on tmds encoder (output 1) [33582.189064] [drm] nouveau 0000:01:00.0: Setting dpms mode 0 on tmds encoder (output 1) [37210.583706] [drm] nouveau 0000:01:00.0: Setting dpms mode 3 on tmds encoder (output 1) [39692.889095] [drm] nouveau 0000:01:00.0: Setting dpms mode 0 on tmds encoder (output 1) [48318.610342] [drm] nouveau 0000:01:00.0: fail pre-validate sync [48318.610348] [drm] nouveau 0000:01:00.0: validate both_list [48318.610371] [drm] nouveau 0000:01:00.0: validate: -16 [48507.572011] [drm] nouveau 0000:01:00.0: Failed to idle channel 1. [48507.573775] [drm] nouveau 0000:01:00.0: PGRAPH - ERROR nsource: ILLEGAL_MTHD nstatus: PROTECTION_FAULT [48507.573784] [drm] nouveau 0000:01:00.0: PGRAPH - ch 32 (0x00000000) subc 2 class 0x1000 mthd 0x0184 data 0x00004000 [48507.578937] [drm] nouveau 0000:01:00.0: Setting dpms mode 3 on tmds encoder (output 1) [48508.042549] [drm] nouveau 0000:01:00.0: 0xC641: Parsing digital output script table [48508.092588] [drm] nouveau 0000:01:00.0: Setting dpms mode 0 on tmds encoder (output 1) [48508.092593] [drm] nouveau 0000:01:00.0: Output DVI-I-1 is running on CRTC 0 using output A
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. 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 '16'. 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 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 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 to click on "Clone This Bug" and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
I'm seeing similar behavior on Fedora 19. kernel-3.10.3-300.fc19.x86_64 xorg-x11-drv-nouveau-1.0.7-1.fc19.x86_64 Relevant stuff from /var/log/messages: Aug 3 09:07:35 mithlond kernel: [87798.217268] nouveau E[ DRM] GPU lockup - switching to software fbcon Aug 3 09:07:38 mithlond kernel: [87801.607014] nouveau E[Xorg[702]] failed to idle channel 0xcccc0001 [Xorg[702]] Aug 3 09:07:41 mithlond kernel: [87804.607017] nouveau E[Xorg[702]] failed to idle channel 0xcccc0001 [Xorg[702]] Aug 3 09:07:43 mithlond kernel: [87806.607124] nouveau E[ PFIFO][0000:01:00.0] channel 3 [Xorg[702]] unload timeout Aug 3 09:07:46 mithlond kernel: [87809.607012] nouveau E[Xorg[702]] failed to idle channel 0xcccc0000 [Xorg[702]] Aug 3 09:07:49 mithlond kernel: [87812.608018] nouveau E[Xorg[702]] failed to idle channel 0xcccc0000 [Xorg[702]] Aug 3 09:07:51 mithlond kernel: [87814.608138] nouveau E[ PFIFO][0000:01:00.0] channel 2 [Xorg[702]] unload timeout Aug 3 09:07:51 mithlond /etc/gdm/Xsession[900]: [6730:6730:0803/090751:ERROR:x11_util.cc(115)] X IO error received (X server probably went away) Aug 3 09:07:51 mithlond /etc/gdm/Xsession[900]: [3108:3108:0803/090751:ERROR:x11_util.cc(115)] X IO error received (X server probably went away) Aug 3 09:07:51 mithlond /etc/gdm/Xsession[900]: [2733:2733:0803/090751:ERROR:chrome_browser_main_x11.cc(62)] X IO error received (X server probably went away) Aug 3 09:07:51 mithlond /etc/gdm/Xsession[900]: (nautilus:1243): Gdk-WARNING **: nautilus: Fatal IO error 11 (Resource temporarily unavailable) on X server :0. Aug 3 09:07:51 mithlond /etc/gdm/Xsession[900]: (gnome-settings-daemon:1094): Gdk-WARNING **: gnome-settings-daemon: Fatal IO error 11 (Resource temporarily unavailable) on X server :0. Aug 3 09:07:51 mithlond /etc/gdm/Xsession[900]: Window manager warning: Log level 16: gnome-shell: Fatal IO error 0 (Success) on X server :0. Aug 3 09:07:51 mithlond /etc/gdm/Xsession[900]: gnome-session[900]: Gdk-WARNING: gnome-session: Fatal IO error 11 (Resource temporarily unavailable) on X server :0. Aug 3 09:07:51 mithlond gnome-session[900]: Gdk-WARNING: gnome-session: Fatal IO error 11 (Resource temporarily unavailable) on X server :0. Aug 3 09:07:51 mithlond /etc/gdm/Xsession[900]: thunderbird: Fatal IO error 11 (Resource temporarily unavailable) on X server :0. Aug 3 09:07:51 mithlond /etc/gdm/Xsession[900]: (nm-applet:1252): Gdk-WARNING **: nm-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0. Aug 3 09:07:51 mithlond /etc/gdm/Xsession[900]: dropbox: Fatal IO error 11 (Resource temporarily unavailable) on X server :0. Aug 3 09:07:54 mithlond kernel: [87817.766007] nouveau E[gnome-shell[1167]] failed to idle channel 0xcccc0000 [gnome-shell[1167]] Aug 3 09:07:57 mithlond kernel: [87820.766013] nouveau E[gnome-shell[1167]] failed to idle channel 0xcccc0000 [gnome-shell[1167]] Aug 3 09:07:59 mithlond kernel: [87822.766159] nouveau E[ PFIFO][0000:01:00.0] channel 4 [gnome-shell[1167]] unload timeout Behavior is the following... Screen freezes, mouse locks up. I can ssh into the machine and use it normally in every other aspect. The only thing that seems to be non-functional is the graphical desktop
Also, I should have included 01:00.0 VGA compatible controller: NVIDIA Corporation G98 [GeForce 8400 GS Rev.2] (rev a1) [pmyers@mithlond ~]$ lsmod | grep nouveau nouveau 989091 3 video 19052 1 nouveau mxm_wmi 12865 1 nouveau wmi 18697 2 mxm_wmi,nouveau i2c_algo_bit 13257 1 nouveau drm_kms_helper 50210 1 nouveau ttm 80402 1 nouveau drm 272504 5 ttm,drm_kms_helper,nouveau i2c_core 34242 5 drm,i2c_i801,drm_kms_helper,i2c_algo_bit,nouveau And the frequency with which I see this sort of lockup is approx once per day (on average. Some days it happens multiple times, other days not at all)
Same bug on Fedora 18 with nvidia nouveau E[gnome-shell[495]] failed to idle channel 0xcccc0000 in dmesg, with gnome3.
Four weeks ago I installed F20 and am *still* getting these hangs (every week or so), although less often than on F17 and F16 (sometimes every few hours, but then maybe none for a week or more). I have used the SSH trick on F17. Now on F20 whenever I notice the display pause inexplicably I quickly ctrl+alt+F2, login and 'shutdown -r now'. I prefer that to having sshd running and a port open in the firewall and a spare PC up "just in case" nouveau chucks a wobbly. There have been times when the keyboard also locked up before I could complete even that short sequence of steps. I still have an installation of F11 with the NVidia driver - I can run for hours :-o without a hang or error, just have to put up with nags saying my version of firefox is too old. Anyway, that hopefully indicates the hardware is ok. Today I got about 20mins work done (gedit, firefox, nautilus, terminal) before the display nearly locked up. Note that the journal shows thousands of lines with the "(unknown bits)" text, generated in just a few minutes. [troy@f20 ~]$ lspci -s 02:00.0 02:00.0 VGA compatible controller: NVIDIA Corporation G73 [GeForce 7600 GT] (rev a1) [troy@f20 ~]$ yum list installed '*nouveau*' xorg-x11-drv-nouveau.x86_64 1:1.0.9-2.fc20 @koji-override-0/$releasever [troy@f20 ~]$ yum list installed 'kernel' kernel.x86_64 3.11.10-301.fc20 @koji-override-0/$releasever kernel.x86_64 3.12.8-300.fc20 @updates [troy@f20 ~]$ journalctl -k -b -1 | grep 'nouveau' | head -50 14:13:01 f20 kernel: nouveau [ DEVICE][0000:02:00.0] BOOT0 : 0x04b100a2 14:13:01 f20 kernel: nouveau [ DEVICE][0000:02:00.0] Chipset: G73 (NV4B) 14:13:01 f20 kernel: nouveau [ DEVICE][0000:02:00.0] Family : NV40 14:13:01 f20 kernel: nouveau [ VBIOS][0000:02:00.0] checking PRAMIN for image... 14:13:01 f20 kernel: nouveau [ VBIOS][0000:02:00.0] ... checksum invalid 14:13:01 f20 kernel: nouveau [ VBIOS][0000:02:00.0] checking PROM for image... 14:13:02 f20 kernel: nouveau [ VBIOS][0000:02:00.0] ... appears to be valid 14:13:02 f20 kernel: nouveau [ VBIOS][0000:02:00.0] using image from PROM 14:13:02 f20 kernel: nouveau [ VBIOS][0000:02:00.0] BIT signature found 14:13:02 f20 kernel: nouveau [ VBIOS][0000:02:00.0] version 05.73.22.19.00 14:13:02 f20 kernel: nouveau [ PFB][0000:02:00.0] RAM type: GDDR3 14:13:02 f20 kernel: nouveau [ PFB][0000:02:00.0] RAM size: 256 MiB 14:13:02 f20 kernel: nouveau [ PFB][0000:02:00.0] ZCOMP: 379904 tags 14:13:02 f20 kernel: nouveau [ PTHERM][0000:02:00.0] FAN control: PWM 14:13:02 f20 kernel: nouveau [ PTHERM][0000:02:00.0] fan management: disabled 14:13:02 f20 kernel: nouveau [ PTHERM][0000:02:00.0] internal sensor: yes 14:13:02 f20 kernel: nouveau [ DRM] VRAM: 251 MiB 14:13:02 f20 kernel: nouveau [ DRM] GART: 512 MiB 14:13:02 f20 kernel: nouveau [ DRM] TMDS table version 1.1 14:13:02 f20 kernel: nouveau W[ DRM] TMDS table script pointers not stubbed 14:13:02 f20 kernel: nouveau [ DRM] DCB version 3.0 14:13:02 f20 kernel: nouveau [ DRM] DCB outp 00: 01000300 00000028 14:13:02 f20 kernel: nouveau [ DRM] DCB outp 01: 03000302 00000000 14:13:02 f20 kernel: nouveau [ DRM] DCB outp 02: 04011312 00000000 14:13:02 f20 kernel: nouveau [ DRM] DCB outp 03: 020223f1 00c0c080 14:13:02 f20 kernel: nouveau [ DRM] DCB conn 00: 0030 14:13:02 f20 kernel: nouveau [ DRM] DCB conn 01: 3161 14:13:02 f20 kernel: nouveau [ DRM] DCB conn 02: 0210 14:13:02 f20 kernel: nouveau [ DRM] DCB conn 03: 0211 14:13:02 f20 kernel: nouveau [ DRM] DCB conn 04: 0213 14:13:02 f20 kernel: nouveau [ DRM] Saving VGA fonts 14:13:02 f20 kernel: nouveau [ DRM] 0xD3EB: Parsing digital output script table 14:13:02 f20 kernel: nouveau [ DRM] 0xD426: Parsing digital output script table 14:13:02 f20 kernel: nouveau [ DRM] 2 available performance level(s) 14:13:02 f20 kernel: nouveau [ DRM] 0: core 560MHz shader 560MHz memory 700MHz voltage 1300mV fanspeed 31% 14:13:02 f20 kernel: nouveau [ DRM] 1: core 560MHz shader 560MHz memory 700MHz voltage 1300mV fanspeed 65% 14:13:02 f20 kernel: nouveau [ DRM] c: core 558MHz shader 558MHz memory 702MHz fanspeed 65% 14:13:02 f20 kernel: nouveau [ DRM] MM: using M2MF for buffer copies 14:13:02 f20 kernel: nouveau [ DRM] Setting dpms mode 3 on TV encoder (output 3) 14:13:02 f20 kernel: nouveau [ DRM] allocated 1600x1200 fb: 0x9000, bo ffff8800dfb1fc00 14:13:02 f20 kernel: fbcon: nouveaufb (fb0) is primary device 14:13:02 f20 kernel: nouveau [ DRM] 0xD3EB: Parsing digital output script table 14:13:02 f20 kernel: nouveau 0000:02:00.0: fb0: nouveaufb frame buffer device 14:13:02 f20 kernel: nouveau 0000:02:00.0: registered panic notifier 14:13:02 f20 kernel: [drm] Initialized nouveau 1.1.1 20120801 for 0000:02:00.0 on minor 0 14:32:02 f20 kernel: nouveau E[ PGRAPH][0000:02:00.0] (unknown bits 0x00000010) nsource: nstatus: 14:32:02 f20 kernel: nouveau E[ PGRAPH][0000:02:00.0] ch 1 [0x000ea000 Xorg[1907]] subc 4 class 0x009f mthd 0x0308 data 0x000c0633 14:32:02 f20 kernel: nouveau E[ PGRAPH][0000:02:00.0] (unknown bits 0x00000010) nsource: nstatus: 14:32:02 f20 kernel: nouveau E[ PGRAPH][0000:02:00.0] ch 1 [0x000ea000 Xorg[1907]] subc 4 class 0x009f mthd 0x0308 data 0x01150633 14:32:02 f20 kernel: nouveau E[ PGRAPH][0000:02:00.0] (unknown bits 0x00000010) nsource: nstatus: [troy@f20 ~]$ journalctl -k -b -1 | grep -c 'nouveau' 9597
I hereby retract my previous statement that the hangs are less frequent under F20. Yesterday: one hang after about 50 mins from boot. I killed Xorg and that got me going for the rest of the day. Today: almost continual hangs (about half a dozen in a few hours) - even after killing Xorg as soon as I logged back in, and even after a reboot. I did notice that while I stayed in a virtual terminal the nouveau driver was happy. I worked on some backups and disk images for a couple of hours without incident. So here I am back in F11 (running the NVidia driver) just to be sure the graphics card is ok. If there is anything else I can try under F20 to identify the problem, or other information required, I am happy to work on it.
This has now worsened to the point that sometimes even the login screen is affected - the keyboard still works so I can enter my password but the field does not reflect the fact that anything has been entered (a dot for each character). Even if the password field does display correctly, once logged in any windows I open are white. I have found that if for example I open terminal, I can type text and it will be actioned (eg "exit" and window closes). I have resorted to running vncserver and opening a remote desktop from my notebook (where I write this). This took a few days to establish as I had to discover and learn firewall-cmd and nmcli. What is quite bizarre is the gradual worsening of the problem to the point that it is now unusable except remotely. I have also run F17 and F11 over the last few days and F11 has no issue whilst F17 is ok for an hour or so as usual. I have looked at the journal for the startup and don't see anything obvious that could explain the worsening situation. My idea was that maybe there is a firmware file being loaded that is being corrupted. It seems like some sort of cumulative effect - each boot it gets worse.
Since vncserver (xvnc) doesn't allow me to authenticate admin apps (eg firewall), I tried x11vnc to get access to the console (:0). Not surprisngly x11vnc didn't help - the console displays but it does not properly respond to mouse and keyboard (I added -dk and -dp to the x11vnc command and watched the keyboards and mouse events arrive). As a test I opened terminal at the console, then setup x11vnc via virtual terminal, remoted in and positioned the mouse on the close window (top right) of the terminal window and clicked once. On the remote display nothing happened. Disconnected and stopped x11vnc. Went back to the console and after a refresh the terminal window vanished.
Just to make sure - this is only Gnome-shell problem, if you use different environment/login manager than it works OK? Does the same thing happen on a LiveUSB with updates applied? I personallly abaddoned the Gnome shell for various reasons, same with nvidia graphics ATM. Therefore I can not confirm this is a common problem.
I interpreted it as a nouveau problem (because it is the module emitting errors) which initially presents as appearing to cause the gnome shell to hang. Further investigation (comment 12) the windows on the console do seems to still function but the rendering of the graphical UI does not happen fully. For the first few weeks under F20 I had only intermitent problems and over time it has worsened such that the faulty rendering now occurs at every boot from the login screen (where typing in the password field is not reflected visually - comment 11). Whatever the problem is, it seems to only affect the console. Remotely I can use vncserver (display :1) without problem, but x11vnc (display :0 = console) does not accept mouse or keyboard events, or these are again not reflected graphically so I can't tell what is going on (comment 12).
I have updated to kernel 3.13.8-200.fc20 but the problem still persists. Prior to the update there were a couple of boots where the login password field rendered properly and I then had a few minutes of normal UI use once logged in.
Well it took a while but I eventually discovered Video Memory Test (VMT) which is like memtest but for video ram. I downloaded the ISO version (VMTCE) from sourceforge: http://sourceforge.net/projects/vmtce/files/ After completing the test there were 223,834 errors. Nice... not. Further investigation suggests nVidia might have switched the type of solder the year after my card was manufactured, due to high failure rates in notebooks: http://www.tgdaily.com/hardware-features/39045-nvidia-gpu-failures-caused-by-material-problem-sources-claim Anyway, drats, my problem is indeed a hardware error, most likely all those video ram solder joints have micro fractures.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora 'version' of '20'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 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 this bug is closed as described in the policy above. 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.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.