Description of problem: When using the nouveau driver and a 3.7 kernel, right when the system is going into graphical mode, the system freezes completely (often with a periodic pattern on the display). It doesn't respond to ssh or even ping. It comes up normally with the 3.6.10 and 3.6.11 kernels. If I use the nomodeset boot option, it comes up but only in 1024x768 mode (my display is 1920x1080). If I use the proprietary Nvidia driver, it comes up normally with all kernels. My video hardware is GeForce 6150SE nForce 430. Currently running the 3.7.2-201.fc18.x86_64 kernel with the proprietary Nvidia driver. I tried the -204 updates-testing kernel with nouveau and it freezes the same way. Version-Release number of selected component (if applicable): 3.7.* kernel How reproducible: always
Same problem with the 3.7.4-204.fc18.x86_64 kernel and nouveau. Proprietary driver works fine.
I disabled intel VT-d in UEFI, and it works for me. I remember I have seen a same bug of f18 beta.
My box is BIOS with an AMD CPU. I can't tell if there's any corresponding BIOS setting.
Same problem with 3.7.5-201.fc18.x86_64 and nouveau.
Same with kernel-3.7.6-201.fc18.x86_64 and nouveau, though it still works with the proprietary driver. On the other hand, kernel-3.7.7-201.fc18.x86_64 doesn't work in graphical mode even with the proprietary driver, although the machine is not frozen and VTs work. So I'm gradually running out of graphical options - kernel-3.6.11-3.fc18.x86_64 is the last one that works with nouveau, and kernel-3.7.6-201.fc18.x86_64 the last that works with nvidia.
I started having these problems on Saturday 16.02.2013 after updating the following packages: yum history info 229 Loaded plugins: langpacks, presto, refresh-packagekit Transaction ID : 229 Begin time : Sat Feb 16 00:23:38 2013 Begin rpmdb : 2556:33d6c9aa7e834bc550696b8ec3f75f36d7d6e0bb End time : 00:24:22 2013 (44 seconds) End rpmdb : 2556:1357e381a0697130b281865f8287344b584015e7 User : Lassi Ylikojola Return-Code : Success Command Line : update Transaction performed with: Installed rpm-4.9.1.3-7.fc17.x86_64 @updates Installed yum-3.4.3-30.fc17.noarch @updates Installed yum-metadata-parser-1.1.4-6.fc17.x86_64 @koji-override-0/$releasever Installed yum-presto-0.7.3-1.fc17.noarch @koji-override-0/$releasever Packages Altered: Updated btparser-0.22-1.fc17.x86_64 @updates Update 0.25-1.fc17.x86_64 @updates Updated firefox-18.0-1.fc17.x86_64 @updates Update 18.0.2-1.fc17.x86_64 @updates Updated nspr-4.9.4-1.fc17.x86_64 @updates Update 4.9.5-1.fc17.x86_64 @updates Updated nspr-devel-4.9.4-1.fc17.x86_64 @updates Update 4.9.5-1.fc17.x86_64 @updates Updated nss-3.14.1-3.fc17.x86_64 @updates Update 3.14.2-2.fc17.x86_64 @updates Updated nss-devel-3.14.1-3.fc17.x86_64 @updates Update 3.14.2-2.fc17.x86_64 @updates Updated nss-softokn-3.14.1-3.fc17.x86_64 @updates Update 3.14.2-3.fc17.x86_64 @updates Updated nss-softokn-devel-3.14.1-3.fc17.x86_64 @updates Update 3.14.2-3.fc17.x86_64 @updates Updated nss-softokn-freebl-3.14.1-3.fc17.i686 @updates Updated nss-softokn-freebl-3.14.1-3.fc17.x86_64 @updates Update 3.14.2-3.fc17.i686 @updates Update 3.14.2-3.fc17.x86_64 @updates Updated nss-softokn-freebl-devel-3.14.1-3.fc17.x86_64 @updates Update 3.14.2-3.fc17.x86_64 @updates Updated nss-sysinit-3.14.1-3.fc17.x86_64 @updates Update 3.14.2-2.fc17.x86_64 @updates Updated nss-tools-3.14.1-3.fc17.x86_64 @updates Update 3.14.2-2.fc17.x86_64 @updates Updated nss-util-3.14.1-1.fc17.x86_64 @updates Update 3.14.2-2.fc17.x86_64 @updates Updated nss-util-devel-3.14.1-1.fc17.x86_64 @updates Update 3.14.2-2.fc17.x86_64 @updates Updated xulrunner-18.0-6.fc17.x86_64 @updates Update 18.0.2-1.fc17.x86_64 @updates history info I was using the nvidia driver. Nouveau does not work also(this might be due to my xorg.conf. I did make a new one with X -configure) I tested with following kernels: vmlinuz-3.6.11-5.fc17.x86_64 vmlinuz-3.7.3-101.fc17.x86_64 vmlinuz-3.7.6-102.fc17.x86_64 I'm now using fbdev since i can boot into graphical mode with it. So is it possible that those nss* packages are somehow related to this.
The akmod-nvidia-304.64-6.fc18.x86_64 update just pushed from Rpmfusion fixed the problem with 3.7.7 and the nvidia driver.
Same problem with kernel-3.8.1-201.fc18.x86_64 and nouveau. When booting into a recent kernel using nouveau and the nomodeset boot option (which only gives 1024x768 resolution), xrandr says xrandr: Failed to get size of gamma for output default Screen 0: minimum 640 x 480, current 1024 x 768, maximum 1024 x 768 default connected 1024x768+0+0 0mm x 0mm 1024x768 61.0* 800x600 61.0 640x480 60.0 while normal output (using the nvidia driver) is Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 4096 x 4096 VGA-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm 1920x1080 60.0*+ 1680x1050 60.0 1440x900 59.9 1280x1024 75.0 60.0 1280x960 60.0 1152x864 75.0 1024x768 75.0 70.1 60.0 800x600 75.0 72.2 60.3 56.2 640x480 75.0 72.8 59.9
Somewhat similar behavior with the 64-bit Gnome 3.8 Test Day Live image. If I boot with the default option, it shuts itself down after a few seconds. If I add "nomodeset" to the boot options, it boots up, but only in 1024x768, and in this case the xrandr output looks essentially the same as above (I didn't check if it was identical, but the gamma line is the same).
With the testday-2013-04-23-x86_64.iso image, it boots normally and appears to be using normal resolution (though I forgot to check exactly what it was, I can check or run any other tests if necessary). In F18, the same problem continues (up to the latest 3.8.8 kernel) with not coming up in graphical mode. Was there a fix in F19 that would account for this?
Issue still applies to a fully updated F19 system including kernel-3.9.0-301.fc19.
Good to know someone else sees this. Changing the Version back to 19.
In F18, with the latest (3.9.2-200.fc18.x86_64) kernel, I can get into graphical mode with nouveau. Unfortunately, when I ran glxgears and quit by clicking on the X in the upper right (the first thing I did after logging in), it causes the same freeze as happened during boot. Using the nvidia driver, it works fine. (I probably should have checked if it worked normally with nouveau and the nomodeset option, in the resulting 1024x768 mode.)
Info: - NVIDIA GeForce 6150 SE nForce 430 - Fedora 19 (Schrodinger's Cat) - Standard Gnome Desktop I can get into Graphical mode with Nouveau, but there are many problems: lag, graphical artifacts (green and orange boxes), and with certain applications (Firefox, gnome-boxes, and The firewall utility) complete freezes with diagonal lines. The freeze is immediate with gnome-boxes, but occurs after some time of usage with any application. The freeze also occurs intermittently directly after login screen, it's a 60/40 chance of getting to a unfrozen interface. The artifacts are also persistent in an unfrozen interface. I can confirm it is a problem with nouveau. Before writing this, I just installed the nVidia 304.xx driver set from rpmfusion, and Gnome 3 is now working like a dream, actually faster and smoother than ever.
I was able to do a clean F19 install on my machine, but installed the nvidia 304.xx driver ASAP without running anything except a gnome terminal. Have not tested yet to see how bad the artifacts/freezeups are. Changing the Summary. If anyone sees this with 32-bit as well, I'll change the Hardware to "All", it's probably not just 64-bit.
this seems a "natural" evolution of this: https://bugzilla.redhat.com/show_bug.cgi?id=901816 btw, on f19 is happening also on 32 bits.
On a F19 KDE I have the same as the orignal report of freeze right after plasma starts to display, then a unreadable pixelated display is presented. Using: Nvidia GeForce 6150SE nForce 430 AMD Athlon(tm) II X2 250 Processor × 2
I can confirm this bug is still present in Fedora 19 64-bit, using Gnome. Whenever I try to launch some applications (Firefox, in particular; nothing ever goes wrong if I use Chrome or Epiphany/Web) the system freezes completely, and shows some kind of periodic, unintelligible pattern on the screen. Video card: Nvidia GeForce 6150SE nForce 430
The only way it will work, is the use "modeset=0". Even then , once in a while it fails.
This still occurs on kernel-PAE-3.12.5-302.fc20.i686. It is not always. however. just sometimes.
Experienced a total freeze in F20 x86_64 (clean install) shortly after temporarily switching from nvidia back to nouveau.
(In reply to Andre Robatino from comment #21) Confirmed. I use xfce. Random freezes when using apps (e.g. Firefox), instant freeze when running eg. compiz-manager. On freezing, diagonal lines are displayed as mentioned by drkibitz. NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) AMD Phenom(tm) II X4 840 Processor kernel-3.12.5-302.fc20.x86_64 Alas, no luck with kmod-nvidia-304xx-3.12.5-302.fc20.x86_64-304.117-1.fc20.1. x86_64 either: random freezes with lightdm (login, user-switcing, Ctrl+Alt+Fx switching). Sometimes the resulation(?) changes to lower, but the framebuffer(?) seems not to follow, so that I can see part of the logical screen with lined patterns, and I can see what I type in the terminal and I can choose File/Quit in Firefox. Should I disable framebuffer? Can you share your working nvidia version, configuration, grub2 linux line, please?
akmod-nvidia-304xx-304.117-1.fc20.x86_64 kmod-nvidia-304xx-3.12.5-302.fc20.x86_64-304.117-1.fc20.1.x86_64 kernel-3.12.5-302.fc20.x86_64 C61 [GeForce 6150SE nForce 430] AMD Athlon(tm) Processor LE-1640 linux /vmlinuz-3.12.5-302.fc20.x86_64 root=/dev/mapper/fedora_compaq--pc-root ro vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora_compaq-pc/swap rd.lvm.lv=fedora_compaq-pc/root nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off
(In reply to Andre Robatino from comment #23) Thank you. The problem with lightdm user switching still remained. Do you use gdm and Gnome instead of my using of lightdm and Xfce?
(In reply to T-Gergely from comment #24) > (In reply to Andre Robatino from comment #23) > > Thank you. The problem with lightdm user switching still remained. > Do you use gdm and Gnome instead of my using of lightdm and Xfce? Yes, I'm using gdm and GNOME. Haven't tested any other DE on F20 so far.
Same on my girlfriends computer, using FC20 (x86_64) & nouveau-driver. A normal attempt to login (KDE) completely freezes the system. Login in "rescue-mode" does work. # lspci | grep -i vga 00:0d.0 VGA compatible controller: NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) It's an onboard-card on a BIOSTAR-mainboard. Looks quite similar to this bug, which was reported 3 years ago: https://bugzilla.redhat.com/show_bug.cgi?id=679619
FOUND WORKAROUND !! I have a eMachines EL1331 which has been running F20 x86_64 with nouveau. It has the GeForce 6150SE onboard graphics chip set. When I first installed F20, it exhibited the freezes described in this bug and bug 905629. I struggled with it for some time and eventually stopped having issues. Unfortunately, I had forgotten what I did to fix the problem originally. Recently did a yum update to kernel 3.16.3-200.fc20.x86_64 and the problem was almost always present, Could not ping the system and had the wavy lines on the display others have seen. During a login using gnome or kde, the system would lock up or shortly after logging in the system would lock up while some graphics updates were occuring. Got so frustrated with it to the point where I reset the BIOS to defaults and reloaded F20 from DVD since the system had crashed during a yum update. Before updating using yum using the original DVD image, the system was somewhat unstable meaning it would sometimes work and sometimes freeze. Once I ran yum upgrade, it went to nearly 100% failure rate. Tried nomodset, modset=0, nouveau.agpmode=0 and played with BIOS Frame Buffer Size with no joy. I removed all those changes. EVENTUAL WORKAROUND: In Phoenix-Award BIOS, go to Advanced Chipset Features and disable Spread Spectrum. The frame buffer size setting in that screen is set to 256MB. The system has 4 GB of RAM. $ cat cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 127 model name : AMD Athlon(tm) Processor 2850e stepping : 2 cpu MHz : 800.000 cache size : 512 KB 00:0d.0 VGA compatible controller: NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) Linux el1331.localdomain 3.16.3-200.fc20.x86_64 #1 SMP Wed Sep 17 22:34:21 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux xorg-x11-drv-nouveau-1.0.9-2.fc20.x86_64 $ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.16.3-200.fc20.x86_64 root=/dev/mapper/fedora_el1331-root ro vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora_el1331/swap rd.lvm.lv=fedora_el1331/root rhgb quiet LANG=en_US.UTF-8 Hope this can help someone else as this is a really frustrating problem.
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.