School of Computer Science THE UNIVERSITY OF BIRMINGHAM

Getting hibernate (pm-hibernate) to work on linux (Fedora 16 and Fedora 17)
Aaron Sloman
http://www.cs.bham.ac.uk/~axs

This is part of my linux-laptop web site: http://www.cs.bham.ac.uk/~axs/laptop



NEWS

Update Dec 2012: the solution using tuxonice did not last, unfortunately.
I can no longer get tuxonice to work at all.
So I have gone back to the previous solution in the "work around" section
For me that is totally reliable, using Fedora 16 and Fedora 17.


Update 20 Oct 2012: Improved solution using Tuxonice with Fedora 17 (FC17) on Laptop

Thanks to help from Matthias Hensler (http://mhensler.de/swsusp/download_en.php) I now have a much better solution on my Dell Latitude E6410 than the one described in the workaround below.

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, on my Dell 6410, use of the 'hibernate' command works only if I first edit /etc/hibernate/tuxonice.conf to set

    UseTuxOnIce "no"
Thereafter hibernate 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.


Update 14 Oct 2012: Fedora 16 (FC16) on Desktop, Fedora 17 (FC17) on Laptop


CONTENTS


Introduction: Suspend and Hibernate

Linux provides two ways of saving the process state on a computer and then restoring it later on, with the computer powered down (mostly) in the intervening period:

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:

Two problems

For a while there were two problems with attempts to use pm-hibernate on machines with Intel integrated graphics and the i915 graphical module.

A work-around I can live with till the bug is fixed

Searching for reports from fellow-sufferers I found several tips for coping with hibernate problems, none of which helped except the suggestion to add 'acpi=off' to the boot flags in the grub.cfg file. Doing that allowed hibernate and resume to work, but it was not an acceptable solution since too many things did not work, including screen brightness adjustment.
I later found that the problems were reduced by using 'maxcpus=1' instead. But including that in grub.cfg for normal boot was too restrictive as it prevented use of all four cpus.

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

Both are available here: edit-grub and do-hibernate So all I have to do now is remember to run 'edit-grub' after a kernel update, and before I first attempt to hibernate. Then instead of using the 'pm-hibernate' command I invoke 'do-hibernate'.

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; 21 Oct 2012


Maintained by Aaron Sloman A.Sloman@cs.bham.ac.uk