Bug 746929

Summary: nVidia NVS 300 -- won't boot
Product: Red Hat Enterprise Linux 6 Reporter: Tomas Jamrisko <tjamrisk>
Component: kernelAssignee: Ben Skeggs <bskeggs>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: high    
Version: 6.2CC: arthur.huillet+redhat_bugzilla, bskeggs, gasmith, kzhang, martin.wilck, rdassen, syeghiay, tjamrisk, tpelka
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: kernel-2.6.32-244.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 747034 (view as bug list) Environment:
Last Closed: 2012-06-20 07:58:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 727267    
Attachments:
Description Flags
Screen of what happens at boot with NVS 300
none
with drm.debug=14 as kernel option
none
dmesg output
none
Probably the more useful output
none
mistake, too many tabs, wrong bug none

Description Tomas Jamrisko 2011-10-18 09:59:58 UTC
Description of problem:

Attempting to boot with nVidia NVS 300 results in (see attachment)


Version-Release number of selected component (if applicable):

RHEL6.2-20111016.n.0



How reproducible:

Always 

Steps to Reproduce:
1. Get a NVS 300
2. Boot
  
Actual results:
(see attachment)

Expected results:
Regular boot

Additional info:

The picture is from fedora 16 beta, booting RHEL62 resulted in 
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128, RAW EDID: [unreadable, font had same color as background]

[drm] nouveau 0000:0f:00.0: DDC responded, but no EDID for DP-1

Comment 1 Tomas Jamrisko 2011-10-18 10:00:55 UTC
Created attachment 528765 [details]
Screen of what happens at boot with NVS 300

Comment 3 Tomas Pelka 2011-10-18 15:46:09 UTC
Created attachment 528836 [details]
with drm.debug=14 as kernel option

Do we have a chance how to record this messages during boot time (booting from live).

Comment 4 Ben Skeggs 2011-10-19 08:06:53 UTC
Can you boot with "drm.debug=14 log_buf_len=1M", and try to ssh in and save the dmesg output somehow?

Also, this particular monitor is known working on other cards without EDID issues?

Comment 5 Tomas Pelka 2011-10-19 08:31:43 UTC
(In reply to comment #4)
> Can you boot with "drm.debug=14 log_buf_len=1M", and try to ssh in and save the
> dmesg output somehow?
> 

Ben I don't think this will work, since the sshd will not start, this issue precedes the start of sshd.

Do we have any other way how to get longer log?

> Also, this particular monitor is known working on other cards without EDID
> issues?

We can definitely try older monitor.

Comment 6 Ben Skeggs 2011-10-19 08:43:36 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > Can you boot with "drm.debug=14 log_buf_len=1M", and try to ssh in and save the
> > dmesg output somehow?
> > 
> 
> Ben I don't think this will work, since the sshd will not start, this issue
> precedes the start of sshd.
You can boot with "drm.debug=14 log_buf_len=1M nomodeset 3", wait for sshd to start, then "modprobe -r nouveau; modprobe nouveau modeset=1".

If you still can't ssh in after this (if the system is hung hard), you can use netconsole, and start it before the modprobe nouveau step.

> 
> Do we have any other way how to get longer log?
> 
> > Also, this particular monitor is known working on other cards without EDID
> > issues?
> 
> We can definitely try older monitor.
Well, if this monitor works without errors with other cards/drivers, it should work with nouveau too :)  In any case nouveau shouldn't be taking the whole system down!

Comment 7 Tomas Jamrisko 2011-10-19 14:42:13 UTC
Thanks, those parameters work, for dmesg output see attachment (dmesg.out)

Comment 8 Tomas Jamrisko 2011-10-19 14:42:49 UTC
Created attachment 529016 [details]
dmesg output

Comment 9 Tomas Jamrisko 2011-10-19 15:10:15 UTC
Created attachment 529023 [details]
Probably the more useful output

Forgot to try loading nouveau before, sorry about that -- the hopefully actually useful output

Comment 10 Tomas Jamrisko 2011-10-19 15:16:50 UTC
Created attachment 529025 [details]
mistake, too many tabs, wrong bug

The previous output wasn't very useful (didn't even try to load nouveau drivers)

Comment 11 Ben Skeggs 2011-10-19 22:40:31 UTC
Hmm, interesting.  From the logs it doesn't look like the system should have been hung, just no proper screen output after nouveau has initialised.

Nouveau is failing to detect any displays due to, it looks like, the monitor's EDID being broken.  Are you able to test with another known-working NVIDIA GPU (and perhaps ATI or something if that fails still), and confirm the monitor works correctly there?

The next big issue I notice is that this card can somehow manage to drive DP, VGA and DVI natively all from the same connector.  This is something I haven't come across yet, and would very much like to get my hands on this hw to implement it.

Comment 12 Tomas Jamrisko 2011-10-20 09:28:45 UTC
The system isn't completely hung, ssh works just fine, the only thing that seems to be frozen after loading the driver is the screen.

The monitor works well (doesn't crash, displays what's required) with Quadro 2000,  Quadro FX 380 and Intel HD graphics (didn't test other cards). 

Results of having a different monitor connected (which usually works fine) were the same (didn't boot, EDID checksum is invalid, remainder is 128 RAW EDID...).

There is also a similar bug with NVS 450 ( https://bugzilla.redhat.com/show_bug.cgi?id=747034 ). Except that nvs 450 doesn't fail so early and doesn't have the connector at all. 

Both boot properly with nomodeset parameter (should have probably mentioned earlier)

Comment 13 Ben Skeggs 2011-10-20 09:40:18 UTC
(In reply to comment #12)
> The system isn't completely hung, ssh works just fine, the only thing that
> seems to be frozen after loading the driver is the screen.
Yep, nouveau thinks nothing's connected, so never does a modeset, leaving whatever was there before - which is VGA text mode in this case.

> 
> The monitor works well (doesn't crash, displays what's required) with Quadro
> 2000,  Quadro FX 380 and Intel HD graphics (didn't test other cards). 
> 
> Results of having a different monitor connected (which usually works fine) were
> the same (didn't boot, EDID checksum is invalid, remainder is 128 RAW EDID...).
Okay, it definitely looks like something's wrong driver-side in that case.  How was the monitor connected?  I believe that card has DMS-59 connectors on the back, but what does your DMS-59 adaptor provide on the other end?

Ben.

> 
> There is also a similar bug with NVS 450 (
> https://bugzilla.redhat.com/show_bug.cgi?id=747034 ). Except that nvs 450
> doesn't fail so early and doesn't have the connector at all. 
> 
> Both boot properly with nomodeset parameter (should have probably mentioned
> earlier)

Comment 14 Tomas Jamrisko 2011-10-20 10:17:38 UTC
You are right, the card only has a DMS-59 and the adaptor provides 2 DVI outputs

Comment 15 RHEL Program Management 2011-10-25 05:47:49 UTC
Since RHEL 6.2 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 22 Rodrigo A B Freire 2012-04-24 20:52:45 UTC
*** Bug 769391 has been marked as a duplicate of this bug. ***

Comment 23 Gary Smith 2012-06-03 11:44:05 UTC
*** Bug 696119 has been marked as a duplicate of this bug. ***

Comment 26 errata-xmlrpc 2012-06-20 07:58:20 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2012-0862.html