Description of problem: Rescue and install CD's from FC6test1 work just fine even in graphics mode. First boot works for x86-64 but then x never does and hangs system (first boot is in graphical mode). On x86 first boot runs in text mode, x still hangs. It may be possible that the problem is that the machine is trying to use an external monitor (not attached), but the system locks hard. So, I will be testing this, but I doubt it. Why does it work on install/rescue but not on a live system? (This is not related to bug 201471 as I am also trying all this with maxcpus=1.) The chip is unknown to lspci and seemingly to X. I have attached lspci output so that it can be added if needed. Version-Release number of selected component (if applicable): xorg-x11-drv-nv-1.2.0-3.fc6 How reproducible: Every time it hangs with a blank BRIGHT screen. Steps to Reproduce: 1. Install on given laptop 2. try to run system-config-display 3. watch it hang with no errors, no nothing Additional info: Windows calls the chip nVidia GeForce Go 7200
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.