RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 746929 - nVidia NVS 300 -- won't boot
Summary: nVidia NVS 300 -- won't boot
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.2
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Ben Skeggs
QA Contact: Desktop QE
URL:
Whiteboard:
: 696119 769391 (view as bug list)
Depends On:
Blocks: 727267
TreeView+ depends on / blocked
 
Reported: 2011-10-18 09:59 UTC by Tomas Jamrisko
Modified: 2018-11-28 21:19 UTC (History)
9 users (show)

Fixed In Version: kernel-2.6.32-244.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 747034 (view as bug list)
Environment:
Last Closed: 2012-06-20 07:58:20 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Screen of what happens at boot with NVS 300 (817.38 KB, image/jpeg)
2011-10-18 10:00 UTC, Tomas Jamrisko 		no flags Details
with drm.debug=14 as kernel option (1.20 MB, image/jpeg)
2011-10-18 15:46 UTC, Tomas Pelka 		no flags Details
dmesg output (43.54 KB, text/plain)
2011-10-19 14:42 UTC, Tomas Jamrisko 		no flags Details
Probably the more useful output (181.22 KB, text/plain)
2011-10-19 15:10 UTC, Tomas Jamrisko 		no flags Details
mistake, too many tabs, wrong bug (50.39 KB, text/plain)
2011-10-19 15:16 UTC, Tomas Jamrisko 		no flags Details
Show Obsolete (2) View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 96153 0 None None None Never
Red Hat Product Errata RHSA-2012:0862 0 normal SHIPPED_LIVE Moderate: Red Hat Enterprise Linux 6 kernel security, bug fix and enhancement update 2012-06-20 12:55:00 UTC

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
Note You need to log in before you can comment on or make changes to this bug.