This is part of my linux-laptop web site: http://www.cs.bham.ac.uk/~axs/laptop
I also use hibernate and suspend without problems on my Desktop PC running Fedora 19 (F19).
The new method uses the latest
Fedora 17 (FC17) Tuxonice kernel, with the hibernate-tuxonice and
dracut-tuxonice utilities, all downloadable from:
http://mhensler.de/swsusp/download_en.php
and available in his yum repository:
http://mhensler.de/swsusp/repository_en.php
However, it requires editing /etc/hibernate/tuxonice.conf to set
UseTuxOnIce "no"
and thereafter hibernating with the 'hibernate' command, not
'pm-hibernate'. The edit in tuxonice.conf only needs to be done
once, after installing hibernate-tuxonice.
Exactly why that is required to allow resume/thaw after hibernate always to succeed remains a mystery to be investigated.
The great advantage of this method, compared with the best alternative described below, is that it does not require a copy of grub.cfg to be edited after each kernel upgrade, and it does not require hibernate to be run with a special script that temporarily replaces grub.cfg, and restores the old value after resume.
It also does not require the boot flag 'maxcpus=1' for resume, which could presumably affect speed.
See also https://bugzilla.redhat.com/show_bug.cgi?id=862475 comment 47.
So the problem is still a mystery, but a totally reliable work-around seems to be use of boot parameter 'maxcpus=1' in grub.cfg before resuming. At present this requires two versions of grub.cfg, one for full reboot, and one for resume. Only the latter has the extra boot parameter included. (There should be a way to make it unnecessary to use different grub.cfg files for booting and resuming.)
A usable but messy way to automate this is described in the work around section below.
I shall describe command-line utilities since those are what I use. Your system may give you menu options to activate suspend or hibernate. In order to use my method described below you will need either to use the command line or change one of your menus to invoke the commands described here.
The two options for saving the state are:
The command 'pm-suspend' is the default command for initiating a suspend (to RAM) process . Whether this works for you on linux can depend on the hardware you are using as explained in http://www.brighthub.com/environment/green-computing/articles/9738.aspx
I shall say no more about use of pm-suspend as I use only the next alternative: suspend to hard drive.
The default command for achieving this is 'pm-hibernate'. However, if you install tuxonice on your machine, as described in http://tuxonice.net/, the command is replaced by 'hibernate'. I used tuxonice for several years on a succession of Dell laptops but after I acquired a Dell Latitude E6410 in June 2010, with integrated intel graphics I started having difficulties concerned with the Video module i915 (and its predecessor), required for use with the intel graphics card.
Later I switched to pm-hibernate which I eventually got to work as described below. Many users have reported problems with i915 and either (pm-)hibernate or suspend. The solution I have found now seems to work very reliably for me. I am describing it here in the hope that others may find this useful. It is not ideal, but it does seem to be reliable.
As explained above, on the laptop I have also tried running without this workaround on an experimental kernel, to try to locate the bug.
The hibernate failing problem was
fixed, at least for users of Fedora 16, by the end of March 2012, in
kernel 3.3. See
https://bugzilla.redhat.com/show_bug.cgi?id=785384
Since then hibernation has been very reliable and very fast on my 4-core
Intel core-i5 cpu, on both laptop and desktop PC.
The process takes advantage of multiple CPUs to do
the compression of the image being written to the hard drive in several
parallel streams. I have not encountered hibernate freezing since the
end of March 2012.
However, the other problem, resume failing, remains.
23 Jul 2012 Warning about dual-boot installations:
if you switch between linux and windows, don't use 're-start' or
're-boot' in windows to return to linux as that stops hibernate
working. Instead shut down completely from windows, then power up, then
select linux.
Update 14 Oct 2012: This turned out to be a side effect of using
'acpi=off' in grub.cfg to allow resume from pm-hibernate. I have not
checked whether that problem remains since switching to use of
'maxcpus=1' instead.
In my case the process gets very close to completion, but just as the display should switch to the mode it was in before hibernating occurred, the machine crashes and initiates a reboot.
This does not happen every time. When I try using pm-hibernate several times in succession, resume may or may not complete successfully.
The rest of this file describes a workaround.
So I tried inserting two menu entries in the grub.cfg file, identical except that one had maxcpus=1 and one did not. I used the one without for booting the machine, but after hibernating I used the menu entry with maxcpus=1 (which I set as the default grub menu option, since I very rarely reboot).
That works very reliably both on my Viglen Genie desktop PC running Fedora 16, with intel integrated graphics and my Dell Latitude E6410, also with intel integrated graphics. Both machines use the i915 module (required for intel graphics) which some people suspect is the cause of the problems.
This solution required me to remember to edit the grub.cfg file after a kernel update, making a copy of the new entry without the special flag, to be used for booting and one with the special flag, for resuming from hibernate. Doing the hibernates by hand was error-prone (and a mistake could produce an unbootable machine requiring rescue by using a Live-CD, to fix the edit). Also, the kernel update process (on Fedora) uses a program called 'grubby' which copies the kernel settings from the running kernel for the new kernel, which meant that by default I had maxcpus=1 set for the new kernel. So if I forgot to edit the grub.cfg file before rebooting after an update I booted in an unsatisfactory mode.
My messy but working solution is to create two simple shell scripts called
#!/bin/bash ## edit-grub ## Aaron Sloman http://www.cs.bham.ac.uk/~axs ## 31 May 2012 ## This is used after a new kernel is installed. It makes a copy of ## grub.cfg called grub.cfg-resume which it edits so as to insert 'maxcpus=1' ## as a boot flag in the kernel line. ## ## It also alters the menu heading to show RESUME so that after ## hibernate when the machine is next booted there is a reminder that ## hibernate, not shut-down, was used. ## ## This program uses 'ed'. It would probably be better to use 'sed', ## but I am unfamiliar with it, and can't be bothered to learn just now. ## go to directory containing grub.cfg cd /boot/grub2 ## save the old version of grub.cfg-resume mv grub.cfg-resume grub.cg-resume-bak ## make a copy of the latest grub.cfg, called grub.cfg-resume ## and edit it as described above. cp grub.cfg grub.cfg-resume ed grub.cfg-resume << \\\\ 1p /menuentry/p s/i686)/i686)RESUME/p /vmlinuz/p s/$/ maxcpus=1/p w q \\
#!/bin/bash
## do-hibernate
##
## Aaron Sloman http://www.cs.bham.ac.uk/~axs
## 31 May 2012
##
## This is used to hibernate after saving grub.cfg and copying
## grub.cfg-resume to grub.cfg, so that when resuming after hibernate
## the flag 'maxcpus=1' will be used, inserted into grub.cfg-resume by
## the edit-grub script
##
## After successful resume, the saved version of grub.cfg is restored
##
## The use of killall plugin-container is not essential, but I noticed
## that with firefox running the size of plugin-container could grow very large
## and it seemed unnecessary to include that in the hibernate image, since it
## is automatically restarted on demand.
cd /boot/grub2
if [ -f grub.cfg-resume ]; then
echo "killall plugin-container"
killall plugin-container
## Make sure windows partitions are unmounted
## If you sometimes mount windows partitions on the hard drive in
## linux it's a good idea to unmount them all before hibernating,
## in case you do something in windows inconsistent with the information
## saved in linux.
## This is an example -- edit or remove, as needed:
##echo "unmounting /win7c"
umount /win7c
echo "Ready to hibernate"
echo "Saving grub.cfg"
mv grub.cfg grub.cfg-saved
echo "Set up grub.cfg-resume as grub.cfg"
cp -p grub.cfg-resume grub.cfg
sleep 2
/usr/sbin/pm-hibernate
echo "Restore grub.cfg-saved"
mv grub.cfg-saved grub.cfg
else
echo "Cannot find grub.cfg-resume"
exit
fi
A minor risk is that if the resume ever does not complete I shall have the wrong version of grub.cfg and will have to restore grub.cfg-saved manually. If I forget to do that the next boot will present me with the 'RESUME' option showing, and I can edit the grub command from the boot menu to remove the maxcpus=1 portion. Then after booting I can restore the grub.cfg-saved file. However, since resume now works very reliably I don't expect to have that problem.
I have been using this solution now since early May 2012. I was offered the option of editing scripts used by grub2 but that was unacceptably obscure and messy.
Ideally the kernel code invoked by pm-hibernate should be changed so that during the resume process, if it detects that the i915 module is being used, it should turn off acpi before the last stage of resuming. Then when the saved image is restored the state will have acpi on again as it was when the last pm-hibernate command was given.
REMINDER: see the warning about re-starting/re-booting from inside windows above.
NOTE added 15 Jun 2012 -- revised 14 Oct 2012:
I noticed that when I resume with the acpi=off or the maxcpus=1 switch
set in grub.cfg (which always resumes perfectly) it reports using only 1
thread for decompression (though it still goes very fast). If I resume
without that setting then it reports using 3 threads for decompression.
In both cases pm-hibernate uses 3 threads for compression.
So I wondered whether the crash+reboot on resume could be connected with
use of 3 threads for
decompression. With help from Bojan Smojver I managed to rule out
a decompression bug as cause of the resume failure. Details in this
bugreport (between comments 22 and 28):
https://bugzilla.redhat.com/show_bug.cgi?id=862475
Installed: 29 May 2012
Last updated: 31 May 2012; 15 Jun 2012; 23 Jul 2012; 14 Oct
2012; 20 Oct 2012