Bug 582472 - blank screen after boot of livecd with nouveau and new nvidia card
Summary: blank screen after boot of livecd with nouveau and new nvidia card
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau
Version: 13
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Ben Skeggs
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-04-15 05:13 UTC by stephen
Modified: 2011-06-05 22:15 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-06-05 22:15:19 UTC
Type: ---

Attachments (Terms of Use)
dmesg after modprobe nouveau modeset=1 (38.66 KB, text/x-log)
2010-05-15 21:47 UTC, Emanuel Rietveld
no flags Details
hardware setup (lspci -vv) (27.76 KB, text/x-log)
2010-05-15 21:54 UTC, Emanuel Rietveld
no flags Details

Description stephen 2010-04-15 05:13:17 UTC
Description of problem:
When booting the livecd for Fedora beta (the official one or http://adamwill.fedorapeople.org/gfx_test_week_20100412/gfx_test_week_20100412_x86-64.iso) with a newer NVIDIA chip (Quatro FX 380M on a HP elitebook 8440w) a blank screen occurs after loading the nouveau driver. Changing the boot options (removing quiet rhgb and adding 3) doesn't seem to help get any further in diagnosing the problem.

Version-Release number of selected component (if applicable):
NVIDIA chip Quatro FX 380M on HP elitebook 8440w
Fedora 13 beta

Steps to Reproduce:
1. Boot livecd (with either iso mentioned above -- official beta or test week) with 380M NVIDIA chip.
Actual results: 
Booting to blank screen that can't be exited out.

Expected results: Boot into livecd desktop in order to install the system, or boot into a low graphics mode so installation can occur and binary driver can be installed later. 

Additional info: The chip works fine with the most recent NVIDIA binary (195.36.15) on ubuntu 9.10. Log files cannot be retrieved as runtime 3 also seems to not boot into text mode with this problem.

Comment 1 Ben Skeggs 2010-04-15 05:24:10 UTC
Can you boot OK with "nomodeset 3"?  If so, you *might* have some luck getting logs out of it by running "modprobe -r nouveau; modprobe nouveau modeset=1" from the console after that.

The screen will probably blank out still etc, but you could maybe switch to another console and save logs blindly, or it may survive in /var/log/messages after reboot.

Comment 2 stephen 2010-04-15 05:58:16 UTC
"nomodeset 3" worked for booting into text, but after screen goes blank from running "modprobe -r nouveau; modprobe nouveau modeset=1", I can't get to a console. Neither Ctrl+Alt+Bckspace or Ctrl+Atl+F1 work. Is there another way to get back to the console so I can attempt to get the log? 

After reboot, I don't get the errors in /var/log/messages associated with the previous exercise (it would seem). However the messages related to nouveau during boot in /var/log/messages are:

localhost kernel: [drm] nouveau 0000:01:00.0: failed to evaluate _DSM: 5
localhost kernel: [drm] nouveau 0000:01:00.0: Detected an NV50 generation card (0x0a8e00a2)
localhost kernel: [drm] Initialized nouveau 0.0.16 20090420 for 0000:01:00.0 on minor 0

Not sure it is recognizing the right generation of chip (mine is a Quatro FX 380M, not sure that is NV50 generation).

Comment 3 Ben Skeggs 2010-04-15 06:05:40 UTC
You definitely won't be able to see a console, but if you alt+fn to another console you can *maybe* (well, usually, things have to be very very dead for this to fail) login blindly and run "dmesg > dmesg.log".

It's correctly detected your card, from the driver's point of view not much has changed since the original GeForce 8 chip (NV50) and it treats them as such.

Comment 4 stephen 2010-04-15 06:18:34 UTC
Giving this a try, but want to make sure I get it right. So I boot with livecd as before (nomodeset 3) and then run "modprobe -r nouveau; modprobe nouveau modeset=1", then when it goes blank, alt+fn to get a new console and login blindly and run dmesg > dmesg.log. Then I reboot with the livecd and look at that file? Getting a few hours of sleep so will be a little bit before results are posted.

Comment 5 stephen 2010-04-15 15:20:59 UTC
How do I get the dmesg.log after running this? How do i get the network to start or some other method of saving that file?

Comment 6 Ben Skeggs 2010-04-28 05:38:51 UTC
Any chance of you doing an install at all?  From a LiveCD will be tricky as no logs will be saved.

Comment 7 Emanuel Rietveld 2010-05-15 21:47:05 UTC
Created attachment 414293 [details]
dmesg after modprobe nouveau modeset=1

Comment 8 Emanuel Rietveld 2010-05-15 21:54:09 UTC
Created attachment 414294 [details]
hardware setup (lspci -vv)

I have the same issue in red hat enterprise linux 6 beta. Install dvd, boot.iso, pxe images, all have the same issue. The screen is blank. With nomodeset 3 everything works (only tried text mode).

I logged in remotely via ssh and performed the procedure "modprobe -r nouveau; modprobe nouveau modeset=1" and captured the dmesg log as requested.

Is there anything else I can do to help?

Comment 9 Ben Skeggs 2010-05-17 00:05:57 UTC
Thankyou for that!  Okay, this looks fairly obvious, for once the display engine error reporting came in handy :)

It looks like the modeline we're using for your display may be very wrong.  I have a strong suspicion I know which bug this is, and the patch was posted on a mailing list recently.

But to confirm, can I see the same log but with "modprobe -r nouveau; modprobe drm debug=15; modprobe nouveau modeset=1", and also the contents of /sys/class/drm/card0/card0-CONNECTOR_NAME/edid just in case it's not the bug I suspect :)

Comment 10 Ben Skeggs 2010-05-17 00:07:51 UTC
Maybe even easier, can you boot with "video=1024x768@75" in your options and see if that helps any.

Comment 11 Emanuel Rietveld 2010-05-17 05:42:20 UTC
I can confirm it boots fine with video=1024x768@75 in the kernel line instead of nomodeset (only tried text mode). 

If you need the debug log anyway let me know.

Comment 12 Ben Skeggs 2010-05-17 23:01:12 UTC
Great!  Thank you.

kernel- (http://koji.fedoraproject.org/koji/taskinfo?taskID=2191529) should work without additional options.

Comment 13 Bug Zapper 2011-06-02 15:21:22 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: 

Comment 14 Ben Skeggs 2011-06-05 22:15:19 UTC
This was actually fixed long ago, closing.

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