After a lot of experimentation, I believe I have figured out how to suspend and
hibernate flawlessly with my laptop. Here are, I think, the relevant features:
It's this easy:
(1) Edit the file /etc/pm/functions-intel and comment out the
entire definition of
resume_video. That definition will then look like this:
Code:
#resume_video()
#{
#(
# /usr/sbin/vbetool post
# /usr/sbin/vbetool vbestate restore < /v</ol>
ar/run/vbestate
#) >/dev/null 2>&1
#}
(2) Add the kernel boot parameter
to the end of the
default boot line beginning "kernel /vmlinuz" in /boot/grub/grub.conf/
In fact, I'm not sure that "acpi_sleep=s3_bios" does anything, but it doesn't do any harm.
To suspend to RAM, click on "Suspend" in the System pull down menu. To hibernate to disk, select "Shut Down", then click on "Suspend" in the shut down dialog box. When I installed FC5 on my laptop, the default gnome-power-manager setting when the computer is running on the battery is to suspend to RAM when the lid is closed. The default setting is to wake up from either suspension or hibernation when the lid is opened.
In the power management configuration window (System -> Preferences -> More preferences -> Power management), on the Running on Battery tab, you
might want to set "Put the computer to sleep when it has been inactive for:" to
"Never". The reason is that if you suspend or hibernate for longer than this
setting, then on resuming, the gnome-power-manager wakes up and realizes that the
computer has been inactive for longer than the allowed time. So it immediately
suspends. (Look in /var/log/messages to see that this is what is going on.) Yes, this is goofy.
Commenting out the entire resume_video function in functions-intel is fairly
radical. This function is given a trivial definition in /etc/pm/functions, so it
isn't left entirely undefined. Many people just comment out the "vbetool post"
line. (I first saw this in one of Firewing1's many elegant and patient postings in
these Forums.) I've found that this works most of the time, but once in a while it
doesn't. For some reason, it almost never does right after I backup my /home
directory to a CD (mkisofs, followed by cdrecord). The video hasn't failed to resume
once since commenting out the entire definition.
There is a small price to pay for leaving the video to restore itself. If you
suspend from a text terminal (for example: cntl-alt-F2; login as root; run
"/usr/sbin/pm-suspend"), then on resuming the screen will be black. To recover,
cntl-alt-F7 takes you back to a perfectly resumed gnome desktop. To fix the
display on vt 2, go back: cntl-alt-F2. Now the display is pale blue-grey with
rows of white dots blinking in unison. Type "clear" and hit return, and you're
back in business.
The blinking white dots effect will also appear on vt 63, which is used while suspending/hibernating.
If you use automount, you may want to shut it down before suspending and restart it
afterwards. I use automount to mount samba shares in my LAN. I've found that if
I don't shut down autofs before suspending, and I stay suspended for a while, then
when I resume, the shared directories may be unavailable and can neither be mounted
nor umounted. I added the lines
Code:
/etc/init.d/smb stop
/etc/init.d/autofs stop
at the top of /usr/sbin/pm-suspend and /usr/sbin/pm-hibernate. I also added the
lines
Code:
/ect/init.d/autofs start
/etc/init.d/smb start
at the bottom of both of those files.
Possible problems. There are two ways that suspending/hibernating can fail. Both are hard to diagnose, because there is never any evidence left in logs, and seldom much to go
on.
The classic failure is for everything to resume properly except the video.
Since taking vbetool out of the process by commenting out the definition of
resume_video in /etc/pm/functions-intel, this hasn't happened once.
The other way I've seen suspending/hibernating fail is for the system to hang when
suspending, or more often, when resuming. My experience has been that this is
caused by something else going wrong. One example is that, initially, I had the
new xorg i810 video driver and xserver installed, but not the mesa-libGL
libraries. 3D rendering didn't work properly, and the system hung about half the
time when resuming. (Incidentally, with the mesa libraries installed, my
experience is that the new i810 driver is outstanding. It puts the ati-fglrx driver
on my 64 bit desktop computer to shame.)
Another example is that after running hal-device-manager, usually emacs stops
recognizing the "super" key. Often the emacs server then hangs and has to be
killed. Afterwards the system may well hang when resuming. There's a bug here
somewhere.
The point with both of these examples is, I think, that the real problem is
somewhere else, not with suspending/resuming. I almost never shut down or reboot
any more. I just suspend during the day and hibernate over night.
Linear Mode
