Suspend - Powersave Documentation

Next: SuspendNvidia, Previous: Thermal, Up: Top

5 Suspend

Please read this notes before trying to use the suspend feature.

First, some definitions so there's no confusion about the used terms:

suspend-to-disk:
saves the actual state of the machine to disk and powers it down. After this, external power and the batteries may be disconnected whithout losing data. At the next bootup, the previous state is resto- red and the computer resumes where the suspend was triggered. This is also called "suspend to disk" (STD), the ACPI term for this is ACPI S4. There are two ways for doing this: one is calling the BIOS and letting it save the state of the machine, this works mostly with APM BIOSes (see notes below), the other way is doing it ourselves in the kernel. The kernel implementation is called "swsusp" (for swap or software suspend) and is used with ACPI but can also be used for APM (see notes below).
suspend-to-RAM:
most of the devices in the computer are deactivated (disk drives, graphics chips, even the CPU) and only the RAM is powered to keep its contents. At resume, only the individual devices need to be reinitialized and work continues relatively fast. This is also called "suspend to RAM" (STR). It depends on the particular hardware, how long a notebook can be kept in standby without need of an external power supply. Better machines will last several days while others run flat after only a few hours. The ACPI term for STR is ACPI S3.
standby:
processes are stopped, some hardware is deactivated. The ACPI term for standby is ACPI S1. Not many machines support this state and the power savings are rather low.

With ACPI it is pretty straightforward: the operating system has to prepare itself for the upcoming sleep state and then enter it with (little) help of BIOS routines. This is still work in progress and not finished.

Unfortunately, things get a bit more complicated when using APM. With APM, there are only two states: standby and suspend. So with APM you get the following possible states:

standby - APM standby state
suspend to RAM - APM suspend state. If the machine actually enters suspend to disk or suspend to RAM depends on the BIOS settings.
suspend to disk - machine suspends to disk using linux kernel swsusp method

When the "suspend to RAM" routine is called, the BIOS actually decides if it does a STD or a STR. This can often be selected in the BIOS setup. Also, STD on APM machines almost always needs a special hibernation partition or a special file in a DOS partition which needs to be created with a vendor specific DOS or Windows program. On some machines with a Phoenix(R) BIOS you can create the special partition with the linux program "lphdisk". To confuse us even more, some machines (e.g. IBM Thinkpads) do STR or STD depending on which "suspend button" you have pressed (Fn-F4 is STR, Fn-F12 is STD) but there is no way for the powersave daemon to select if it wants to do STR or STD via standard APM BIOS calls. We have therefore decided to implement swsusp also for APM machines that is triggered on the STD powersave methods (powersave -U, kpowersave: Suspend to Disk).

Please note that suspend with ACPI is still experimental and may not work on all hardware. Especially suspend to RAM (ACPI S3) is very problematic on many machines. To avoid trouble for unwary users, we have disabled suspend and standby for normal users in the default configuration on non-notebook machines. If you'd like to try out suspend, you have to change the values of DISABLE_USER_SUSPEND2DISK, DISABLE_USER_SUSPEND2RAM or DISABLE_USER_STANDBY in /etc/powersave/sleep to "no" or run the powersave command as superuser root.

Warning:
failing suspend/standby-cycles can lead to filesystem corruption and loss of data, so try this only if you know what you are doing. For the first tries it is advisable to close all open files and have only a small number of programs and services active on the machine.

The powersave package provides a uniform interface to both APM and ACPI but there are still some differences, which have to be adressed by the configuration settings. You can determine the powermanagement system used by your machine with the command "powersave -S".

Using ACPI, suspend to disk is known to work better than standby / suspend to RAM, so try this first. For first tests it is advisable to set DEBUG to 7 or 15 to increase the verbosity of the powersaved and of the proxy scripts. You will find a lot of diagnostics output in /var/log/messages after restarting powersaved. Also, there are some modules/services which are known to cause problems with suspend, so be sure you installed the newest update kernel. 3D acceleration for graphic cards is known not to work with suspend sometimes (the binary only drivers from NVidia and ATI are a prominent example). However, this issue is being worked on and you already may be able to suspend with acceleration enabled. If you experience any hardware problems on suspend, we would appreciate to be informed about the hardware type that fails (for contact have a look at the end of this file).

So now you are ready to go? Fingers crossed?
Well, let's try. Open a terminal and issue "powersave -U". If everything goes well, the machine should switch to a text console after a few seconds, showing you some progress marks and finally power off. Power it back on and it should begin a normal boot but then recognize the saved image and resume. If everything goes well, the machine should be at the same state it was when the suspend started.

What can go wrong?

The machine does not switch to the text console and shutdown, it seems just "nothing is happening". Before the actual suspend process starts, some drivers are unloaded and some services are stopped. If unloading of a module is not possible, a message box will pop up and a message is written to the log. Look into /var/log/messages for failures to unload modules or stop services. The messages of the powersave daemon start with "powersaved" or "powersave". If you see nothing in the log, look for hanging processes trying to remove modules and stop services with "ps auxfww".
The machine reboots hard during resume. This is usually caused by incompatible device drivers. If it will retry the resume on the next boot, you have to pass the "noresume" option at the boot prompt or boot the "failsafe" menu entry once. Add suspicious modules in /etc/powersave/sleep to UNLOAD_MODULES_BEFORE_SUSPEND.
The resume seems to work fine, but some components do no longer work (e.g. USB Mouse or the network card). This is usually caused by drivers not fully implementing powermanagement support and can often be worked around by unloading the driver module before suspend and reloading it after resume. Add the module to UNLOAD_MODULES_BEFORE_SUSPEND.

To help debugging and finding the "bad" modules, you'll find a list of modules which were loaded and information about memory usage before your last suspend event in /var/log/suspend*.log. A state file that records which services were stopped and which modules unloaded is in /var/lib/suspend*-state.

Since suspend is in constant development and we don't have the possibility to test on every available hardware, we appreciate any feedback either via http://www.suse.com/feedback or on the suse-laptop mailinglist to which you may subscribe via http://www.suse.com (and even if you are trying suspend on a desktop machine, you are welcome on the suse-laptop mailinglist). Note, that this list is mostly german speaking, but you are generally welcome in english, too.