Suspending to RAM with hibernate-script

From ArchWiki
Jump to navigation Jump to search


In this article we will explain how to accomplish a successful suspension to ram: all the processes are stopped and the current state of your machine is saved to ram. All the devices enter a low-consumption state and it will be very fast to resume the machine. Suspension to RAM is an acpi state, but the operation is almost never as simple as telling the machine to enter that state. The vast majority of laptops require additional operations and tricks. However, since this is quite an important feature for laptop users, it is worth spending some hours in finding the working combinations of tricks for your machine.

Different Methods of Suspending to RAM

There is an application, called s2ram, which contains a "whitelist" of known laptop models and, according to what has been reported by other owners of these laptops, tries to do the right things for that specific laptop. The whitelisted laptops can therefore use s2ram to suspend to ram "out of the box". Non-whitelisted laptops need to try different command line options of s2ram in order to determine - by trial and error - the appropriate "tricks" needed to make suspend and resume work. Your experience, if reported to the s2ram developers, will contribute to whitelist your machine in the next release of s2ram.

However, s2ram is not the only resource: the hibernate-script, which is commonly used to accomplish Suspend to Disk , supports also suspension to RAM and proposes some further tricks which could convince your machine to suspend to ram and resume properly. Moreover, the hibernate-script can automatize other useful operations which you could want/need to do before suspension or after resuming from suspension to ram.

Thus, the first part of this article will be devoted to s2ram. The second will discuss the use of the hibernate-script in suspension to ram. In particular, we will see how the hibernate-script can be used to suspend to ram your system just with the s2ram, but providing some additional tweakings. Finally, we will mention the possibility to suspend the machine both to ram and to disk.


The s2ram utility is part of the uswsusp collection, which includes also some goodies relative to Suspend to Disk . You can find uswsusp in the community repositories.

# pacman -S uswsusp

Read the notes provided by pacman during the uswsusp package installation. In essence, you will need to:

  • edit /etc/suspend.conf to specify the resume device, i.e. your swap partition.
resume device = /dev/sdXY
  • update /etc/mkinitcpio.conf to include the uresume hook
HOOKS="base udev autodetect pata scsi sata uresume filesystems"
  • rebuild the ramdisk
mkinitcpio -p kernel26

After installing the uswsusp package, check to see whether s2ram recognizes your machine:

# s2ram -n

If you see a line that says "Machine matched entry #", then your machine is already whitelisted. You SHOULD be able to suspend and resume properly by simply running s2ram:

# s2ram

Please note that the way to trigger resume from a suspended to RAM machine depends from your BIOS settings and is not predictable in general (sometimes it is enough to press a key whatsoever). If s2ram seems to work, but something goes wrong in the suspension cycle, then some driver or some process is causing problems and you should look at the hibernate section to see how the hibernate-script can help you. In the worst case, your machine has been erroneously whitelisted due to an inadequate report from another owner of the same machine. You should then report your case to the, so that the previous mistaken report can stand corrected. In this case, you should quote the identification strings provided by s2ram -i.

If s2ram doesn't match your machine to an entry in its whitelist, it will output some general purpose identification strings for your machine (the same as those provided s2ram -i). In this case, you will have to force s2ram to suspend your machine by using s2ram -f.

If s2ram -f doesn't work, try the different workarounds offered by s2ram. Run s2ram -h to get a list of the possible options:

# s2ram -h
Usage: s2ram [-nhi] [-fspmrav]

   -h, --help:       this text.
   -n, --test:       test if the machine is in the database.
                     returns 0 if known and supported
   -i, --identify:   prints a string that identifies the machine.
   -f, --force:      force suspending, even on unknown machines.

The following options are only available with -f/--force:
   -s, --vbe_save:   save VBE state before suspending and restore after resume.
   -p, --vbe_post:   VBE POST the graphics card after resume
   -m, --vbe_mode:   get VBE mode before suspend and set it after resume
   -r, --radeontool: turn off the backlight on radeons before suspending.
   -a, --acpi_sleep: set the acpi_sleep parameter before suspend
                     1=s3_bios, 2=s3_mode, 3=both
   -v, --pci_save:   save the PCI config space for the VGA card.

Try the following variations:

  s2ram -f -a 1
  s2ram -f -a 2
  s2ram -f -a 3
  s2ram -f -p -m
  s2ram -f -p -s
  s2ram -f -m
  s2ram -f -s
  s2ram -f -p
  s2ram -f -a 1 -m
  s2ram -f -a 1 -s

If none of those combinations work, start again but add the "-v" switch.

Note that mixing the "-a" options and the vbetool options ("-p", "-m", "-s") is normally only a measure of last resort, it usually does not make much sense.

If you find several combinations that work (e.g. "s2ram -f -a 3" and "s2ram -f -p -m" both work on your machine), the in-kernel method ("-a") should be preferred over the userspace methods ("-p", "-m" and "-s").

Verify all combinations in both cases when reporting success to the s2ram developers:

  • when issuing s2ram from console
  • when issuing s2ram from X

You should really try ANY combination of these options (the only exception is the radeontool one, which can be useuful only if you have a radeon card), until you find a working combination. When you find a working combination, try to reduce it (that is try to see if any of the options are redundant). With any working combination of options, it is crucial to verify that suspension and resuming work fine both if you suspend from X and if you suspend from the plain console. Actually, in many setups the most tricky thing is to suspend and resume properly from the console. In the best case, s2ram -f is enough: this means that your machine does not require any trick to properly suspend and resume.

There is a trick which does not correspond to a command line option, because it requires additional operations from you. It is marked with NOFB in the whitelist and used for those laptops which suspend and resume properly only if no framebuffer is used. If you verify that no command line option of s2ram works, you can try to disable the framebuffer. In order to do this, you need to edit your grub configuration /boot/grub/menu.lst (or the corresponding lilo file), remove the vga=<foo> value from the kernel line and reboot. This at least if you use the VESAFB framebufeer (as in the arch default kernel). If you use a different framebuffer driver, refer to the documentation of the driver to see how to disable it.

After you have identified the shortest working combination of options, you should do two things. First, you will want to modify the whitelist for your local copy of s2ram to allow your machine to suspend and resume without any special options. Second, you will want to let the developers of s2ram know what options are needed for your machine so it can be added to the whitelist for future releases s2ram.

Finally, it may happen that no trick makes s2ram work. In this case - before giving up - you can use some last-resort tricks provided by the hibernation-script discussed later in this article.


To add your machine to the local whitelist for s2ram, you need to customize the package from ABS. Copy the /var/abs/community/system/uswsusp folder somewhere then run makepkg -o to download the sources. After this, edit the file src/suspend-0.8/whitelist.c

You will see something like this:

struct machine_entry whitelist[] = {

{ "IBM", "", "ThinkPad X32", "", RADEON_OFF|S3_BIOS|S3_MODE }, /* Michael Wagner <> */ { "4MBOL&S", "7521 *", "REV. A0", "", 0 }, /* Alexander Wirt */


Add a new entry using the same format as the others. The first four fields identify your machine and are provided by:

# s2ram -i


sys_vendor   = "Acer, inc."
sys_product  = "Aspire 1640     "
sys_version  = "Not Applicable"
bios_version = "3A05"

Copy these values between the first four sets of quotes. The fifth field identifies which tricks are needed for your machine, seperate each of the tricks with a | character, like the other lines in the file. If no tricks were required, set it to 0.

Now force a recompilation and reinstallation of uswsusp with makepkg -efi (The -e prevents makepkg from overwriting your customized whitelist.c). Your machine should now suspend properly with a plain:

# s2ram

You can now report your identification strings and any tricks required to the mailing list. Please specify always that everything works both from X and from the plain console.

The hibernate-script and suspension to ram

The hibernate-script, developed in the field of the tuxonice project for Suspend to Disk, can be used also to suspend your machine to ram. Actually, he can also try to do this directly, performing the required operations before calling the ACPI S3 state. However, the s2ram seems to be the leading method nowadays and, through the named whitelist, should assure in the future that virtually any laptop can suspend to ram without too much hassle. So, the actually best way to use the power of the hibernate-script for suspension to ram is to use it to call s2ram.

You can edit /etc/hibernate/hibernate.conf to select ususpend-ram.conf as the default action called by:

# hibernate

Just put the following as the first uncommented line:

 TryMethod ususpend-ram.conf

However, may be that you want to use the hibernate-script primarily to suspend to disk. In that case you should resort to the ram-specific configuration file from the command line:

# hibernate -F /etc/hibernate/ususpend-ram.conf

Now you should configure the script. Please note that the options that you put in /etc/hibernate/common.conf will be used anytime you call hibernate (that is also for suspension to disk). On the contrary, the options in /etc/hibernate/ususpend-ram.conf will be used only when you suspend to ram with the s2ram method.

The hibernate-script options are exhaustively described in the man page hibernate.conf.

First of all, may be that some module is preventing you from accomplishing a proper suspension cycle. In this case, list it in the UnloadModules: it will be unloaded before suspension and reloaded after resuming. Note that the hibernation script already does this for some blacklisted modules, whose list is /etc/hibernate/blacklisted-modules.

If you discover that a module is guilty, you should report this to the, so that the bad behaviour of the module can be fixed.

May be also that your display is the guilty and that the tricks provided by s2ram are not enough. The hibernate-script has some further tricks:

The relevant block of options is the following:

### vbetool
#EnableVbetool yes
#RestoreVbeStateFrom /var/lib/vbetool/vbestate
#VbetoolPost yes
# RestoreVCSAData yes
### xhacks
#SwitchToTextMode yes
#UseDummyXServer yes
#DummyXServerConfig xorg-dummy.conf

However, most of these tricks are already attempted by s2ram and you should not duplicate the effort. Only three tricks in this section are specific to the script. The first is to uncomment both the following two lines:

EnableVbetool yes
RestoreVbeStateFrom /var/lib/vbetool/vbestate

Please note that, while s2ram uses an internal vbetool component, the hibernate-script relies on the vbetool package in the extra repo, so you should install it. Basically, this combination of options do something similar to the --vbe_save s2ram option, but, instead of restoring the state saved immediately before suspension, it restores a state manually saved by the user in the file /var/lib/vbetool/vbestate (or any other file you have chosen). You can try to save the state in a peculiar safe situation, like immediately after booting, or before any switching from X to console and back. You can save the state with the following command:

# vbetool vbestate save > /var/lib/vbetool/vbestate

The second peculiar trick (very often required!) is to uncomment the following line:

SwitchToTextMode yes

The script will switch from X to console before suspension and back to X after a successful resuming.

Finally, the UseDummyXServer trick uses a second XServer, with a minimal safe configuration only during the suspension cycle, restoring the full fledged X server only after a complete resume. This can be useful with cards with problematic proprietary drivers: the dummy xserver will use the standard vesa driver instead. Anyway, this last trick should be seldom useful nowadays, because also proprietary drivers seem to support suspension without too many problems.

The hibernate-script gives you many other useful possibilities (such as restarting services, unmounting partitions, ejecting pccards, and so on). Read about them in the man pages.


You can also suspend your machine both to disk and to ram. This is documented in a specific section of the wiki page about suspension to disk.

Automatic Suspend and Wakeup

Once you have suspend to ram working, you will probably want it to happend automatically e.g., when you close the laptop lid.

There are several ways to do this. The easiest is to use a high-level power management tool such as KDE's PowerDevil. Another is to create your own ACPI event handler scripts.

Automatic Suspend, the Hard Way

ACPI events are managed by configuration files in /etc/acpi/events/. (The laptop-mode-tools package contains some examples). A default configuration file called 'anything' is provided by the acpid package, which runs /etc/acpi/ on every event.

An simple event configuration file to manage the opening and closing of a laptop lid (that could be called /etc/acpi/events/lid) looks like this:

event=button[ /]lid
action=/etc/acpi/actions/ %e

The first line specifies the names of the events applicable to this file with a regexp. You can get the names of events by enabling event logging in acpid and looking at /var/log/acpid.

The second line specifies an executable to be run when an applicable event occurs. The '%e' is a variable containing arguments that the event provides. It's a good idea to provide them to the program.

It's customary to put handling programs in /etc/acpi/actions/. A possible implementation of in the previous example could be:

# check if the lid is open or closed, using the /proc file
if grep closed /proc/acpi/button/lid/LID/state >/dev/null ; then
    # if the lid is now closed, save the network state and suspend to ram
    netcfg all-suspend
    # if the lid is now open, restore the network state.
    # (if we are running, a wakeup has already occured!)
    netcfg all-resume

With some basic knowledge of shell scripting, you have a lot of possibilities.

Controlling Wakeup

The ACPI events that trigger wakeup are controlled through the procfile /proc/acpi/wakeup. An example output is:

root@hex in /proc/acpi $ cat wakeup
Device  S-state   Status   Sysfs node
LID       S3    *enabled
PBTN      S4    *enabled
MBTN      S5     enabled
PCI0      S3     disabled  no-bus:pci0000:00
USB0      S0     disabled  pci:0000:00:1d.0
USB1      S0     disabled  pci:0000:00:1d.1
USB2      S0     disabled  pci:0000:00:1d.2
USB3      S0     disabled  pci:0000:00:1d.3
EHCI      S0     disabled  pci:0000:00:1d.7
AZAL      S3     disabled  pci:0000:00:1b.0
PCIE      S4     disabled  pci:0000:00:1e.0
RP01      S4     disabled  pci:0000:00:1c.0
RP02      S3     disabled
RP03      S3     disabled
RP04      S3     disabled  pci:0000:00:1c.3
RP05      S3     disabled
RP06      S3     disabled

To toggle whether an event will trigger a wakeup, pipe its name into the /proc/acpi/wakeup. (Note that every name in the file must have 4 letters, so if it is shorter e.g. LID, it needs be prepended with spaces). So to prevent opening the laptop lid from triggering a wakeup, you could do:

root@hex in /proc/acpi $ echo " LID" > wakeup
root@hex in /proc/acpi $ cat wakeup
Device  S-state   Status   Sysfs node
LID       S3    *disabled
PBTN      S4    *disabled
MBTN      S5     disabled
PCI0      S3     disabled  no-bus:pci0000:00

Another thing to note is that the PBTN and MBTN events were also toggle with the LID event. Sometimes events are linked, so that all of them will be enable and disabled in unison. Checking the 'dmesg' command can confirm this:

root@hex in /proc/acpi $ dmesg
ACPI: 'PBTN' and 'LID' have the same GPE, can't disable/enable one seperately
ACPI: 'MBTN' and 'LID' have the same GPE, can't disable/enable one seperately

This may not actually affect the other events. On a Dell Inspiron 6400, for example, the power button always triggers a wake up. Your mileage may vary.

None of this will persist between boots, so you might want to add the echo command to /etc/rc.local so it is executed on every boot:

# disable the laptop lid switch
echo " LID" > /proc/acpi/wakeup