Power management/Suspend and hibernate
Currently there are three methods of suspending available: suspend to RAM (usually called just suspend), suspend to disk (usually known as hibernate), and hybrid suspend (sometimes aptly called suspend to both):
- Suspend to RAM method cuts power to most parts of the machine aside from the RAM, which is required to restore the machine's state. Because of the large power savings, it is advisable for laptops to automatically enter this mode when the computer is running on batteries and the lid is closed (or the user is inactive for some time).
- Suspend to disk method saves the machine's state into swap space and completely powers off the machine. When the machine is powered on, the state is restored. Until then, there is zero power consumption.
- Suspend to both method saves the machine's state into swap space, but does not power off the machine. Instead, it invokes usual suspend to RAM. Therefore, if the battery is not depleted, the system can resume from RAM. If the battery is depleted, the system can be resumed from disk, which is much slower than resuming from RAM, but the machine's state has not been lost.
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).
- 1 Low level interfaces
- 2 High level interfaces
- 3 Hibernation
- 4 Troubleshooting
Low level interfaces
Though these interfaces can be used directly, it is advisable to use some of high level interfaces to suspend/hibernate. Using low level interfaces directly is significantly faster than 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.
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 kernel documentation for details.
The uswsusp ('Userspace Software Suspend') is 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.
High level interfaces
The end goal of these packages is to provide binaries/scripts that can be invoked to perform suspend/hibernate. Actually hooking them up to power buttons or menu clicks or laptop lid events is usually left to other tools. To automatically suspend/hibernate on certain power events, such as laptop lid close or battery depletion percentage, you may want to look into running Acpid.
See Power management#Sleep hooks for additional information on configuring suspend/hibernate hooks. Also see , , and .
In order to use hibernation, you need to create a swap partition or file. You will need to point the kernel to your swap using the
resume= kernel parameter, which is configured via the boot loader. You will also need to configure the initramfs. This tells the kernel to attempt resuming from the specified swap in early userspace. These three steps are described in detail below.
About swap partition/file size
Even if your swap partition is smaller than RAM, you still have a big chance of hibernating successfully. According to kernel documentation:
/sys/power/image_sizecontrols the size of the image created by the suspend-to-disk mechanism. It can be written a string representing a non-negative integer that will be used as an upper limit of the image size, in bytes. The suspend-to-disk mechanism will do its best to ensure the image size will not exceed that number. However, if this turns out to be impossible, it will try to suspend anyway using the smallest image possible. In particular, if "0" is written to this file, the suspend image will be as small as possible. Reading from this file will display the current image size limit, which is set to 2/5 of available RAM by default.
You may either decrease the value of
/sys/power/image_size to make the suspend image as small as possible (for small swap partitions), or increase it to possibly speed up the hibernation process.
See Systemd#Temporary files to make this change persistent.
Required kernel parameters
The kernel parameter
resume=swap_partition has to be used. Either the name the kernel assigns to the partition or its UUID can be used as
swap_partition. For example:
resume=/dev/archVolumeGroup/archLogicVolume-- example if using LVM
Generally, the naming method used for the
resume parameter should be the same as used for the
Hibernation into swap file
Using a swap file instead of a swap partition requires an additional kernel parameter
The value of
swap_file_offset can be obtained by running
filefrag -v swap_file, the output is in a table format and the required value is located in the first row of the
physical_offset column. For example:
# filefrag -v /swapfile
Filesystem type is: ef53 File size of /swapfile is 4294967296 (1048576 blocks of 4096 bytes) ext: logical_offset: physical_offset: length: expected: flags: 0: 0.. 0: 38912.. 38912: 1: 1: 1.. 22527: 38913.. 61439: 22527: unwritten 2: 22528.. 53247: 899072.. 929791: 30720: 61440: unwritten ...
In the example the value of
swap_file_offset is the first
38912 with the two periods.
The value of
swap_file_offset can also be obtained by running
swap-offset swap_file. The swap-offset binary is provided by package AUR.
resumekernel parameter specifies the device of the partition that contains the swap file, not swap file itself! The parameter
resume_offsetinforms the system where the swap file starts on the resume device. Before the first hibernation a reboot is required for them to be active.
- If using uswsusp, then these two parameters have to be provided in
/etc/suspend.confvia the keys
resume offset. No reboot is required in this case.
Configure the initramfs
- When an initramfs with the
basehook is used, which is the default, the
resumehook is required in
/etc/mkinitcpio.conf. Whether by label or by UUID, the swap partition is referred to with a udev device node, so the
resumehook must go after the
udevhook. This example was made starting from the default hook configuration:
HOOKS=(base udev autodetect keyboard modconf block filesystems resume fsck)
- Remember to regenerate the initramfs for these changes to take effect.
- Note: LVM users should add the
- When an initramfs with the
systemdhook is used, a resume mechanism is already provided, and no further hooks need to be added.
You might want to tweak your DSDT table to make it work. See DSDT article
Add acpi_sleep=nonvs kernel flag to your loader, and you are done!
Suspend/hibernate doesn't work, or not consistently
There have been many reports about the screen going black without easily viewable errors or the ability to do anything when going into and coming back from suspend and/or hibernate. These problems have been seen on both laptops and desktops. This is not an official solution, but switching to an older kernel, especially the LTS-kernel, will probably fix this.
Sometimes the screen goes black due to device initialization from within the initramfs. Removing any modules you might have in Mkinitcpio#MODULES and rebuilding the initramfs, can possibly solve this issue, specially graphics drivers for early KMS. Initializing such devices before resuming can cause inconsistencies that prevents the system resuming from hibernation. This does not affect resuming from RAM. Also, check this article for the best practices to debug suspend/hibernate issues.
For Intel graphics drivers, enabling early KMS may help to solve the blank screen issue. Refer to Kernel mode setting#Early KMS start for details.
If Wake-on-LAN is active, the network interface card will consume power even if the computer is hibernated.
Instantaneous wakeups from suspend
For some Intel Haswell systems with the LynxPoint and LynxPoint-LP chipset, instantaneous wakeups after suspend are reported. They are linked to erroneous BIOS ACPI implementations and how the
xhci_hcd module interprets it during boot. As a work-around reported affected systems are added to a blacklist (named
XHCI_SPURIOUS_WAKEUP) by the kernel case-by-case.
Instantaneous resume may happen, for example, if a USB device is plugged during suspend and ACPI wakeup triggers are enabled. A viable work-around for such a system, if it is not on the blacklist yet, is to disable the wakeup triggers. An example to disable wakeup through USB is described as follows.
To view the current configuration:
$ cat /proc/acpi/wakeup
Device S-state Status Sysfs node ... EHC1 S3 *enabled pci:0000:00:1d.0 EHC2 S3 *enabled pci:0000:00:1a.0 XHC S3 *enabled pci:0000:00:14.0 ...
The relevant devices are
XHC (for USB 3.0). To toggle their state you have to echo the device name to the file as root.
# echo EHC1 > /proc/acpi/wakeup # echo EHC2 > /proc/acpi/wakeup # echo XHC > /proc/acpi/wakeup
This should result in suspension working again. However, this settings are only temporary and would have to be set at every reboot. To automate this take a look at systemd#Writing unit files. See BBS thread for a possible solution and more information.