Bug 546994

Created attachment 377948 [details]
xorg.conf file currently in use

mouse button mappings needs to be added somewhere

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: 2.6.31.12-174.2.3.fc12.i686

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

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
problematic.
...
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
hibernating.
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"  
EndSection

to the following:

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

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?

(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).

Currently (kernel-2.6.32.12-115.fc12.i686, 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.

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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).

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.