Differences between revisions 11 and 12
Revision 11 as of 2007-07-29 07:01:42
Size: 6917
Editor: ?timrichardson
Revision 12 as of 2007-07-29 15:23:06
Size: 6866
Editor: ?timrichardson
Deletions are marked like this. Additions are marked like this.
Line 69: Line 69:
+ '''uswsusp''' recommended by pm-utils. the pm-utils scripts look for the executables in this package. It is a modern set of programs to handle suspend to ram and hibernate (suspend to disk): this package is the home of s2ram + '''uswsusp''' optional but recommended by pm-utils. the pm-utils scripts look for the executables in this package. Try to see if suspend and hibernate works without it first

Help on software suspend

This page gathers bits of information about getting software suspend to work in debian. Because software suspend is still experimental, it is not enabled by default on most machines. Depending on your system, a few more steps are needed to get suspend partially or fully working. However, many people find that it works quite well now.

For more reading material, see also the links at the bottom of this page about hibernate and suspend.

Suspend under lenny using Hal (example, kernel 2.6.21)

The Gnome Power Manager must be installed to enable suspend menu entries on the System -> Shut Down dialog.

However, power management events are not only initiated by the menu system. The computer's power button may be pressed, for example. A key package for Lenny's power management is HAL which watches for ACPI events. HAL has a built-in ACPI module, so you don't need to install the separate ACPI packages.

Power management events are handled by a "policy manager", which decides what do to once a power management event is generated. gnome-power-manager is a policy manager. But it still doesn't actually do any real work, such as suspending the system.

The policy manager (gnome power manager) sends its request for action back to HAL, and HAL then looks for power management scripts to do the real work. Installing HAL with no power management software will log messages to /var/log/messages, but nothing else will happen. You can try this by removing the pm-utils package.

The package pm-utils is a package of power management software. It is actually a "front" to give common interface for HAL; it stands between HAL and actually suspending the system. pm-utils is designed for specific customisations to be "hooked" into it. This means that scripts in the directory /usr/lib/pm-utils/sleep.d are executed at suspend and resume. (pm-utils actually looks first in /etc/pm/sleep.d, but in the default Debian configuration, these directories are empty).

hibernate and "thaw" are handled almost the same.

This is getting a bit complicated, so I will summarise where we are: You choose "suspend". the gnome-power-manager sends a message to HAL, and HAL is pleased to find scripts from pm-utils: it calls pm-suspend. It may pass pm-suspend some specific instructions based on hardware quirks (see below)

pm-suspend runs any scripts it finds to prepare for suspension. Some kernel modules are unloaded, for example.Then it calls a program to cause suspend to happen, requiring the OS to talk to the motherboard. pm-suspend can ask to ask the kernel to suspend, but first it looks for the program s2ram (using the kernel is a fall-back).

(note: the man page for pm-suspend is interesting and easy to understand)

All this message sending may seem like a lot of work, but by putting HAL in the centre, some big advantages are gained. One is that HAL includes a growing database of hardware, and it can use "quirks" to tweak the suspend, hibernate and resume operations. HAL therefore lets all Linux distributions share this hardware-specific knowledge. This database pf quirks is in the Debian package hal-info.

About pm-utils

We stick with the script pm-suspend as the topic to explore further. It is a shell script, in /usr/sbin/pm-suspend. What it does is logged to /var/log/pm-suspend.log

pm-suspend runs a number of shell scripts that do specific tasks to prepare for suspend, and then executes the the suspend. The suspend operation is optionally handled by the Linux kernel, but pm-suspend looks first to see if the package uswsusp is installed (more accurately, it looks for the program called s2ram). If it finds s2ram, it uses this. Using s2ram seems to be the preferred way of working.

You should also have a look at the log file mentioned above.

On my system, I see from the log file that /usr/lib/pm-utils/sleep.d is the source of about ten scripts executed when a suspend occurs. They are executed in alphabetical order. You will notice that the same scripts are executed on a resume, but in reverse order. There is a script to handle network connections: it calls the gnome package network manager, so you should probably be using it.

Summary of relevant packages for HAL and pm-utils

Here is a list of packages linked to power management. Only HAL seems to be necessary for gnome to work.

+ HAL Central to the modern power management approach

+ hal-info rules for specific hardware

+ pm-utils required for the configuration discussed here. Key scripts are placed in /usr/sbin and /usr/lib/pm-utils/sleep.d

+ uswsusp optional but recommended by pm-utils. the pm-utils scripts look for the executables in this package. Try to see if suspend and hibernate works without it first

+ powermgmt-base provides some status scripts that are relied upon by other parts of Gnome and Debian, but it is not central to the operation of suspend and resume.

+ ACPI-Support not needed (included in HAL)

+ acpid not needed

+ acpi not needed

+ libacpi0 not needed

+ hibernate not needed

Information for older kernels

Older versions of Debian do not use HAL as discussed above. They rely on the ACPI pakcages, and scripts handling acpi events.

The following scripts were needed to get suspend to ram working on a ?ThinkPad X22 running linux-image 2.6.14-2 and tracking unstable.

Script /etc/acpi/events/custom_sleepbtn


Script /etc/acpi/events/custom_lid


Script /etc/acpi/actions/custom_sleep.sh

# enable xscreensaver
source /proc/`pidof xscreensaver`/environ && xscreensaver-command -lock

## optional: eject all pcmcia devices
#cardctl eject || true

# go to sleep
echo mem > /sys/power/state

Make sure the files you create in /etc/acpi/actions are executable:

$ sudo chmod +x /etc/acpi/actions/custom_sleep.sh

The first two links refer to old approaches.