Description of problem: Systems using the 'nv' driver for Nvidia graphics cards will not reactivate their display upon resume from suspend or hibernate. Version-Release number of selected component (if applicable): RHEL5.1 (xorg-x11-drv-nv-2.1.2-1.el5) How reproducible: Always Steps to Reproduce: 1. Install RHEL5.1 on a system using an Nvidia card and the 'nv' driver 2. Suspend or hibernate the system 3. Wake the system up from suspend or hibernation Actual results: Brief text-mode display, then nothing appears on the screen. Expected results: Regular X display Additional info: The systems aren't dead; you can ssh to them after they've resumed, but you can't access virtual terminals or use X after resume. Using the vesa driver instead of nv results in a properly working system after waking it up from a suspend or a hibernate.
Resume works fine in text mode if you disable all the VBE quirks. Something in the additional work being done by vesa restore is kicking the display engine back to life. Adding to 5.2 radar for scheduling purposes.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
For this platform this may be something that can be quirked around with either pm-suspend options or BIOS settings. However, in the general case, this is not getting solved without enhancing the nv driver to do native POST. Leaving on the 5.2 radar in case a magic quirks combo suddenly presents itself, but that will almost certainly end up as a fix to hal-info and not xorg-x11-drv-nv.
Plan in place to fix in 5.3. Solution not available in 5.2 time frame.
*** Bug 441575 has been marked as a duplicate of this bug. ***
Can you please attach the output of; lshal | grep "system\." | grep -v uuid Thanks.
Richard, Here is the output from a RHEL5.1 install. I'm working on a 5.2 install right now. # lshal | grep "system\." | grep -v uuid process 5690: Applications must not close shared connections - see dbus_connection_close() docs. This is a bug in the application. system.product = 'Precision M4300' (string) system.vendor = 'Dell Inc.' (string) system.chassis.type = 'Portable' (string) system.chassis.manufacturer = 'Dell Inc.' (string) system.firmware.release_date = '11/05/2007' (string) system.firmware.version = 'A05' (string) system.firmware.vendor = 'Dell Inc.' (string) system.hardware.serial = '27ZH1F1' (string) system.hardware.version = 'Not Specified' (string) system.hardware.product = 'Precision M4300' (string) system.hardware.vendor = 'Dell Inc.' (string) smbios.system.serial = '27ZH1F1' (string) smbios.system.version = 'Not Specified' (string) smbios.system.product = 'Precision M4300' (string) smbios.system.manufacturer = 'Dell Inc.' (string) system.hardware.primary_video.product = 1069 (0x42d) (int) system.hardware.primary_video.vendor = 4318 (0x10de) (int) system.formfactor = 'laptop' (string) system.kernel.machine = 'i686' (string) system.kernel.version = '2.6.18-53.el5' (string) system.kernel.name = 'Linux' (string)
Requested command output for rhel5.2 beta: # lshal | grep "system\." | grep -v uuid system.product = 'Precision M6300' (string) system.vendor = 'Dell Inc.' (string) system.chassis.type = 'Portable' (string) system.chassis.manufacturer = 'Dell Inc.' (string) system.firmware.release_date = '10/24/2007' (string) system.firmware.version = 'A01' (string) system.firmware.vendor = 'Dell Inc.' (string) system.hardware.serial = '8P6J1F1' (string) system.hardware.version = 'Not Specified' (string) system.hardware.product = 'Precision M6300' (string) system.hardware.vendor = 'Dell Inc.' (string) smbios.system.serial = '8P6J1F1' (string) smbios.system.version = 'Not Specified' (string) smbios.system.product = 'Precision M6300' (string) smbios.system.manufacturer = 'Dell Inc.' (string) system.hardware.primary_video.product = 1037 (0x40d) (int) system.hardware.primary_video.vendor = 4318 (0x10de) (int) system.formfactor = 'laptop' (string) system.kernel.machine = 'x86_64' (string) system.kernel.version = '2.6.18-90.el5' (string) system.kernel.name = 'Linux' (string)
Chris, can you please try (as root): pm-suspend --quirk-vbe-post --quirk-dpms-on pm-suspend --quirk-vbestate-restore --quirk-dpms-on pm-suspend --quirk-vbe-post --quirk-vbestate-restore --quirk-dpms-on This can be done on 5.1 or 5.2. I hope one of these will get things working. Thanks.
Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
Richard, Tried on RHEL5.2: # cat /etc/redhat-release Red Hat Enterprise Linux Client release 5.2 (Tikanga) # uname -a Linux dhcp243-111.rdu.redhat.com 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux Results: pm-suspend --quirk-vbe-post --quirk-dpms-on > fails pm-suspend --quirk-vbestate-restore --quirk-dpms-on > fails pm-suspend --quirk-vbe-post --quirk-vbestate-restore --quirk-dpms-on > fails I rebooted the system before running each command, and they all failed with the same description as originally stated. The display lights up and shows a brief text display, then the backlight goes out. --Chris
*** Bug 444861 has been marked as a duplicate of this bug. ***
All the changes for this in the nv driver are applied in xorg-x11-drv-nv-2.1.6-9.el5 MODIFIED
*** Bug 468134 has been marked as a duplicate of this bug. ***
tested on LVS 140M and GeForce 8400M. Resumes to a blank screen. Kicking back to modified. Note: looks like this is that same bug as 439256. Maybe the other should be dup of this one?
*** Bug 439256 has been marked as a duplicate of this bug. ***
We think its fixed in #468289. Cameron, can you test again w/ the new pm-utils?
To clarify some confusion: This BZ was created to change the way Video BIOS is handled in the NV driver during suspend/resume on Nvidia G80 and higher graphics. Nvidia changed the way video bios is initialized, which cased suspend/resume to fail. We have incorporated changes supplied by Nvidia, and should now be correctly saving and restoring the Video BIOS on G80 and higher cards. A separate problem in pm-utils has caused a large number of laptops, using different graphics chips, to fail to resume properly. This problem is addressed in BZ 468289. It appears that both the changes to the NV driver and changes to pm-utils are required to make suspend/resume work correctly.
To clarify one more bit of confusion: The only issue addressed in bug #468289 is the Z61t issue. Any other suspend/resume regressions should be filed as separate bugs.
I tested with the latest pm-utils on three machines. NVS 140 (T61P), GeForce 8400MG (Asus W7s), and a g70 core card in a desktop. None them resume. Snap4 x86_64 + pm-utils-0.99.3-10.el5.x86_64.rpm.
I stole cameron's T61 and tested. Even from text mode, 'vbetool post /var/run/video.rom' loses graphics, which means it sure isn't gonna work when coming back from resume. However, on an Acer Aspire 7520, it works fine. There's one notable difference between the two environments, in that the T61 is an amd64 image where the Acer is i386, so the latter will be using vm86 mode to resume and the former will be using the x86 emulator. Should test the T61 with an i386 image to see if that also fails. If it does, then the method nvidia proposed for resuming is probably not fully reliable; if the i386 image works though, then we're probably looking at an x86emu bug.
i386 image fails on the T61 as well. Simple re-POSTing by saving the ROM before suspend is perhaps not the most reliable method. Which is sort of obvious. If it would work, then why would nvidia go out of their way to disable it?
Release note: Improvements were made to the support of suspend and resume with some G80 and G90 equpped machines. Due to technical limitations, this will not enable suspend/resume on all hardware
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Improvements were made to the support of suspend and resume with some G80 and G90 equpped machines. Due to technical limitations, this will not enable suspend/resume on all hardware.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-0097.html