Ubuntu Wiki

There seems to be quite a bit of discussion about suspend-to-ram and suspend-to-disk support in Feisty. I think a large portion of the disagreements are rooted in the fact the overall suspend process and support are largely inconsistent and undocumented. Therefore, in an attempt to foster useful discussion, I will try to document the overall method of how software suspend works in Ubuntu.

Relevant Packages

Starting software suspend

There are multiple methods of starting a software suspend procedure. Each is associated with a different user-interface state.

Default (acpi events)

In the absence of any other overriding policy, acpi-support has full control over the software suspend process.

There are two categories of acpi suspend events, and they respectively execute two scripts:

These scripts are either executed directly, or in-directly by a mapping of the third-party sleep/hibernate button events to the normal sleepbtn event.

GDM

GDM has menu-items specifically for "hibernate" and "suspend" (sleep). These call the powermanagement-interface directly via the following commands:

The powermanagement-interface scripts execute the acpi-support scripts with an override for any other policy.

Gnome

gnome-power-manager is the official policy and user-interface for power management in Gnome. When it is running, the several power management related acpi-support scripts specifically disable themselves. Their normal actions will not occur except when specifically requested via a "force" command-line option.

The software suspend policy of gnome-power-manager is actually handled by hal.

KDE

Software suspend policy

Once a software suspend has been requested, some program must perform the "policy" for it. That is, actually ensure the system is in a suitable state for suspension. And later, return the system to (roughly) the same state it was before the software suspend occurred.

acpi-support

These much maligned scripts now have a long history behind them, and apparently fairly rich support for a variety of hardware. However, they are also almost completely Ubuntu specific.

The two earlier mentioned scripts, /etc/acpi/hibernate.sh and /etc/acpi/sleep.sh handle the heavy lifting. Documenting their every contortion is beyond the scope of this article; however, the overall process is as follows:

hal

As hal is designed to be operating system agnostic, there is a (mostly dummy) front-end handler script initially called and then a specific worker script:

• is this the setup in feisty? On my edgy system scripts are in /usr/share/hal/scripts and there is no scripts/linux directory -- MattPrice

These scripts have several bugs and inconsistencies between them. (Free easy bug-fixing opportunity here!) However, in terms of Ubuntu, a selection process for what will perform the hiberate/suspend is performed:

1. powermanagement-interface

2. powersaved

3. (hibernate only) freedesktop's pm-utils (do you mean "suspend-to-disk only"?)

4. uswsusp

5. hibernate (suspend2)

6. acpi-support

7. Direct to /sys/power/state sysfs interface.

In a default Ubuntu installation, powermanagement-interface is installed and therefore will always win. This results in hal handing off policy back to acpi-support.

• Am I right in thinking this is a ranked ordering, so that installing hibernate on top of a default ubuntu system will never allow hibernate to take over the suspend process? --MattPrice

• If a user wants to make changes to the default suspend procedures, what's the right level at which to intervene? Is it possible to rationalize this system so that system-specific changes only need to be made to one set of scripts? --MattPrice

  • I filed a patch for that at https://bugs.launchpad.net/ubuntu/+source/hal/+bug/90425

kpowersave

As of 0.7.2, kpowersave also uses HAL

Kernel suspend technologies

Inconsistencies

• There does not appear to be a default handler for the hibernatebtn acpi event.

• acpi-support will use uswsusp for hibernation but not sleep.

Alternatives

uswsusp

currently in the Universe repository: http://packages.ubuntu.com/cgi-bin/search_packages.pl?keywords=uswsusp&searchon=names&subword=1&version=all&release=all Contains these binaries:

• s2disk - suspend to disk (hibernate)
• s2ram - suspend to RAM (sleep). Not in Edgy.
• s2both - kind of a mixture of the two above. First saves the RAM contents to the swap partition and then goes to sleep. Not in Edgy.

Note: can do compression and encryption when hibernating. Integration with usplash.

Suspend2

Suspend2 is a kernel patch which enables a second suspend method at the kernel level. Because it uses compression, it is generally somewhat quicker than swsusp, and it has a number of other features such as a pretty user interface. Some users also find that suspend2 is more reliable at suspending/resuming than swsusp, but this is almost always because those users use a different power-management interface -- the hibernate script package.

This page used to say:

The complexity of the suspend management system and the multiple changes that are made to the system when suspend2 is added make it difficult to diagnose precisely why one method works when another does not. If the whole stack were made as implementation-agnostic as possible (e.g. if acpi-support would try suspend2 as well as uswsusp and swsusp, and if suspend2's more advanced configuration features were accessible somehow within the default stack) would go a long way towards making suspend2 easier to use on ubuntu.

Suspend2 has, however, included support for transparent replacement of swsusp for some time. It should therefore be trivial to see whether reliability is improved simply by using Suspend2, or because of using the hibernate script in place of the above mentioned stack. Support for replacing swsusp by default is enabled at kernel compile time, and can be temporarily disabled at run time by echoing 0 or 1 to /sys/power/suspend2/replace_swsusp. At boot time, any attempt to resume via swsusp also invokes a check to resume a Suspend2 image, since we can't know until we check for an image which method was used when we suspended.

The default configuration in the Suspend2 patch has replacing swsusp enabled, and builds and configures LZF compression support. Any resume= parameter will override resume2=, and Suspend2 understands swsusp's simpler resume2=/dev/<partition> format, and will thus work out of the box in most cases. For swapfiles, a different method of telling where to find the image header is used (resume[2]=[swap:]/dev/<partition><sector>). The values to be used can be found by swapon'ing swap devices, then catting /sys/power/suspend2/swap/header_locations:

• #cat /sys/power/suspend2/swap/headerlocations For swap partitions, simply use the format: resume2=swap:/dev/hda1.

  For swapfile /swapfile, use resume2=swap:/dev/hda2:0xe4058.

CategoryLaptop