Bug 414971 - Systems using the 'nv' driver will not activate display on resume from suspend or hibernate
Systems using the 'nv' driver will not activate display on resume from suspen...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xorg-x11-drv-nv (Show other bugs)
5.1
x86_64 Linux
high Severity high
: rc
: ---
Assigned To: Adam Jackson
desktop-bugs@redhat.com
: FutureFeature, HardwareEnablement
: 439256 441575 444861 468134 (view as bug list)
Depends On:
Blocks: 429701 441909 446125 447490 RHEL5u3_relnotes
  Show dependency treegraph
 
Reported: 2007-12-06 17:30 EST by Gary Case
Modified: 2013-01-10 02:55 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
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.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 15:55:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gary Case 2007-12-06 17:30:26 EST
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.
Comment 2 Adam Jackson 2007-12-06 18:14:23 EST
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.
Comment 4 RHEL Product and Program Management 2007-12-06 18:24:21 EST
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.
Comment 5 Adam Jackson 2008-01-17 16:58:21 EST
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.
Comment 7 Larry Troan 2008-02-13 08:01:48 EST
Plan in place to fix in 5.3. Solution not available in 5.2 time frame.
Comment 8 Zack Cerza 2008-04-10 13:47:13 EDT
*** Bug 441575 has been marked as a duplicate of this bug. ***
Comment 9 Richard Hughes 2008-04-17 08:43:46 EDT
Can you please attach the output of;

lshal | grep "system\." | grep -v uuid

Thanks.
Comment 10 Chris Tatman 2008-04-17 10:56:38 EDT
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)
Comment 11 Chris Tatman 2008-04-17 12:04:11 EDT
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)
Comment 12 Richard Hughes 2008-04-18 08:28:52 EDT
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.
Comment 13 Matěj Cepl 2008-06-12 09:39:34 EDT
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.
Comment 14 Chris Tatman 2008-06-12 12:34:25 EDT
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


Comment 15 Mikel Ward 2008-06-14 07:08:43 EDT
*** Bug 444861 has been marked as a duplicate of this bug. ***
Comment 20 Adam Jackson 2008-09-18 17:20:30 EDT
All the changes for this in the nv driver are applied in xorg-x11-drv-nv-2.1.6-9.el5

MODIFIED
Comment 24 Mikel Ward 2008-10-23 03:00:40 EDT
*** Bug 468134 has been marked as a duplicate of this bug. ***
Comment 25 Cameron Meadors 2008-11-20 16:13:46 EST
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?
Comment 26 Suzanne Yeghiayan 2008-11-25 14:32:33 EST
*** Bug 439256 has been marked as a duplicate of this bug. ***
Comment 27 Jonathan Blandford 2008-12-02 16:40:04 EST
We think its fixed in #468289.  Cameron, can you test again w/ the new pm-utils?
Comment 29 Russell Doty 2008-12-02 17:50:20 EST
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.
Comment 30 Zack Cerza 2008-12-03 14:23:58 EST
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.
Comment 31 Cameron Meadors 2008-12-03 14:33:24 EST
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.
Comment 32 Adam Jackson 2008-12-03 17:47:31 EST
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.
Comment 33 Adam Jackson 2008-12-08 11:26:06 EST
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?
Comment 36 Matthew Garrett 2008-12-16 10:43:55 EST
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
Comment 39 Suzanne Yeghiayan 2008-12-17 12:06:53 EST
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.
Comment 40 errata-xmlrpc 2009-01-20 15:55:03 EST
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

Note You need to log in before you can comment on or make changes to this bug.