Bug 546994 - suspend and hibernate do not restore video with Fedora 12 kernels (i915 video)
Summary: suspend and hibernate do not restore video with Fedora 12 kernels (i915 video)
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 12
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2009-12-13 02:55 UTC by Michal Jaegermann
Modified: 2010-12-04 01:44 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-12-04 01:44:56 UTC

Attachments (Terms of Use)
Xorg.0.log file from the affected laptop (26.30 KB, text/plain)
2009-12-13 02:55 UTC, Michal Jaegermann
no flags Details
xorg.conf file currently in use (1.70 KB, text/plain)
2009-12-13 02:58 UTC, Michal Jaegermann
no flags Details

Description Michal Jaegermann 2009-12-13 02:55:20 UTC
Created attachment 377947 [details]
Xorg.0.log file from the affected laptop

Description of problem:

Acer Travelmate 230 laptop with 82845G/GL video after an upgrade from F10 to F12 stopped restoring video after suspend/hibernate.  A rather nasty regression.  Both suspend and hibernate "work" in that sense that after a restore the laptop is "alive" and can be accessed over a network but no expected picture.  A screen is going "full blast", which can be easily seen from a tone quite different from the one when a screen is off, but it remains blank.  If one believes what shows up in /var/log/Xorg.0.log then everything is fine only nothing shows.

The situation does change when 'nomodeset' is applied.  At least for a  "short term" suspend and hibernate a video is restored.  But when I left a suspended laptop overnight then upon restore an expected picture blinked for a moment and after that a screen went dark.  Nothing which I tried could restore a picture short of killing gdm which restarted X.  Of course the whole desktop was lost that way.

Version-Release number of selected component (if applicable):

How reproducible:
all the time

Additional info:
This laptop was doing both suspend and hibernation very reliably with Fedora 10. This was likely an effect of fixed 20-video-quirk-pm-acer.fdi which followed lineds described in bug 437886.

Comment 1 Michal Jaegermann 2009-12-13 02:58:08 UTC
Created attachment 377948 [details]
xorg.conf file currently in use

mouse button mappings needs to be added somewhere

Comment 2 Michael Convey 2010-01-26 22:41:29 UTC
I have the same problem with my Toshiba Tecra M3 S636 laptop. Blank screen with blinking cursor in the upper left corner after resuming from hibernation. 

kernel version:

Installed the Nvidia drivers per the following thread: http://forums.fedoraforum.org/showthread.php?s=cf6d1c87b53f3bd73cda97c4a24482da&t=204752

Comment 3 Michael Convey 2010-03-09 22:00:19 UTC
According to the nvidia readme file (/usr/share/doc/xorg-x11-drv-nvidia-173xx-173.14.22/README.txt):

"There are a few known issues associated with notebooks:
o Display change hotkey switching is not available on all notebooks. In
some cases, the ACPI infrastructure is not fully supported by the NVIDIA
Linux Driver. Work is ongoing to increase the robustness of NVIDIA's
support in this area. Toshiba and Lenovo notebooks are known to be
o In many cases, suspending and/or resuming will fail. As mentioned above,
this functionality is very system-specific. There are still many cases
that are problematic. Here are some tips that may help:
o In some cases, hibernation can have bad interactions with the PCI
Express bus clocks, which can lead to system hangs when entering
hibernation. This issue is still being investigated, but a known
workaround is to leave an OpenGL application running when
o On notebooks with relatively little system memory, repetitive
hibernation attempts may fail due to insufficient free memory. This
problem can be avoided by running `echo 0 > /sys/power/image_size`,
which reduces the image size to be stored during hibernation.
o Some distributions use a tool called vbetool to save and restore VGA
adapter state. This tool is incompatible with NVIDIA GPUs' Video
BIOSes and is likely to lead to problems restoring the GPU and its
state. Disabling calls to this tool in your distribution's init
scripts may improve power management reliability.
Sometimes chipsets lose their AGP configuration during suspend, and may cause
corruption on the bus upon resume. The AGP driver is required to save and
restore relevant register state on such systems; NVIDIA's NvAGP is notified of
power management events and ensures its configuration is kept intact across
suspend/resume cycles.
Linux 2.4 AGPGART does not support power management, Linux 2.6 AGPGART does,
but only for a few select chipsets. If you use either of these two AGP drivers
and find your system fails to resume reliably, you may have more success with
the NvAGP driver."

From the nvidia's installation and configuration instructions (/usr/share/doc/xorg-x11-drv-nvidia-173xx-173.14.22/html/chapter-12.html):

"There are several choices for configuring the NVIDIA kernel module's use of AGP on Linux. You can choose to either use the NVIDIA builtin AGP driver (NvAGP), or the AGP driver that comes with the Linux kernel (AGPGART). This is controlled through the "NvAGP" option in your X config file:
Option "NvAGP" "0" ... disables AGP support
Option "NvAGP" "1" ... use NvAGP, if possible
Option "NvAGP" "2" ... use AGPGART, if possible
Option "NvAGP" "3" ... try AGPGART; if that fails, try NvAGP
The default is 3 (the default was 1 until after 1.0-1251).
You should use the AGP driver that works best with your AGP chipset. If you are experiencing problems with stability, you may want to start by disabling AGP and seeing if that solves the problems. Then you can experiment with the AGP driver configuration.
Also note that changing AGP drivers generally requires a reboot before the changes actually take effect.
If you are using a recent Linux 2.6 kernel that has the Linux AGPGART driver statically linked in (some distribution kernels do), you can pass the
agp=off parameter to the kernel (via LILO or GRUB, for example) to disable AGPGART support. As of Linux 2.6.11, most AGPGART backend drivers should respect this parameter."

Also, I found the following explanation very useful: http://www.amitsrivastava.net/2008-03-23-hibernate-suspend-resolved-ubuntu-gutsy-nvidia-dell-vostro/

In the end, I was able to get my Toshiba laptop to successfully resume from hibernation by changing the Device section of my xorg.conf file from the following:
Section "Device"  
     Identifier  "Videocard0"  
     Driver      "nvidia"  
     Option      "AddARGBGLXVisuals" "True"  

to the following:

Section "Device"  
     Identifier  "Videocard0"  
     Driver      "nvidia"  
     Option      "AddARGBGLXVisuals" "True"  
     Option      "NvAGP" "1"  

Even though resume from hibernation worked, when I use the command “cat /proc/driver/nvidia/agp/status ”, I get the following:

Status: Disabled  
 AGP initialization failed, please check the ouput  
 of the 'dmesg' command and/or your system log file  
 for additional information on this problem.

From this, I conclude resume from hibernation works when AGP is disabled and my system is not using either the NvAGP driver or the AGPGART driver. So, I changed my xorg.conf file to use the following option instead:

Option "NvAGP" "0"

After making this change, I tested hibernation again and it resumed without a problem.

Any thoughts on the pros and cons of trying to get the NvAGP driver to work vs. leaving AGP disabled altogether? What am I losing?

Comment 4 Michal Jaegermann 2010-03-09 23:58:18 UTC
(In reply to comment #3)
> According to the nvidia readme file

A summary of this report talks about i915 video, i.e. Intel.  I know that you added a comment #2 about Nvidia but that should be really a different bug (and you should be using nouveau if you expect any reaction here).

Comment 5 Michal Jaegermann 2010-05-24 20:26:00 UTC
Currently (kernel-, xorg-x11-drv-intel-2.9.1-1.fc12.i686,
xorg-x11-server-Xorg-1.7.6-4.fc12.i686) a return from hibernation does restore a video.  Not so after a suspend when a screen remains absolutely reliably blank.
Also turning a screen off from a screensaver results in a video permanently gone.

Comment 6 Bug Zapper 2010-11-04 03:30:00 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 7 Michal Jaegermann 2010-11-04 06:41:48 UTC
See bug 624316.  Regardless if this is an issue of overenthusiastic pm-utils or a kernel driver this is still broken (AFAIK; the affected machine is out of my reach for some time to come).

Comment 8 Bug Zapper 2010-12-04 01:44:56 UTC
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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