Bug 692919

Created attachment 489431 [details]
output from "dmesg" immediately after boot

Created attachment 489432 [details]
Xorg.0.log

Created attachment 489433 [details]
00-system-setup-keyboard.conf

There is no xorg.conf, and this is the only file in the /etc/X11/xorg.conf.d directory.

Versions:

0:kernel-2.6.38-0.rc8.git0.1.fc15.x86_64
0:kernel-2.6.38.2-8.fc15.x86_64
0:kernel-2.6.38.2-9.fc15.x86_64
0:xorg-x11-apps-7.6-2.fc15.x86_64
0:xorg-x11-drivers-7.4-2.fc15.x86_64
0:xorg-x11-drv-acecad-1.4.99-3.20101203gitf8e87eaf4.fc15.x86_64
0:xorg-x11-drv-aiptek-1.3.99-3.20101203git95b891239.fc15.x86_64
0:xorg-x11-drv-apm-1.2.3-6.fc15.x86_64
0:xorg-x11-drv-ast-0.91.10-5.fc15.x86_64
0:xorg-x11-drv-ati-6.14.0-7.20110316gitcdfc007ec.fc15.x86_64
0:xorg-x11-drv-cirrus-1.3.2-7.fc15.x86_64
0:xorg-x11-drv-dummy-0.3.4-5.fc15.x86_64
0:xorg-x11-drv-elographics-1.2.99-3.20101206git6fd22a9d6.fc15.x86_64
0:xorg-x11-drv-evdev-2.6.0-3.fc15.x86_64
0:xorg-x11-drv-fbdev-0.4.1-8.fc15.x86_64
0:xorg-x11-drv-fpit-1.3.99-3.20101206git020c04e29.fc15.x86_64
0:xorg-x11-drv-glint-1.2.4-7.fc15.x86_64
0:xorg-x11-drv-hyperpen-1.3.99.1-3.20101202git0a03c1fd0.fc15.x86_64
0:xorg-x11-drv-i128-1.3.4-7.fc15.x86_64
0:xorg-x11-drv-i740-1.3.2-7.fc15.x86_64
0:xorg-x11-drv-intel-2.14.0-4.fc15.x86_64
0:xorg-x11-drv-keyboard-1.5.99.901-2.fc15.x86_64
0:xorg-x11-drv-mach64-6.8.2-7.fc15.x86_64
0:xorg-x11-drv-mga-1.4.13-6.fc15.x86_64
0:xorg-x11-drv-mouse-1.6.99.901-2.fc15.x86_64
0:xorg-x11-drv-mutouch-1.2.99-4.20101206git24029451c.fc15.x86_64
1:xorg-x11-drv-nouveau-0.0.16-24.20110324git8378443.fc15.x86_64
0:xorg-x11-drv-nv-2.1.18-6.fc15.x86_64
0:xorg-x11-drv-openchrome-0.2.904-13.fc15.x86_64
0:xorg-x11-drv-penmount-1.4.99-3.20101203git6658e9ad2.fc15.x86_64
0:xorg-x11-drv-qxl-0.0.21-2.fc15.x86_64
0:xorg-x11-drv-r128-6.8.1-9.fc15.x86_64
0:xorg-x11-drv-rendition-4.2.4-5.fc15.x86_64
0:xorg-x11-drv-s3virge-1.10.4-7.fc15.x86_64
0:xorg-x11-drv-savage-2.3.2-3.fc15.x86_64
0:xorg-x11-drv-siliconmotion-1.7.3-8.20100122.fc15.x86_64
0:xorg-x11-drv-sis-0.10.3-5.fc15.x86_64
0:xorg-x11-drv-sisusb-0.9.4-5.fc15.x86_64
0:xorg-x11-drv-synaptics-1.3.99.901-2.fc15.x86_64
0:xorg-x11-drv-tdfx-1.4.3-7.fc15.x86_64
0:xorg-x11-drv-trident-1.3.4-5.fc15.x86_64
0:xorg-x11-drv-v4l-0.2.0-12.fc15.x86_64
0:xorg-x11-drv-vesa-2.3.0-7.fc15.x86_64
0:xorg-x11-drv-vmmouse-12.6.99.901-3.20101209git07232feb6.fc15.x86_64
0:xorg-x11-drv-vmware-11.0.3-4.fc15.x86_64
0:xorg-x11-drv-void-1.3.1-5.20101202gitcb8d19b8a.fc15.x86_64
0:xorg-x11-drv-voodoo-1.2.4-5.fc15.x86_64
0:xorg-x11-drv-wacom-0.10.99-1.20110315.fc15.x86_64
1:xorg-x11-font-utils-7.5-6.fc15.x86_64
0:xorg-x11-fonts-ISO8859-1-100dpi-7.5-3.fc15.noarch
0:xorg-x11-fonts-ISO8859-1-75dpi-7.5-3.fc15.noarch
0:xorg-x11-fonts-misc-7.5-3.fc15.noarch
0:xorg-x11-resutils-7.5-2.fc15.x86_64
0:xorg-x11-server-common-1.10.0-7.fc15.x86_64
0:xorg-x11-server-utils-7.5-4.fc15.x86_64
0:xorg-x11-server-Xephyr-1.10.0-7.fc15.x86_64
0:xorg-x11-server-Xorg-1.10.0-7.fc15.x86_64
0:xorg-x11-utils-7.5-2.fc15.x86_64
1:xorg-x11-xauth-1.0.2-9.fc15.x86_64
0:xorg-x11-xinit-1.0.9-20.fc15.x86_64
0:xorg-x11-xkb-utils-7.5-3.fc15.x86_64

> At about the same time that I updated to kernel-2.6.38-1.fc15, I noticed
> something very odd: whenever I rebooted, instead of the display turning back on
> during the POST, the display stays off until the kernel boots and starts KMS.
> Then--and only then--does my laptop panel turn on. Moreover, this is true even
> if I perform a completely cold boot.

scary... 

Maybe one of these might help to return the laptop from this pseudo-briked
state.

after a cold-boot (one cold-boot per item):

more hardware/firmware related:
* can you enter the bios and are you able to see it with the buil-in lcd panel?
* does the laptop have a fn-display key for changing the video output?
  if it does, then try:
   * try switching from ldvs to vga or dual mode (if posible).
* attach a vga monitor and power on the laptop and see if it works, also 
  enter bios and switch displays with the fn key.

more software related:
* boot with an older kernel, if it is still avaiable.
* what happens if you disable graphical plymouth mode and use the old plain vga 
  plymouth text mode?
* completelly disable nouveau (in dracut and in modules.d/blacklist.conf), and
  force the usage of vesa, and reboot at least once with vesa.

* booting another os for testing purposes, maybe from live-cd.

You can try this from a remote ssh session:

from: http://nouveau.freedesktop.org/wiki/KernelModeSetting

Deactivating KMS and unloading Nouveau

# echo 0 > /sys/class/vtconsole/vtcon1/bind
# rmmod nouveau

# /etc/init.d/consolefont restart 
this is not for fedora, systemd replacement??
maybe one of those:
console-kit-daemon.service           loaded active running Console Manager
console-kit-log-system-start.service loaded active exited  Console System Startup Logging
systemd-vconsole-setup.service       loaded active exited  Setup Virtual Console

# rmmod ttm
# rmmod drm_kms_helper
# rmmod drm

and then modprobe or insmod them again.

Reartes, your suggestion to hook up an external monitor and use the Fn-display key to switch inputs was a good one. It took a few tries, but I was finally able to get into the boot menu / BIOS by using an external monitor. I configured the display to use the LCD panel only, but it had no effect.

I also tried booting the Fedora 14 installation DVD, which is what I was running before I loaded F15. It was able to turn on the screen during KMS initialization, but when I rebooted, the screen was still off during POST.

However, getting to the boot menu allowed me to run the onboard diagnostics, which returned:

--Video Card Connection Test--
Test Results : Pass

--LCD Inverter Detection Test--
Test Results : Pass

--LCD Connection Test--
Test Results : Fail
Error Code   : 1000-0321
Msg: Unable to detect LCD.

So, at this point, I see two main possibilities:

1.  There is some sort of hardware problem with my laptop's panel, and it is merely coincidence that it occurred while I was testing F15. The problem disables the LCD screen when the system POSTs, but the nouveau driver somehow convinces the video card to enable the LCD when it initializes KMS.

2.  The nouveau driver has stored some value into the video card's NVRAM that causes it to keep the LCD panel off (including across warm/cold [re]boots) until it is explicitly turned on. The laptop's BIOS doesn't expect the video card to do this, so it believes the LCD panel is faulty.

At this point, based solely on the fact that I haven't been able to find any other reports of F15 bricking nouveau-driver laptop panels, I think possibility #1 is more likely.

However, before I close this as WORKSFORME, I'd like to know of the feasibility of possibility #2. If, for example, a nouveau developer can assert that the G72M doesn't *have* any settings or preferences that are retained across power cycles (i.e., no NVRAM or similar functionality), then possibility #2 would be remote.

i am not a developer, but there may be some posibiblity before consider option 1.
 
Flashing all firmware (BIOS, EC and VBIOS)
i never owned any dell nor have experience flashing dell firmware, but maybe flashing the firmware (bios + embeded controller + vbios) might overwrite any eeprom or similar permanent configuration. check if there is a bios package (maybe a downgrade[and reupdated later] may be needed if possible at all). 
check if there is a bios package that also comes with video bios (or a separate package, i dont know about dells). I dont know if the problem is in the vbios, it is most likely the embeded controller. check for firmware updates and changelogs.

I don't believe there's anything that we touch that could cause this to happen.  The only possibility I can think of would be that we corrupted the panel's EDID, but, you'd see the DRM being very noisy if that were the case, and we're clearly able to detect it and set a mode.

I'm not sure why we can detect the EDID but the VBIOS can't, that's somewhat odd.  Perhaps we have different tolerances, and whatever's gone wrong makes DDC exceed what the VBIOS will accept.

There is a trick I've heard of people trying that has helped in some cases, usually to restore corrupt EDID (which seems unlikely here), but anything's worth a try:  the trick is to take the battery out for over a minute, then put it back in, and when you power back on keep holding the power button down for at least 30 seconds before releasing it.

The 30-second-power-button trick didn't work.

The DRM has no problem reading the EDID. Believe me, I know what happens when it can't—see bug 668196 (although that's a different driver).

Thus, I think the most likely explanation is what you said: for whatever reason, the hardware problem that's occurred here confuses the VBIOS, but not the nouveau driver.

That's pretty damn impressive, considering that the VIOS was (assumably) written with nVidia's assistance, and the nouveau driver was written with a specific LACK of nVidia's assistance!

At any rate, I'm closing this as WORKSFORME. (Feel free to change it to NOTABUG, if you think that's more accurate.)