Bug 590960 - [NV84] Nouveau kms leads to an all black display
[NV84] Nouveau kms leads to an all black display
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau (Show other bugs)
13
x86_64 Linux
urgent Severity medium
: ---
: ---
Assigned To: Ben Skeggs
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-11 00:56 EDT by Liang Suilong
Modified: 2013-01-13 06:59 EST (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-27 12:15:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
xorg.log (45.74 KB, text/plain)
2010-05-11 00:56 EDT, Liang Suilong
no flags Details
dmesg.log (40.08 KB, text/plain)
2010-05-11 00:57 EDT, Liang Suilong
no flags Details
dmesg with nomodeset kernel parameter (36.53 KB, text/plain)
2010-05-11 07:21 EDT, Liang Suilong
no flags Details
xorg.log with nomodeset parameter (76.51 KB, text/plain)
2010-05-11 07:23 EDT, Liang Suilong
no flags Details

  None (edit)
Description Liang Suilong 2010-05-11 00:56:22 EDT
Created attachment 413041 [details]
xorg.log

Just like Intel this bug: https://bugzilla.redhat.com/show_bug.cgi?id=587171

Nouveau kms also leads to a all black display. 

I have tested many kernels. 2.6.33.1-19, and the lastest 2.6.33.3-85. When the system start to run kernel, My screen turns to all black screen. Then my LG L1953T monitor switches to energy-saving mode. My monitor is using DVI-D port. 

I try to remove 'quiet' from kernel parameter of GRUB. I can see my monitor leads to a black screen after loading DRM of kernel. 

Here is my hardware list: http://www.smolts.org/client/show/pub_2cfd8066-d0ed-4131-bb9e-04bbdcc0c7bd
Comment 1 Liang Suilong 2010-05-11 00:57:42 EDT
Created attachment 413042 [details]
dmesg.log

Here is my dmesg.log.
Comment 2 Liang Suilong 2010-05-11 01:01:47 EDT
Additionally, If I turn off nouveau KMS, I can login GDM normally. 

I add this bug into F13Blocker. I think this bug will affect whether we release F13 on time or not.
Comment 3 Jesse Keating 2010-05-11 01:03:08 EDT
Not sure if this would block the release, particularly since a well known work around works (disabling kms).  I vote not a blocker.
Comment 4 Liang Suilong 2010-05-11 01:17:19 EDT
(In reply to comment #3)
> Not sure if this would block the release, particularly since a well known work
> around works (disabling kms).  I vote not a blocker.    

Yes, disabling kms can work, However, a lot of users do not know how to disable kms before booting LiveCD. So I think this problem is quite urgent. 

Though enabling KMS will occur to all black display, services running on background are still OK, such as sshd. I can connect to my desktop from another machine via ssh.
Comment 5 Adam Williamson 2010-05-11 05:38:24 EDT
It's not that urgent, because it's a single-system bug. We've tested F13 on quite a few NVIDIA systems, between QA and Ben Skeggs, and haven't seen this bug. We generally only take bugs like this as blockers if they affect a reasonably wide range of systems. Someone on the list reported a somewhat different bug with an 8400GS, but we've tested several other NV8* cards and they're okay.

It may help to attach logs from the case where you boot with 'nomodeset', to see how they differ.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 6 Liang Suilong 2010-05-11 07:21:49 EDT
Created attachment 413105 [details]
dmesg with nomodeset kernel parameter
Comment 7 Liang Suilong 2010-05-11 07:23:51 EDT
Created attachment 413107 [details]
xorg.log with nomodeset parameter
Comment 8 Liang Suilong 2010-05-11 07:47:36 EDT
I have uploaded the logs which record X and dmesg's information without nouveau KMS. I also test another machine with GF8600. It is the same.
Comment 9 John Poelstra 2010-05-11 20:59:07 EDT
Reviewed by a QA, Release Engineering, etc. at 2010-05-11 "Go/No-Go Meeting and determined that this is not a release blocker.
Comment 10 Liang Suilong 2010-05-11 22:59:21 EDT
I have reported this bug in Nouveau Test Day. Yesterday I captured two videos for black display. 

Here is the first one:
http://liangsuilong.fedorapeople.org/black-display.MPG

booting information after removing 'rhgb' and 'quiet' parameter:
http://liangsuilong.fedorapeople.org/imformation-before-black-display.MPG
Comment 11 Tommy He 2010-05-12 12:07:56 EDT
Unable to reproduce this bug on GeForce 8400M G on a ASUS F9Dc laptop with F13 RC2 LiveCD i686.

With mesa-dri-drivers-expermental installed, below tests were performed:

KMS Plymouth GDM: OK.
VMT switch: OK.
gnome-shell: Blur window boarder and fonts in normal view. Fine in maximum window.
Compiz: OK, cube and wobby. (following tests were performed with Compiz enabled)
Non-XV video openvideo.dailymotion.com : OK
XV video Offline Bunny Trailer(theora): OK
Comment 12 Michal Schmidt 2010-05-12 14:12:11 EDT
The specific monitor is probably an important factor here. That's why others cannot reproduce.

From the dmesg:

[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 8
[drm:drm_edid_block_valid] *ERROR* Raw EDID:
...hex dump of the EDID data...
Comment 13 Michal Schmidt 2010-05-12 14:24:42 EDT
Hopefully Ben Skeggs will know more...
Comment 14 Ben Skeggs 2010-05-12 19:24:22 EDT
Yeah, it looks like the monitor is reporting bad information to the driver, or the driver is doing something wrong retrieving the info.  The former is more likely.
Comment 15 Liang Suilong 2010-05-13 01:23:16 EDT
(In reply to comment #14)
> Yeah, it looks like the monitor is reporting bad information to the driver, or
> the driver is doing something wrong retrieving the info.  The former is more
> likely.    

In my opinion, the latter is more likely. Nouveau KMS can run on F11 and F12 with my monitor. I also test Fedora 13 Alpha and it is OK too. Experimental nouveau 3D acceleration also runs well.  

So Does the latest codes cause this bug? Do developers need to forward-port the old codes to the latest branch?
Comment 16 Michal Schmidt 2010-05-13 03:01:28 EDT
Can you try booting with the parameter "edid_force_checksum=1" ?
Comment 17 Michal Schmidt 2010-05-13 03:08:00 EDT
(In reply to comment #16)
> Can you try booting with the parameter "edid_force_checksum=1" ?    

Oh, forget it. The patch adding the parameter is not in the Fedora kernel.
Comment 18 Michal Schmidt 2010-05-13 04:03:10 EDT
ajax,

is this a situation for which your patch "drm/edid: Add option to forcibly
correct EDID checksums" was meant?:
http://lists.freedesktop.org/archives/dri-devel/2010-April/000255.html
What is the status of it?
Comment 19 Liang Suilong 2010-05-13 08:19:27 EDT
(In reply to comment #16)
> Can you try booting with the parameter "edid_force_checksum=1" ?    

I try it, but it is the same. 

In this evening (GMT +8), I will download RC3 image and test nouveau KMS on another machine with GeForce 8600GT too.
Comment 20 Liang Suilong 2010-05-13 23:47:46 EDT
Last night I tested RC3 image in two desktops with NV8x chip. 

The first one: GeForce 8500GT and LG L1770H (1280x1024) monitor.
KMS Plymouth GDM: OK.
VMT switch: OK.

The second one: GeForce 8600GT and Envision G912W (1440x900) monitor.
KMS Plymouth GDM: OK.
VMT switch: OK.

But My desktop still did not work correctly. The same problem appeared. 

A friend in Fedora Chinese User Group named Yong Ma reported to me that KMS could not detect the best resolution of his monitor but both KMS Plymouth GDM and VMT switch are OK. When he logged into GDM and change to the best resolution then hist monitor became unclear. His monitor is AOC 171S+ and the best reolution is 1280x1024, nevertheless, KMS forced to use 1024x768. His display card is GeForce 8600GT.
Comment 21 Liang Suilong 2010-05-14 00:22:19 EDT
(In reply to comment #20)
> Last night I tested RC3 image in two desktops with NV8x chip. 
> 
> The first one: GeForce 8500GT and LG L1770H (1280x1024) monitor.
> KMS Plymouth GDM: OK.
> VMT switch: OK.
> 
> The second one: GeForce 8600GT and Envision G912W (1440x900) monitor.
> KMS Plymouth GDM: OK.
> VMT switch: OK.
> 

Sorry, the second desktop should be GeForce 8600GT and Envision G916W (1440x900) monitor.
Comment 22 Liang Suilong 2010-05-18 05:39:18 EDT
Ben Skeggs,

I have tested kernel-2.6.33.4-96.fc13.x86_64 and xorg-x11-drv-nouveau-0.0.16-6.20100423git13c1043.fc13.x86_64. The bug is still existed on my desktop.
Comment 23 Mateusz M. 2010-05-23 03:15:18 EDT
file /etc/passwd- is not owned by any package
please add

.spec
conf dir

sorry for my comment
Comment 24 lane 2010-08-25 13:08:18 EDT
Not sure if this is the same issue or not.  I installed F13 on a Lenovo T410.  The base install worked.  When I updated to 2.6.33.8-149 the display goes black consistent with the description above.

We tried the following workaround:

nomodeset nouveau.modeset=0

as additional parameters without success.

The only other version of the kernel that I have used is 2.6.33.3-85, which is the version of the kernel that was installed as part of the original installation.

Here is my hw list:

http://www.smolts.org/client/show/pub_846d0061-647a-4317-8b77-196d0a9c50bb

Assuming this is the same issue - is there a workaround?
Comment 25 Ben Skeggs 2010-08-25 18:51:40 EDT
(In reply to comment #24)
> Not sure if this is the same issue or not.  I installed F13 on a Lenovo T410. 
> The base install worked.  When I updated to 2.6.33.8-149 the display goes black
> consistent with the description above.
> 
> We tried the following workaround:
> 
> nomodeset nouveau.modeset=0
> 
> as additional parameters without success.
> 
> The only other version of the kernel that I have used is 2.6.33.3-85, which is
> the version of the kernel that was installed as part of the original
> installation.
> 
> Here is my hw list:
> 
> http://www.smolts.org/client/show/pub_846d0061-647a-4317-8b77-196d0a9c50bb
> 
> Assuming this is the same issue - is there a workaround?
I'd suggest grabbing the latest 2.6.34.fc13 kernel from koji. 

http://koji.fedoraproject.org/koji/buildinfo?buildID=191473
Comment 26 Jeff Raber 2010-12-07 21:36:03 EST

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 27 Joe Sislow 2011-04-07 20:32:25 EDT
Hey, this problem is wrecking a server of mine, and I really don't want to have to buy a new monitor to fix it.  Is there any new status on this or a workaround?  I seem to have the problem with an older Hanns G JC199D monitor that's returning EDID nouveau doesn't like.  I'm running F14 with kernel 2.6.35.11-83.fc14.i686.  I'd be happy to provide more info if it helps track it down.
Comment 28 Joe Sislow 2011-04-08 09:27:04 EDT
Just to add some detail.  I found a workaround.  I switched to the closed Nvidia driver to see if I could get further, and in doing so, I found it also had a problem with the EDID data from my monitor.  By scraping the EDID from the Xorg log, I was able to save it to a file.  Once I did that, I changed 2 bytes: 

- The checksum was wrong, so I recalculated it.  Once it was correct, X complained about the extension flag.  

- The second to last byte is the extension flag.  According to wiki, it's the number of blocks that follow this block, but only in version 1.3 or greater.  It wasn't in my case, so I set it to 0.

Once I did those, I used the line

Option "CustomEDID" "DFP-0:/etc/X11/nvnew.raw"

That seems to have gotten it to work.  I'm not sure it'll work with nouveau, as I haven't been brave enough to undo a working setup and try it.  But that might do in the time.  The key seems to be, though, that when nouveau gets an EDID it doesn't like, the default resolution is out of range for some monitors.  That seems like a horribly bad choice to me, so if there's one change I'd request, it's that the default resolution on error is revisited.
Comment 29 Bug Zapper 2011-06-02 10:13:03 EDT
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 30 Bug Zapper 2011-06-27 12:15:48 EDT
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 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.

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.