Bug 529292 - Graphics hang with KMS on nVidia 7800GT with FC12 beta RC2 install
Graphics hang with KMS on nVidia 7800GT with FC12 beta RC2 install
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
low Severity high
: ---
: ---
Assigned To: Ben Skeggs
Fedora Extras Quality Assurance
:
Depends On:
Blocks: fedora-x-blocker
  Show dependency treegraph
 
Reported: 2009-10-15 22:02 EDT by Chris Ball
Modified: 2009-11-07 18:39 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-06 11:28:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg with drm debug=15 and nouveau.modeset=1 (111.01 KB, text/plain)
2009-10-15 22:03 EDT, Chris Ball
no flags Details
X log when launching with nouveau DDX and no KMS (30.01 KB, text/plain)
2009-10-15 22:04 EDT, Chris Ball
no flags Details
X log when launching with nv DDX and no KMS (29.33 KB, text/plain)
2009-10-15 22:04 EDT, Chris Ball
no flags Details
binary edid from Apple Cinema 30" (128 bytes, application/octet-stream)
2009-10-15 22:05 EDT, Chris Ball
no flags Details
dmesg after Ben's patch (36.83 KB, text/plain)
2009-10-16 13:10 EDT, Chris Ball
no flags Details
xorg log after Ben's patch (18.48 KB, text/plain)
2009-10-16 13:11 EDT, Chris Ball
no flags Details
Compendium of similar failures from four reporters (1.67 KB, text/plain)
2009-11-05 17:16 EST, Adam Williamson
no flags Details
Versions of drivers, libdrm and kernel (308 bytes, application/octet-stream)
2009-11-05 18:25 EST, Carl van Tonder
no flags Details

  None (edit)
Description Chris Ball 2009-10-15 22:02:36 EDT
Description of problem:

When booting an installed FC12 beta RC2 (installed with vesa to avoid the hang), the display stops changing when modeset happens and stays hung; nothing I try can get further changes in video output.  It hangs when running nv or nouveau *without* modesetting, also with a hang and no more video updates, too.
Haven't tried the nvidia driver because I can't get it to build against F12 beta.

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

The card is an eVGA 7800GT, 10de:0092 3842:c517.

The display is an Apple Cinema 30" connected via dual-link DVI at 2560x1600.

F12 beta RC2, 2.6.31.1-56.fc12.i686.PAE, 64-bit Athlon64 3800+ machine

How reproducible:

Every time.

Steps to Reproduce:
1. boot without nomodeset
2.
3.
  
Actual results:
video hangs

Expected results:
working video

Additional info:

Attaching:

* dmesg with drm debug=15
* nouveau DDX log (doesn't seem to show anything wrong, but the display doesn't draw anything past a glitched pointer)
* nv DDX log (doesn't seem to show anything wrong, the display draws the GDM background, and then glitches and hangs when the GDM box animates/expands to show the user choices 
* binary copy of the EDID
Comment 1 Chris Ball 2009-10-15 22:03:37 EDT
Created attachment 364997 [details]
dmesg with drm debug=15 and nouveau.modeset=1
Comment 2 Chris Ball 2009-10-15 22:04:12 EDT
Created attachment 364998 [details]
X log when launching with nouveau DDX and no KMS
Comment 3 Chris Ball 2009-10-15 22:04:48 EDT
Created attachment 364999 [details]
X log when launching with nv DDX and no KMS
Comment 4 Chris Ball 2009-10-15 22:05:14 EDT
Created attachment 365000 [details]
binary edid from Apple Cinema 30"
Comment 5 Chris Ball 2009-10-15 22:19:58 EDT
Tried kernel 2.6.31.4-83.fc12.i686 just in case it helped; same result.
Comment 6 Chris Ball 2009-10-15 22:24:09 EDT
Also tried the other DVI port -- this card has two DVI ports, one of which has a dual-link TMDS and can run at full resolution.

Doing so results in the mode attempted being 1280x800 instead (which is correct for the single transmitter), but it still hangs rather than setting the mode.
Comment 7 Chris Ball 2009-10-16 13:08:30 EDT
Ben committed a kernel patch to nouveau GIT to fix this last night, and I've tried it out.  

It modesets -- I get a 2560x1600 mode that is legible, but contains small amounts of glitching and pixel trails from previous text.

When X starts with nouveau, I get a screenful of snow/noise.  If I hit ctrl+alt+backspace, X exits with a "Fatal server error: Detected GPU lockup".

Remarkably, after this happens, the fb is no longer glitchy, and starting X *another* time gets me a working X session.  However, I see that the kernel has said "GPU lockup - switching to software fbcon".

Am attaching the new dmesg, with the GPU lockup at the bottom, and new X log, also with the GPU lockup message.
Comment 8 Chris Ball 2009-10-16 13:10:26 EDT
Created attachment 365069 [details]
dmesg after Ben's patch
Comment 9 Chris Ball 2009-10-16 13:11:11 EDT
Created attachment 365070 [details]
xorg log after Ben's patch
Comment 10 Adam Williamson 2009-11-05 17:15:59 EST
So, we have four people hitting very similar issues. I'm not sure these are the same, but concentrating them into one report for now. Ben can tell us if they need to be split up.

Those affected are Chris Ball (reporter of this bug), James Laska, Carl van Tonder (via #530169) and Josh Boyer.

I am attaching a compendium of the messages each reporter is getting. They're obviously similar, but not identical, so we don't know if these are all the same bug. Symptoms are slightly different in each case, but we can say at least that this generally renders the current X session completely unusable.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 11 Adam Williamson 2009-11-05 17:16:40 EST
Created attachment 367743 [details]
Compendium of similar failures from four reporters
Comment 12 Adam Williamson 2009-11-05 17:18:10 EST
Adding all affected users to CC and setting bug to block F12.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 13 Adam Williamson 2009-11-05 17:29:58 EST
Ben would like everyone to test kernel -122 and see if it resolves these problems. It's available at:

http://koji.fedoraproject.org/koji/buildinfo?buildID=139823

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 14 Carl van Tonder 2009-11-05 18:25:55 EST
Created attachment 367754 [details]
Versions of drivers, libdrm and kernel

Still busy installing -122 kernel so will post results after that. In the mean-time, my versions of -drv-nouveau, libdrm and sever-Xorg as well as my *current* kernel.
Comment 15 Josh Boyer 2009-11-05 18:49:48 EST
The -122 kernel seems to have fixed things on my iMac G5 using Nouveau.
Comment 16 Adam Williamson 2009-11-05 19:38:23 EST
setting this to MODIFIED. we have a tag request in for 122:

https://fedorahosted.org/rel-eng/ticket/3126

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 17 Adam Williamson 2009-11-05 19:39:20 EST
note that Carl van Tonder reported on IRC the fix works for him. James Laska reports that the protection fault errors are gone from his logs but he cannot confirm X is working as he's not in front of the machine. Chris Bell has not yet been able to test.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 18 James Laska 2009-11-06 07:10:42 EST
I can report that the hangs no longer occur on my nVidia Corporation NV44 [Quadro NVS 285] system using kernel-2.6.31.5-122.fc12.i686.
Comment 19 Chris Ball 2009-11-07 18:39:23 EST
-122 is actually worse for me, but I suspect a bug's been fixed in the process.

Previously, I would get a somewhat glitchy modeset from nouveau, then start X, X would detect a GPU lockup, I'd start X *again*, and I'd have a working X session.

With -122, I get the glitchy modeset, but the lockup never happens.  Then when I start X I get a glitchy X session, and that soon turns into a full system hang.

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