Bug 590960

Created attachment 413042 [details]
dmesg.log

Here is my dmesg.log.

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.

Not sure if this would block the release, particularly since a well known work around works (disabling kms).  I vote not a blocker.

(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.

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

Created attachment 413105 [details]
dmesg with nomodeset kernel parameter

Created attachment 413107 [details]
xorg.log with nomodeset parameter

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.

Reviewed by a QA, Release Engineering, etc. at 2010-05-11 "Go/No-Go Meeting and determined that this is not a release blocker.

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

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

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...

Hopefully Ben Skeggs will know more...

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 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?

Can you try booting with the parameter "edid_force_checksum=1" ?

(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.

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?

(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.

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.

(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.

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.

file /etc/passwd- is not owned by any package
please add

.spec
conf dir

sorry for my comment

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?

(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

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

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.

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.

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

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.