Bug 901816 - artifacts/freezeups in graphical mode with nouveau and GeForce 6150SE
Summary: artifacts/freezeups in graphical mode with nouveau and GeForce 6150SE
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau
Version: 20
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ben Skeggs
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-01-19 13:57 UTC by Andre Robatino
Modified: 2015-06-29 11:44 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-06-29 11:44:25 UTC
Type: Bug

Attachments (Terms of Use)

Description Andre Robatino 2013-01-19 13:57:57 UTC
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:

Comment 1 Andre Robatino 2013-01-26 16:23:51 UTC
Same problem with the 3.7.4-204.fc18.x86_64 kernel and nouveau. Proprietary driver works fine.

Comment 2 chen haochuan 2013-02-01 11:33:45 UTC
I disabled intel VT-d in UEFI, and it works for me. I remember I have seen a same bug of f18 beta.

Comment 3 Andre Robatino 2013-02-04 21:37:24 UTC
My box is BIOS with an AMD CPU. I can't tell if there's any corresponding BIOS setting.

Comment 4 Andre Robatino 2013-02-05 05:04:48 UTC
Same problem with 3.7.5-201.fc18.x86_64 and nouveau.

Comment 5 Andre Robatino 2013-02-16 02:10:05 UTC
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.

Comment 6 Lassi Ylikojola 2013-02-16 19:24:57 UTC
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-               @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:

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.

Comment 7 Andre Robatino 2013-02-16 19:37:07 UTC
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.

Comment 8 Andre Robatino 2013-03-02 20:42:58 UTC
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

Comment 9 Andre Robatino 2013-03-21 14:00:21 UTC
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).

Comment 10 Andre Robatino 2013-04-24 13:14:57 UTC
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?

Comment 11 Joachim Frieben 2013-05-04 16:15:15 UTC
Issue still applies to a fully updated F19 system including kernel-3.9.0-301.fc19.

Comment 12 Andre Robatino 2013-05-04 16:44:11 UTC
Good to know someone else sees this. Changing the Version back to 19.

Comment 13 Andre Robatino 2013-05-16 08:21:02 UTC
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.)

Comment 14 drkibitz 2013-07-07 09:21:52 UTC
- 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.

Comment 15 Andre Robatino 2013-07-07 09:46:48 UTC
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.

Comment 16 cornel panceac 2013-07-10 19:58:14 UTC
this seems a "natural" evolution of this:


btw, on f19 is happening also on 32 bits.

Comment 17 Vern Clark 2013-07-23 04:19:56 UTC
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.

Nvidia GeForce 6150SE nForce 430 
AMD Athlon(tm) II X2 250 Processor × 2

Comment 18 Guido Mureddu 2013-07-27 17:02:14 UTC
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

Comment 19 Vern Clark 2013-07-28 03:08:11 UTC
The only way it will work, is the use "modeset=0". 
Even then , once in a while it fails.

Comment 20 cornel panceac 2013-12-26 07:38:58 UTC
This still occurs on kernel-PAE-3.12.5-302.fc20.i686. It is not always. however. just sometimes.

Comment 21 Andre Robatino 2013-12-26 15:38:13 UTC
Experienced a total freeze in F20 x86_64 (clean install) shortly after temporarily switching from nvidia back to nouveau.

Comment 22 T-Gergely 2013-12-31 12:55:51 UTC
(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

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, 

Comment 23 Andre Robatino 2013-12-31 17:45:27 UTC
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

Comment 24 T-Gergely 2014-01-06 20:45:21 UTC
(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?

Comment 25 Andre Robatino 2014-01-06 20:48:12 UTC
(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.

Comment 26 MaxiPunkt 2014-01-27 21:02:39 UTC
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:

Comment 27 Bruce Petrie 2014-10-10 18:04:01 UTC

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


$ 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.

Comment 28 Fedora End Of Life 2015-05-29 08:51:47 UTC
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.

Comment 29 Fedora End Of Life 2015-06-29 11:44:25 UTC
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

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.