Bug 623555 - nouveau locks up console with garbled X session, G73 [GeForce 7600 GS], AGP
Summary: nouveau locks up console with garbled X session, G73 [GeForce 7600 GS], AGP
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau
Version: 13
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Ben Skeggs
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-08-12 06:30 UTC by CJ Kucera
Modified: 2010-08-16 04:39 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2010-08-16 04:39:52 UTC

Attachments (Terms of Use)
dmesg.txt (30.16 KB, text/plain)
2010-08-12 06:30 UTC, CJ Kucera
no flags Details
Xorg.0.log (25.57 KB, text/x-log)
2010-08-12 06:35 UTC, CJ Kucera
no flags Details
lsmod.txt (1.66 KB, text/plain)
2010-08-12 06:36 UTC, CJ Kucera
no flags Details

Description CJ Kucera 2010-08-12 06:30:02 UTC
Created attachment 438351 [details]

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

Attached here is my full dmesg output, Xorg.0.log is next...

Comment 1 CJ Kucera 2010-08-12 06:35:13 UTC
Created attachment 438352 [details]

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"

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 06:36:16 UTC
Created attachment 438354 [details]

... 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 11:42:29 UTC
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 17:57:02 UTC

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?


Comment 5 Ben Skeggs 2010-08-12 21:59:17 UTC
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 16:56:30 UTC
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 04:32:56 UTC
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 04:39:52 UTC
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.