Bug 623555 - nouveau locks up console with garbled X session, G73 [GeForce 7600 GS], AGP
nouveau locks up console with garbled X session, G73 [GeForce 7600 GS], AGP
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau (Show other bugs)
13
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Ben Skeggs
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-12 02:30 EDT by CJ Kucera
Modified: 2010-08-16 00:39 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-16 00:39:52 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)
dmesg.txt (30.16 KB, text/plain)
2010-08-12 02:30 EDT, CJ Kucera
no flags Details
Xorg.0.log (25.57 KB, text/x-log)
2010-08-12 02:35 EDT, CJ Kucera
no flags Details
lsmod.txt (1.66 KB, text/plain)
2010-08-12 02:36 EDT, CJ Kucera
no flags Details

  None (edit)
Description CJ Kucera 2010-08-12 02:30:02 EDT
Created attachment 438351 [details]
dmesg.txt

Description of problem:

This is quite similar to a number of other bugs here, but none of the others seemed to be exactly this.  Apologies if I missed one.

Anyway, when attempting to use Nouveau on this system, it will immediately show what looks like a garbled version of the X screen that I should be seeing, which will also completely lock up the console (I'm unable to use Ctrl-Alt-F1 to get back to the text console, for instance).  The box itself still runs fine; I can SSH in from a remote location to look at logs and the like.

The graphics card is a Geforce 7600 GS, AGP version (G73 chipset, I guess) - in case it matters, my AGP bridge is a VIA KT880.  I tried adding "nouveau.tv_disable=1" to my boot lines, as suggested in some other bugs here, but that didn't do anything (the logfiles didn't make it look like that would have been the problem, anyway).

I'm using a kernel here from fedora-updates-testing (kernel-2.6.34.3-37.fc13) instead of the stock F13 kernel because otherwise I get a crash and trace very much like that from bug 559791.

I'm not using any fancy graphical effects on my WM - I'm actually defaulting to runlevel 3 and doing a "startx" which just takes me into icewm, a very basic WM which doesn't do any fancy compositing stuff.

The framebuffer component of nouveau seems to work fine, since I get the fancier "loading" graphics as the system boots, before I get dropped to the login prompt.

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

(all should be current)
kernel-2.6.34.3-37.fc13
xorg-x11-server-Xorg-1.8.2-3.fc13.i686
xorg-x11-drv-nouveau-0.0.16-7.20100423git13c1043.fc13.i686

Attached here is my full dmesg output, Xorg.0.log is next...
Comment 1 CJ Kucera 2010-08-12 02:35:13 EDT
Created attachment 438352 [details]
Xorg.0.log

Complete Xorg.0.log - you'll note that there's no warnings or errors flagged anywhere in there.  The 1680x1050 (at 60Hz) autodetected by Nouveau is the correct geometry for the monitor the machine is hooked up to.  Also as you can tell, this is going through the VGA output.

Oh, and since it's only four lines and probably not worth an actual attachment, here's my current xorg.conf, as well:

Section "Device"
Identifier "n"
Driver "nouveau"
EndSection

I had tried running this on a more full xorg.conf which specified resolutions and all that, and it produced the same effect.

Oh, one other thing to note - the F13 install disc and LiveCD both did basically the exact same thing for me - they'd get up to the point of launching X, and I'd end up with a garbled, unresponsive screen.  In the end I had to do a text install in order to get F13 installed in the first place.

Oh, and for the time being, I can certainly just make do with either nv or the binary nvidia module...
Comment 2 CJ Kucera 2010-08-12 02:36:16 EDT
Created attachment 438354 [details]
lsmod.txt

... oh, which reminds me, here's the output from lsmod as well, just showing that the binary nvidia is NOT loaded, while nouveau is.  (I assume that you could infer as much from the dmesg output, but here it is regardless.)
Comment 3 Ben Skeggs 2010-08-12 07:42:29 EDT
This is the issue:

[drm] nouveau 0000:01:00.0: PFIFO_DMA_PUSHER - Ch 0

The GPU locks up for some reason.  You may be able to make it to X with "nouveau.noaccel=1" in your boot options.

Can you please update to http://koji.fedoraproject.org/koji/buildinfo?buildID=189280 as it's very close to nouveau git, and see if it helps any.
Comment 4 CJ Kucera 2010-08-12 13:57:02 EDT
Hello...

1) Yep, adding "nouveau.noaccel=1" seems to work fine.  Thanks!

2) I had actually already been using that kernel image (without it, I was getting an actual crash + traceback).  FWIW, this morning I went ahead and compiled up the kernel source from Nouveau's Git (which is apparently based on 2.6.35-rc3 at the moment), and it did the exact same thing.  I'm guessing that this is an upstream issue.  Did you want me to just re-file it with them, directly?

Thanks!
Comment 5 Ben Skeggs 2010-08-12 17:59:17 EDT
If you wish to file with nouveau upstream directly, you may get some other nouveau developers looking at it too.  But, I'm one of them anyway, so here's fine too :)

I am, however, not too sure of the cause at this point.  It's possibly also an AGP issue, how do you far with "nouveau.noagp=1" in your boot options?
Comment 6 CJ Kucera 2010-08-13 12:56:30 EDT
Okay, sounds good to me - I'll just leave it here.

X starts up fine if I have "nouveau.noagp=1", so either that or "nouveau.noaccel=1" works for me.

I had figured it was still an issue, previously, since I figured that the "noaccel" meant that I was missing out on some kind of enhanced performance, though either of these two workarounds is good enough for me.  Feel free to just close this out if you don't think there's anything to be done here (um, not that you'd need MY permission to do so, of course).

Thanks for the help!
Comment 7 Ben Skeggs 2010-08-16 00:32:56 EDT
Yeah, NoAccel gives you no GPU acceleration whatsoever.  Using noagp is likely the best workaround you'll get.  Unfortunately, AGP issues tend to be very specific to chipset+GPU combinations, so are very hard to fix without it in front of you.

But, if noagp is ok for you, feel free to close this :)
Comment 8 CJ Kucera 2010-08-16 00:39:52 EDT
Sure, I'll just close it out.  Thanks again for looking into it!

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