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

First, some definitions so there's no confusion about the used terms:
@itemize
@item 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).
@item 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.
@item 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.
@end itemize

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:
@itemize
@item	standby        - APM standby state
@item	suspend to RAM - APM suspend state. If the machine actually enters suspend
                    to disk or suspend to RAM depends on the BIOS settings.
@item	suspend to disk - machine suspends to disk using linux kernel swsusp method
@end itemize
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
(@code{powersave -U}, @code{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 
@code{DISABLE_USER_SUSPEND2DISK}, @code{DISABLE_USER_SUSPEND2RAM} or
@code{DISABLE_USER_STANDBY} in @code{/etc/powersave/sleep} to "no" or
run the @code{powersave} command as superuser @code{root}.

@cartouche
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.
@end cartouche

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 "@code{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 @code{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 @code{/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 "@code{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?
@itemize
@item 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
  "@code{ps auxfww}".
@item 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 @code{/etc/powersave/sleep}
  to @code{UNLOAD_MODULES_BEFORE_SUSPEND}.
@item 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
  @code{UNLOAD_MODULES_BEFORE_SUSPEND}.
@end itemize
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 @code{/var/log/suspend*.log}. A state file that
records which services were stopped and which modules unloaded is in
@code{/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 @url{http://www.suse.com/feedback} or on the suse-laptop
mailinglist to which you may subscribe via @url{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.