My Dell Latitude D620 laptop has a nVidia G72M [Quadro NVS 110M/GeForce Go 7300] video card in it.
If I attempt to use the nouveau driver (either via KMS, or by booting to runlevel 3 with nomodeset and then running startx), the screen goes completely off, then comes back on with a black background that gradually lightens with a red tinge, from the bottom of the screen up. After a few moments, the screen has lightened enough that vertical stripe patterns are visible on it, almost like a screensaver. No components of the desktop are visible.
The system doesn't actually hang; I can Ctrl-Alt-Backspace the X server or flip to another virtual consoles. But the red tinge remains even after I shut down the X server, even if I subsequently restart X with the nv driver. (Only rebooting will get rid of it.)
This behavior has been unchanged since the nouveau driver was first released; it has consistently failed to work, in exactly this manner.
As a workaround, I am using the nv driver. But the nv driver can have issues with ACPI suspend/resume operations, so I'd prefer to use the nouveau driver if possible.
I have attached Xorg.0.log from an Xserver started via "startx".
Created attachment 375124 [details]
Xorg.0.log from X server session using nouveau driver
Ok, let's try that again...
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.
In addition to the Xorg.0.log file, could you also supply your xorg.conf and outbput of demsg?
Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please.
We will review this issue again once you've had a chance to attach this information.
hank you in advance.
Fedora Bugzappers volunteer triage team
Created attachment 375234 [details]
output from "dmesg"
I've attached my dmesg output.
The Xorg.0.log file I attached was generated with no /etc/X11/xorg.conf file.
James, thank you for your logs and all are aboard. Setting triaged keyword, already assigned to Ben Skeggs, setting Status to ASSIGNED.
This bug has been triaged
Fedora Bugzappers volunteer triage team
A response of, "nouveau doesn't support that chip/card yet, sorry" is a perfectly acceptable response, FWIW.
I really only filed this bug to make sure that the nouveau developers know that this chip/card doesn't work...
Created attachment 383572 [details]
dmesg output, kms enabled
Per the advice of some developers on the freenode #nouveau IRC channel, here's dmesg output from a boot with kms enabled (that is, without "nomodeset" on the kernel command line).
The point at which the display turned into angry fruit salad was *before* this line:
dracut: Scanning devices dm-0 for LVM volume groups
I know this because dm-0 is a LUKS-encrypted partition, and the display was already hosed at the point where I had to type the passphrase to unlock the partition.
I sent an mmiotrace trace to <email@example.com> back on 2010-02-04 (filename 10de:01d7-ralston-mmiotrace.tar.gz), but I haven't heard anything further.
Is there anything more I can do to help debug this?
The laptop that has this video card in it is a work laptop, so if I wheedled, I could probably find someone who would be willing to swap me for a laptop that doesn't have an nVidia card. But I don't want to do that, because it'll make Linux look bad...
I've found/fixed this issue recently, it'll make it to upstream nouveau once I hear back from the guy who's testing an updated patch. Then, it'll make it to Fedora shortly after. I'll update all the relevant bugs once it's in.
If you can provide the patch, I'll cheerfully roll my own RPMs with the patch and test them...
Ah cool, feel free: http://members.iinet.net.au/~skeggsb/d620.diff
kernel-126.96.36.199-92.fc12 has been submitted as an update for Fedora 12.
kernel-188.8.131.52-92.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/kernel-184.108.40.206-92.fc12
kernel-220.127.116.11-92.fc12 + nouveau KMS works perfectly on my Dell Latitude D620 now. Thanks MUCH for tracking this down and fixing it.
As an added bonus, using KMS has fixed bug 542878, so now I have working suspend/resume again.
Closing, as I've still had no issues with kernel-18.104.22.168-92.fc12 + nouveau KMS.