Red Hat Bugzilla – Bug 623555
nouveau locks up console with garbled X session, G73 [GeForce 7600 GS], AGP
Last modified: 2010-08-16 00:39:52 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...
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...
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.)
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.
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!
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?
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!
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 :)
Sure, I'll just close it out. Thanks again for looking into it!