Bug 201472

Created attachment 133700 [details]
lspci -vvv and lspci -n

That chip does appear to be completely unknown to Linux.  Cool!  I've added it
to the pci ids list on sourceforge.

s-c-d should be picking the right driver though, 0x01d6 is definitely listed in
the xinf file.  Can you attach the X log from attempting to run s-c-d?

Can you tell me how to do this when the machine locks hard the instant s-c-d is
started (due to it calling X)? This is the problem, I cannot get anything.

Ok, if you reference #201471 you will see things are now stable. Without noapic
I can book and rhgb works, but when gdm loads, it hangs. With noapic I appear to
be completely stable. _HOWEVER_, there are still is a problem. It uses probed
values for the monitor instead of the LCD generic 1280x800 selection I keep
doing. It also won't use 24 bit color although I am telling it to.

So, rhgb and gdm run at 800x600 in 16bit. This is a bug with
system-config-display. How do I fix this?

Oh, and a currently up-to-date rawhide still says it doesn't know this card. So,
apparently things are not being moved down from cvs to rawhide.

Ok, s-c-d still doesn't recognize the chip as a go live 7200. Additionally,
colors are often screwed up in X (including rhgc) and switching virtual consoles
and back ususally fixes it (occassionally multiple attempts are needed).

Additionally the last six or seven rawhide kernels are showing:
PCI: Failed to allocate mem resource #6:20000@e0000000 for 0000:05:00.0


This is my video card. If I turn all DPMS (X, vbetool through acpi, etc.) off,
the system will not crash on sleep, but the video doesn't come back (eternal or
internal). Should this sleep crash be a new bug?

Ok, s-c-d seems to recognize and not crash. The color screw up about half goes
away with vga=normal and nofb as kernel parameters. This also solves (if and
only if DPMS option is enabled through X) the crash on sleep. However, hibernate
still leaves a black screen (no backlight seems to be the problem) on resume.
However, alt-ctl-delte and shutdown -r now both work, so it isn't dead.

I don't know if the following code (found
athttp://www.mail-archive.com/devel/msg06145.html) for XFree86 works
or not. I have a Go 7200. This code is for a Go chip. Maybe xorg needs it or we
need an nvtool just like radeontool which will do this, if it is the right thing
to do:

--- xc/programs/Xserver/hw/xfree86/drivers/nv/nv_driver.c.bak   2004-04-05
02:13:51.000000000 +0200
+++ xc/programs/Xserver/hw/xfree86/drivers/nv/nv_driver.c       2004-06-05
19:44:56.000000000 +0300
@@ -1623,6 +1623,17 @@
     }
 #endif
     
+    if((pNv->Chipset == 0x10DE0112))
+    {
+      /* GeForce2 Go */
+      CARD32 tmp_pcrt;
+      tmp_pcrt = pNv->PCRTC0[0x081C/4] & 0xFFFFFF00;
+      if(on) {
+          tmp_pcrt |= 0x55;
+      }
+      pNv->PCRTC0[0x081C/4] = tmp_pcrt;
+    }
+
     /* cut the TMDS output */
     if(on) fpcontrol |= pNv->fpSyncs;
     else fpcontrol |= 0x20000022;




For those trying to keep their system from crashing: grub.conf needs to be
changed to have nofb and vga=normal, make sure your xorg.conf has Option "DPMS"
in the display section. The screen will still be black. Don't bother with the
bios modes for sleep (acpi something = something_bios or some such) as they will
likely cause your system to crash, especially with DV6000 laptops from HP.

Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no longer
test releases. We're cleaning up the bug database and making sure important bug
reports filed against these test releases don't get lost. It would be helpful if
you could test this issue with a released version of Fedora or with the latest
development / test release. Thanks for your help and for your patience.

[This is a bulk message for all open FC5/FC6 test release bugs. I'm adding
myself to the CC list for each bug, so I'll see any comments you make after this
and do my best to make sure every issue gets proper attention.]

Yes, this is still valid. I just wasn't updating the version. Done.

Actually, as of Fedora 7, test release bugs should now be marked against the
"devel" version, for exactly this reason.

Updating summary to match current problem.

Ok, still  no backlight, including the quirks for dpms on. This with all updates
from rawhide/devel as of today.

Do you have a backlight control file under /proc/acpi/video?

There are several directories. All of them contain entries like this:
./UVGA/LCD:
total 0
-rw-r--r-- 1 root root 0 2007-09-26 00:18 brightness
-r--r--r-- 1 root root 0 2007-09-26 00:18 EDID
-r--r--r-- 1 root root 0 2007-09-26 00:18 info
-rw-r--r-- 1 root root 0 2007-09-26 00:18 state

This laptop died a horrible death by... hmm... horrible HP quality control
recently. I am no longer able to help test any fixes to this bug. It also has
had no attention since September 07 it seems.

I am closing this bug in 72 hours unless the assigned person thinks it needs to
stay open as I can no longer help test.

Since there are insufficient details provided in this report for us to
investigate the issue further, and we have not received feedback to the
information we have requested above, we will assume the problem was not
reproducible, or has been fixed in one of the updates we have released for the
reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest
update of their distribution, and if this issue turns out to still be
reproducible in the latest update, please reopen this bug with additional
information.

Closing as INSUFFICIENT_DATA.