Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 578965 - [NV4e] nouveau driver does not work with geforce 6100
Summary: [NV4e] nouveau driver does not work with geforce 6100
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau
Version: 14
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Ben Skeggs
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: [cat:modesetting]
Depends On:
Blocks: F13Target
TreeView+ depends on / blocked
 
Reported: 2010-04-01 22:02 UTC by shmuel siegel
Modified: 2018-04-11 14:33 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 525905
Environment:
Last Closed: 2012-08-16 17:37:12 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)
xorg log file for pure noise on screen (34.31 KB, text/plain)
2010-04-17 22:08 UTC, shmuel siegel 		no flags Details
Xorg.log - No xorg.conf (53.60 KB, text/plain)
2011-06-02 10:37 UTC, Fdor 		no flags Details
Xorg.log - Nouveau forced (10.14 KB, text/plain)
2011-06-02 10:39 UTC, Fdor 		no flags Details
Xorg.log - nv forced (28.61 KB, text/plain)
2011-06-02 10:40 UTC, Fdor 		no flags Details
Xorg.log - No xorg.conf (70.38 KB, text/plain)
2011-06-02 10:57 UTC, Fdor 		no flags Details
Show Obsolete (1) View All

Description shmuel siegel 2010-04-01 22:02:20 UTC 
+++ This bug was initially created as a clone of Bug #525905 +++

Description of problem:
Basically the nouveau driver cause x to hang on my system.
For a preupgrade/anaconda install this cause anaconda to not work at all unless I set the xdriver to vesa.
For an installed system it means that I don't have X.
I will upload a dmesg and xorg.log showing problems with nouveau despite the xorg.conf using nv. I prefer to not generate an xorg.log for a xorg.conf using nouveau since it will be a lot harder to recover from that.

--- Additional comment from fedora.nu on 2009-09-26 18:30:46 EDT ---

Created an attachment (id=362789)
dmesg showing nouveau issue

--- Additional comment from fedora.nu on 2009-09-26 18:31:38 EDT ---

Created an attachment (id=362790)
xorg log for nv not working

--- Additional comment from bskeggs on 2009-09-26 19:25:46 EDT ---

For nouveau, can you update to at least kernel-2.6.31.1-46.fc12 and retry.

For nv, it's not going to work while nouveau has control of the hardware.  Boot with "nomodeset" in your boot options.

--- Additional comment from fedora.nu on 2009-09-27 06:35:12 EDT ---

updating to 48 did not change anything. Nomodeset does work, so at least I have a working x system now. It is still going to be a problem to upgraders.

--- Additional comment from bskeggs on 2009-09-27 07:08:50 EDT ---

Is that nomodeset with nv that works? Or nomodeset with nouveau?

--- Additional comment from fedora.nu on 2009-09-28 14:24:19 EDT ---

Actually with nomodeset I can use either driver.

--- Additional comment from bskeggs on 2009-09-28 18:17:38 EDT ---

Ok, well it looks like the latest kernel has actually fixed some of the known issues on your chipset then, and an issue seen in your kernel log you attached earlier.

So, are you able to post /var/log/Xorg.0.log from using nouveau with nomodeset and your /var/log/messages from trying to use nouveau without nomodeset.  Without nomodeset, do you see the plymouth boot screen and/or boot messages?  Or nothing at all when nouveau takes control?

--- Additional comment from fedora.nu on 2009-09-28 19:47:15 EDT ---

Created an attachment (id=362949)
xorg.log without nomodeset using nouveau. kernel 2.6.31.1-48.fc12.x86_64 

I don't claim to understand what I just saw. I rebooted into level 5 without the nomodeset. The modeset was done since I switched to proper screen resolution. Dmessage still reports the GPU lockup and the screen spent a few seconds with total noise. But then the cursor appeared over the noise and finally a real login screen. Maybe startx at init 3 is different and maybe I just didn't have enough patience for the driver to recover.

There are hundreds of lines in dmesg of the form
[drm] nouveau 0000:00:05.0: PFIFO_DMA_PUSHER - Ch 1
[drm] nouveau 0000:00:05.0: PFIFO_DMA_PUSHER - Ch 0
followed by
[drm] nouveau 0000:00:05.0: Failed to idle channel 1.  Prepare for strangeness..
[drm] nouveau 0000:00:05.0: PFIFO_DMA_PUSHER - Ch 0

--- Additional comment from bskeggs on 2009-10-08 20:03:36 EDT ---

What you seen was nouveau detecting a GPU lockup, and X switching off acceleration so it could still operate.  I'm not really sure what you're seeing, I've just tested a machine with the same chipset and it appears to be functioning correctly.  This is with 2.6.31.1-56.fc12, but, there were no nouveau changes since the version you tested and that version.

There were further fixes to various potentially-related areas of nouveau recently.  These would be available in http://koji.fedoraproject.org/koji/buildinfo?buildID=135765 if you wish to test.

--- Additional comment from darkwerdna on 2009-11-07 00:08:17 EST ---

that's the thing, I don't see anything my laptop screen remains completely blank. I copied the messages file completely blind

--- Additional comment from fedora-triage-list on 2009-11-16 08:00:04 EST ---


This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from clinton on 2010-01-13 23:54:46 EST ---


I'm having display corruption with FC12 and a GeForce 6150 card.  Not sure if the problem is related to this bug or not.   

00:05.0 VGA compatible controller: nVidia Corporation C51PV [GeForce 6150] (rev a2) (prog-if 00 [VGA controller])
        Subsystem: Micro-Star International Co., Ltd. K8NGM2 series
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 19
        Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
        Memory at d0000000 (64-bit, prefetchable) [size=256M]
        Memory at fc000000 (64-bit, non-prefetchable) [size=16M]
        Expansion ROM at feae0000 [disabled] [size=128K]
        Capabilities: <access denied>
        Kernel driver in use: nouveau
        Kernel modules: nouveau, nvidiafb


I also get a constant stream of the following messages in dmesg:

[drm] nouveau 0000:00:05.0: PFIFO_CACHE_ERROR - Ch 0/0 Mthd 0x0310 Data 0x010d7000
[drm] nouveau 0000:00:05.0: PFIFO_CACHE_ERROR - Ch 0/0 Mthd 0x0314 Data 0x00001000
[drm] nouveau 0000:00:05.0: PFIFO_CACHE_ERROR - Ch 0/0 Mthd 0x0318 Data 0x00001000
[drm] nouveau 0000:00:05.0: PFIFO_CACHE_ERROR - Ch 0/0 Mthd 0x031c Data 0x00001000
[drm] nouveau 0000:00:05.0: PFIFO_CACHE_ERROR - Ch 0/0 Mthd 0x0320 Data 0x000003ce
[drm] nouveau 0000:00:05.0: PFIFO_CACHE_ERROR - Ch 0/0 Mthd 0x0324 Data 0x00000101
[drm] nouveau 0000:00:05.0: PFIFO_CACHE_ERROR - Ch 0/0 Mthd 0x0328 Data 0x00000000
[drm] nouveau 0000:00:05.0: PFIFO_CACHE_ERROR - Ch 0/0 Mthd 0x0100 Data 0x00000000

--- Additional comment from clinton on 2010-01-13 23:56:33 EST ---

Created an attachment (id=383610)
Screen capture of the display corruption

Common display issues:
- Background get random noise
- Icons/buttons are the first to start with display corruption.

--- Additional comment from clinton on 2010-01-13 23:58:42 EST ---


I should have added the kernel version and x11 driver.  

[pulsar ~]$ rpm -qa | egrep -i 'nouveau|kernel-' | sort
kernel-PAE-2.6.31.9-174.fc12.i686
xorg-x11-drv-nouveau-0.0.15-17.20091105gite1c2efd.fc12.i686

--- Additional comment from awilliam on 2010-01-14 01:28:50 EST ---

clinton: please file a separate bug. thanks.
Comment 1 shmuel siegel 2010-04-01 22:04:50 UTC 
GPU lockup is being detected with f13 beta rc3 with a minimal install (no X)
Comment 2 shmuel siegel 2010-04-06 23:19:15 UTC 
2.6.33.1-24 still has this problem. In addition, after switching to text mode, udev hangs. Using athlon 3800+ and geforce 6100
Comment 3 Adam Williamson 2010-04-09 19:21:41 UTC 
Can we get your kernel and X logs? Can you also test with the latest kernel - http://koji.fedoraproject.org/koji/buildinfo?buildID=166151 ? Thanks.
Comment 4 shmuel siegel 2010-04-13 22:24:54 UTC 
As I said, minimal install (no X, therefore no X logs). Is there a way for me to get logs from a system that hangs in udev?
Comment 5 Adam Williamson 2010-04-14 18:55:38 UTC 
not particularly easily. i'm still not entirely clear what the bug is here? it's titled 'nouveau driver does not work', then you talk about 'GPU lockup', then udev hang 'after switching to text mode' (but if this is a minimal install it's *always* text mode)? confused.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 6 shmuel siegel 2010-04-17 22:08:43 UTC 
Created attachment 407321 [details]
xorg log file for pure noise on screen

failure for kernel 2.6.33.2-41.fc13.x86_64
xorg-x11-drv-nouveau-0.0.16-3.20100305git6b8b157.fc13.x86_64
xorg-x11-server-Xorg-1.8.0-4.fc13.x86_64
Comment 7 Andy 2010-04-18 01:33:48 UTC 
My laptop with the nvidia GPU died, I'm going to remove myself from this bug, I can no longer help.
Comment 8 shmuel siegel 2010-04-19 22:13:55 UTC 
I am receiving this message many times in dmesg when started with nomodeset. Is it relevant to my failure to bring up x on geforce 6100?
[drm] nouveau 0000:00:05.0: called without init
Comment 9 Ben Skeggs 2010-04-19 22:42:14 UTC 
nomodeset is not intended to work any longer in F13.
Comment 10 shmuel siegel 2010-04-22 23:38:51 UTC 
now i am getting these dnesg messages over and over
[drm] nouveau 0000:00:05.0: PFIFO_DMA_PUSHER - Ch 0
[drm] nouveau 0000:00:05.0: PFIFO_DMA_PUSHER - Ch 1
[drm] nouveau 0000:00:05.0: PFIFO_DMA_PUSHER - Ch 2

for kernel 2.6.33.2-57.fc13.x86_64 
x server xorg-x11-server 1.8.0-6.fc13 
[    20.353] (--) PCI:*(0:0:5:0) 10de:0242:1462:7252 nVidia Corporation C51G [GeForce 6100] rev 162, Mem @ 0xfd000000/16777216, 0xd0000000/268435456, 0xfc000000/16777216, BIOS @ 0x????????/131072
[    20.398] (II) LoadModule: "nouveau"
[    20.400] (II) Loading /usr/lib64/xorg/modules/drivers/nouveau_drv.so
[    20.400] (II) Module nouveau: vendor="X.Org Foundation"
[    20.400] 	compiled for 1.7.99.901, module version = 0.0.15
[    20.401] 	Module class: X.Org Video Driver
[    20.401] 	ABI class: X.Org Video Driver, version 7.0
Comment 11 shmuel siegel 2010-04-30 02:31:38 UTC 
kernel 73 and the april 28 version of the nouveau driver do not solve this problem. Is there anything that I can provide to help debugging this? This machine work in f12 prior to march.
Comment 12 Adam Williamson 2010-04-30 19:55:14 UTC 
This bug was discussed at the 2010/04/30 blocker review meeting. 

It looks like this is a single-system (may be single-adapter) bug; there's no duplicate reports we can find. We don't usually consider such issues blockers, unfortunately, as it's not really possible to fix every single such issue and still stick to a plausible release schedule. Sorry about this. If Ben does manage to get a fairly safe fix available by Tuesday, we can consider taking it for the final release. Thanks.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 13 shmuel siegel 2010-05-11 22:32:02 UTC 
nomodeset is working now. I have a working X
Comment 14 Ben Skeggs 2010-05-12 01:11:58 UTC 
nomodeset is causing you to get the vesa driver instead in all likelihood, nouveau no longer supports nomodeset.
Comment 15 Fdor 2011-06-02 10:35:17 UTC 
The bug is still in fedora 14.

I've tested 3 ways:

1) Without xorg.conf: Vesa driver is automatically selected. Works, but video is slow. I can't change to my prefered hand-made resolution (tested with "xrandr" command).

2) With nouveau driver forced: Doesn't work (X doesn't start).

3) With nv driver forced: Works, but video is even worse than with the first way (vesa driver). Video slow. I can't change to my prefered hand-made resolution. 

For 2) and 3) ways, I've used a minimal xorg.conf file. For 2) way:

  Section "Device"
  Identifier "n"
  Driver "nouveau"
  EndSection

For 3) way:

  Section "Device"
  Identifier "n"
  Driver "nv"
  EndSection

I'm attaching xorg log files for every way.

I had to add "nomodeset" to kernel booting parameters. Without "nomodeset", the kernel doesn't boot (it just hangs up).

Am I doing something wrong? Or is this bug still unfixed?

(P.S. Please change the bug Status from "NEW" to "CONFIRMED" or something. Also, update bug Version from "13" to "14")
Comment 16 Fdor 2011-06-02 10:37:57 UTC 
Created attachment 502492 [details]
Xorg.log - No xorg.conf
Comment 17 Fdor 2011-06-02 10:39:31 UTC 
Created attachment 502493 [details]
Xorg.log - Nouveau forced
Comment 18 Fdor 2011-06-02 10:40:24 UTC 
Created attachment 502494 [details]
Xorg.log - nv forced
Comment 19 Fdor 2011-06-02 10:57:15 UTC 
Created attachment 502496 [details]
Xorg.log - No xorg.conf

Oops, I atached the log file for other graphic card.
This is the good one.
Comment 20 Adam Williamson 2011-06-02 14:52:56 UTC 
Thanks for the update. If the vesa driver is selected by default, it sounds like the X devs are aware of this problem and blacklisting the adapter to avoid it...

Have you had a chance to test with F15 yet?
Comment 21 Bug Zapper 2011-06-02 15:44:42 UTC 
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  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 '13'.

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 13'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 13 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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
Comment 22 Fdor 2011-06-02 19:05:15 UTC 
I'll probably upgrade to F15 next days, I'll tell you. Thanks.
Comment 23 Fdor 2011-07-04 14:30:07 UTC 
Fixed in Fedora 15.

I've:
- upgraded to Fedora 15.
- removed "nomodeset" from kernel booting parameters.
- forced "nouveau" driver in xorg conf.

A minor problem:
- While booting, the graphical boot is shown for some seconds (~2 sec.).
- Then, the screen goes into black (my monitor goes into power saving mode) until the end of the booting process.
- Then, the screen is changed from black to the graphical login (gdm).
- Finally, I enter username and password, kde is loaded correctly (screen doesn't change its mode nor goes into black), and I can work perfectly with all apps.

I know the graphical booting is complex, so I consider the black screen problem as minor. Hope it will be fixed.

Thanks
Comment 24 Matěj Cepl 2011-07-18 00:45:38 UTC 
Reporter, could you please confirm the comment 23. Has this been fixed in F15?

Thank you
Comment 25 shmuel siegel 2011-07-19 18:55:20 UTC 
Sorry, I no longer have the relevant hardware. It seems that the only other person who was bothered by this problem is happy now. So feel free to close the bug.
Comment 27 Fedora End Of Life 2012-08-16 17:37:16 UTC 
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached 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" (top right of this page) 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
Note You need to log in before you can comment on or make changes to this bug.