Difference between revisions of "Suspend to RAM"

From ArchWiki
Jump to navigation Jump to search
m (Other Resources: rm unrelated link)
m (Other Resources: rm unrelated links)
Line 56: Line 56:
You might want to tweak your '''DSDT table''' to make it work. See [[DSDT]] article
You might want to tweak your '''DSDT table''' to make it work. See [[DSDT]] article
== Other Resources ==
*{{ic|/usr/src/linux-2.6.38-ARCH/Documentation/power/interface.txt}} Kernel Power Management Interface
*{{ic|/usr/src/linux-2.6.38-ARCH/Documentation/power/states.txt}} System Power Management States

Revision as of 20:01, 27 July 2013

Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary end From Wikipedia:Sleep mode:

Sleep mode can go by many different names, including Stand By, Sleep, and Suspend. When placed in this sleep mode, aside from the RAM which is required to restore the machine's state, the computer attempts to cut power to all unneeded parts of the machine. Because of the large power savings, most laptops automatically enter this mode when the computer is running on batteries and the lid is closed.

This article describes generally mechanisms to suspend Arch Linux system to memory. There are multiple low level interfaces (backends) providing basic functionality, and some high level interfaces providing tweaks to handle problematic hardware drivers/kernel modules (e.g. video card re-initialization).

Low level interfaces

Though these interfaces can be used directly, it is advisable to use some of high level interfaces to suspend/resume. Using low level interfaces directly is significantly faster using any high level interface, since running all the pre- and post-suspend hooks takes time, but hooks can properly set hardware clock, restore wireless etc.

kernel (swsusp)

The most straightforward approach is to directly inform the in-kernel software suspend code (swsusp) to enter a suspended state; the exact method and state depends on the level of hardware support. On modern kernels, writing appropriate strings to /sys/power/state is the primary mechanism to trigger this suspend.

See http://acpi.sourceforge.net/documentation/sleep.html for details.


The uswsusp ('Userspace Software Suspend') provides s2ram, a wrapper around the kernel's suspend-to-RAM mechanism, which performs some graphics adapter manipulations from userspace before suspending and after resuming.

See main article Uswsusp.


TuxOnIce is a fork of the kernel implementation of suspend/resume that provides kernel patches to improve the default implementation. It requires a custom kernel to achieve this purpose.

See main article TuxOnIce.

High level interfaces

Note that the end goal of these packages is to provide binaries/scripts that can be invoked to perform suspend/resume. Actually hooking them up to power buttons or menu clicks or laptop lid events is left to other mechanisms. To automatically suspend/resume on certain power events, such as laptop lid close or battery depletion percentage, you may want to look into running Acpid.


systemd provides native commands for suspend, hibernate and a hybrid suspend, see Power Management#Power management with systemd for details.

See Power Management#Sleep hooks for additional information on configuring suspend/resume hooks. Also see man systemctl, man systemd-sleep, and man systemd.special.


pm-utils is a set of shell scripts that encapsulate the backend's suspend/resume functionality. It comes with a set of pre- and post-suspend tweaks and various hooks to customize the process.

See main article pm-utils.



You might want to tweak your DSDT table to make it work. See DSDT article