Hide Forgot
I'm testing F15 on my Dell Latitude D620 laptop, which uses a G72M [Quadro NVS 110M/GeForce Go 7300] to drive the laptop's LCD panel. As I have previously discovered, the Latitude D620 with the G72M has some quirks. (See bug 543091 for the gory details.) 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. I do not believe there is anything physically wrong with my laptop, the video card, or the panel. I can (blindly) navigate the GRUB menus during the boot. It's just that the panel is off. Thus, I believe that the kernel (or possibly the nouveau_drv.so X driver) has somehow stored options to the BIOS and/or video card that tells it to keep the panel off until it is specifically initialized. Here's why this is an urgent problem: whatever changes have been made to my laptop's display appear to be permanent. Specifically: I removed all batteries and accessories from the laptop, took it apart, and disconnected the CMOS battery for approximately 30 minutes. I then reconnected the battery, reassembled everything, and powered it back up. But the behavior did not change: the panel backlight stayed completely off until KMS initialized. Now, I know F15 is alpha. And this laptop is old. (That's why it's my Fedora alpha guinea pig, each time a new Fedora Alpha release comes out.) But... this is bad, guys. Really bad. Essentially, you've bricked it. The only saving grace is that F15 (specifically, KMS) knows how to temporarily unbrick the panel while it's running. That's why I'm filing this bug report: I'm hoping that providing details and feedback, I can provide enough information for you to figure out (and undo!) whatever you've done to brick it. As I said, I don't *think* the base F15 alpha did it, as I'm pretty sure I remember seeing the GRUB splash screen at least once (if only from the reboot after installed from the DVD). But it's definitely bricked now.
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.)