Please read this notes before trying to use the suspend feature.
First, some definitions so there's no confusion about the used terms:
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).
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.
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:
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
- 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
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
If you'd like to try out suspend, you have to change the values of
/etc/powersave/sleep to "no" or
powersave command as superuser
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 "
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
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
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?
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
- 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
- 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
- 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
/var/log/suspend*.log. A state file that
records which services were stopped and which modules unloaded is in
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.