Power management/Suspend and hibernate
There are multiple methods of suspending available, notably:
- Suspend to idle
- Called S0ix by Intel, Modern Standby (previously "Connected Standby") by Microsoft and S2Idle by the kernel. Designed to be used instead of the S3 sleeping state for supported systems, by providing identical energy savings but a drastically reduced wake-up time.
- Suspend to RAM (aka suspend, aka sleep)
- The S3 sleeping state as defined by ACPI. Works by cutting off 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 (aka hibernate)
- The S4 sleeping state as defined by ACPI. 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.
- Hybrid suspend (aka hybrid sleep)
- A hybrid of suspending and hibernating, sometimes called suspend to both. Saves the machine's state into swap space, but does not power off the machine. Instead, it invokes the default suspend. Therefore, if the battery is not depleted, the system can resume instantly. 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).
Low level interfaces
Though these interfaces can be used directly, it is advisable to use the 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 the 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 kernel documentation for details.
Userspace (uswsusp)
The uswsusp ('Userspace Software Suspend') tools provide wrappers around the kernel's suspend-to-RAM mechanism, which perform some graphics adapter manipulations from userspace before suspending and after resuming. See main article Uswsusp.
High level interfaces
The 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.
systemd
systemd provides native commands for suspend, hibernate and a hybrid suspend; see Power management#Power management for details. This is the default interface used in Arch Linux.
See Power management#Sleep hooks for additional information on configuring suspend/hibernate hooks. Also see systemctl(1), systemd-sleep(8), and systemd.special(7).
Changing suspend method
On systems where S0ix suspension does not provide the same energy savings as the regular S3 sleep, or when conserving energy is preferred to a quick resume time, changing the default suspend method is possible.
Run the following command to see all suspend methods hardware advertises support for (current method is shown in square brackets[1]):
$ cat /sys/power/mem_sleep
[s2idle] shallow deep
If your hardware does not advertise the deep sleep status, check first if your UEFI advertises some settings for it, generally under Power or Sleep state or similar wording, with options named Windows 10, Windows and Linux or S3/Modern standby support for S0ix, and Legacy, Linux, Linux S3 or S3 enabled for S3 sleep. Failing that, you can keep using s2idle, consider using hibernation or try to patch the DSDT tables (or find a patched version online).
Confirm that your hardware does not exhibit issues with S3 sleep by testing a few sleep cycles after changing the sleep method:
# echo "deep" > /sys/power/mem_sleep
If no issues have been found, you can make the change permanent with the mem_sleep_default=deep kernel parameter.
In some opposite situations, faulty firmware advertises support for deep sleep, while only s2idle is supported. In this case, an alternative method for using s2idle is available through the SuspendState in sleep.conf.d(5):
/etc/systemd/sleep.conf.d/freeze.conf
[Sleep] SuspendState=freeze
Hibernation
In order to use hibernation, you must create a swap partition or file, and 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 so that the kernel will attempt to resume from the specified swap in early userspace. These three steps are described in detail below.
- See Dm-crypt/Swap encryption#With suspend-to-disk support when using encryption.
- linux-hardened does not support hibernation, see FS#63648.
- Hibernating to swap on zram is not supported, even when zram is configured with a backing device on permanent storage. logind will protect against trying to hibernate to a swap space on zram.
About swap partition/file size
Even if your swap partition is smaller than RAM, you still have a good chance of hibernating successfully. See "image_size" in the kernel documentation for information on the image_size sysfs(5) pseudo-file.
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. For systems with a large amount of RAM, smaller values may drastically increase the speed of resuming a hibernating system. systemd#systemd-tmpfiles - temporary files can be used to make this change persistent:
/etc/tmpfiles.d/hibernation_image_size.conf
# Path Mode UID GID Age Argument w /sys/power/image_size - - - - 0
The suspend image cannot span multiple swap partitions and/or swap files. It must fully fit in one swap partition or one swap file.[3]
Configure the initramfs
- When using a busybox-based initramfs, 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 theresumehook must go after theudevhook. This example was made starting from the default hook configuration:
HOOKS=(base udev autodetect modconf kms keyboard keymap consolefont block filesystems resume fsck)
- Remember to regenerate the initramfs for these changes to take effect.
- When an initramfs with the
systemdhook is used, a resume mechanism is already provided, and no further hooks need to be added.
Required kernel parameters
The kernel parameter resume=swap_device must be used. Any of the persistent block device naming methods can be used as swap_device. For example:
resume=UUID=4209c845-f495-4c43-8a03-5363dd433153resume="PARTLABEL=Swap partition"resume=/dev/archVolumeGroup/archLogicalVolume-- if swap is on a LVM logical volume (UUID and Label should also work)
The kernel parameters will only take effect after rebooting. To hibernate right away, obtain the volume's major and minor device numbers from lsblk and echo them in format major:minor to /sys/power/resume. If using a swap file, additionally echo the resume offset to /sys/power/resume_offset. [4]
For example, if the swap device is 8:3:
# echo 8:3 > /sys/power/resume
Or when hibernating to a swap file, if the swap file is on volume 8:2 and has the offset 38912:
# echo 8:2 > /sys/power/resume # echo 38912 > /sys/power/resume_offset
Hibernation into swap file
Using a swap file requires also setting the resume=UUID=swap_device_uuid and additionally a resume_offset=swap_file_offset kernel parameters. See the kernel documentation.
swap_device is the volume where the swap file resides and it follows the same format as for the root parameter.
On file systems other than Btrfs, 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 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 and the kernel parameter would be resume_offset=38912.
For Btrfs, do not try to use the filefrag tool, since the "physical" offset you get from filefrag is not the real physical offset on disk; there is a virtual disk address space in order to support multiple devices.[5] Instead, use the btrfs-inspect-internal(8) command. E.g.:
# btrfs inspect-internal map-swapfile -r /swap/swapfile
198122980
In this example, swap_file_offset is 198122980 and the kernel parameter would be resume_offset=198122980
- The following command may be used to identify
swap_device_uuid:findmnt -no UUID -T /swapfile - The following command may be used to identify
swap_file_offseton file systems other than Btrfs:filefrag -v /swapfile | awk '$1=="0:" {print substr($4, 1, length($4)-2)}' - The value of
swap_file_offsetcan also be obtained by runningswap-offset swap_file. The swap-offset binary is provided within the set of tools uswsusp. If using this method, then these two parameters have to be provided in/etc/suspend.confvia the keysresume deviceandresume offset. No reboot is required in this case.
- For a stacked block device such as an encrypted container (LUKS), RAID or LVM, the
resumeparameter must point to the unlocked/mapped device that contains the file system with the swap file. - If the swap file is in
/home/, systemd-logind will not be able to determine its size and thus will prevent hibernation with the following message:Failed to hibernate system via logind: Not enough swap space for hibernation. See systemd issue 15354 for two workarounds.
Hibernation into a thinly-provisioned LVM volume
Hibernation into a thinly-provisioned LVM volume is possible, but you have to make sure that the volume is fully allocated. Otherwise resuming from it will fail, see FS#50703.
You can fully allocate the LVM volume by simply filling it with zeros. E.g.:
# dd if=/dev/zero of=/dev/vg0/swap bs=1M status=progress
To verify the volume is fully allocated, you can use:
# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert swap vg0 Vwi-aot--- 10.00g pool 100
A fully allocated volume will show up as having 100% data usage.
discard in /etc/fstab and the -d/--discard option of swapon. Otherwise the used space will be deallocated.Intel Rapid Start Technology (IRST)
Intel Rapid Start Technology is a firmware method of hibernation that allows hibernating from sleep after a predefined interval or according to battery state. This should be faster and more reliable than regular hibernation as it is done by firmware instead of at the operating system level. Generally it must enabled in the firmware, and the firmware also provides support for setting the duration after suspend/battery event triggering hibernation. However, some devices–despite supporting IRST in the firmware–only allow it to be configured via Intel's Windows drivers. In such cases the intel-rst kernel module described below should be able to configure the events under Linux.
With Intel Rapid Start Technology (IRST) enabled, resuming from a deep sleep takes "a few seconds longer than resuming from S3 but is far faster than resuming from hibernation".
Many Intel-based systems have firmware support for IRST but require a special partition on an SSD (rather than an HDD). OEM deployments of Windows may have a pre-existing IRST partition which can be retained during the Arch Linux installation process (rather than wiping and re-partitioning the whole SSD). It should show up as an unformatted partition equal in size to the system's RAM.
If you intend to wipe and re-partition the whole drive (or have already done so), then the IRST partition must be recreated if you also plan on using the technology. This can be done by creating an empty partition equal in size to the system's RAM and by setting its partition type to GUID D3BFE2DE-3DAF-11DF-BA40-E3A556D89593 for a GPT partition or ID 0x84 for an MBR partition. You may also need to enable support for IRST in your system's firmware settings.
The duration of the IRST hibernation process (i.e., copying the "entire contents of RAM to a special partition") is dependent on the system's RAM size and SSD speed and can thus take 20–60 seconds. Some systems may indicate the process's completion with an LED indicator, e.g., when it stops blinking.
Configuring IRST hibernation events in the Linux kernel requires CONFIG_INTEL_RST built-in or as a module. Once loaded via modprobe intel_rst, it should create the files wakeup_events and wakeup_time under /sys/bus/acpi/drivers/intel_rapid_start/*/ that can be used for further configuration. This module is tersely documented, see the source drivers/platform/x86/intel/rst.c for more details.
See also the general Q&A and user guides for Intel Rapid Start Technology.
Troubleshooting
ACPI_OS_NAME
You might want to tweak your DSDT table to make it work. See DSDT.
Suspend/hibernate does not work, or does not work 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.
A problem may arise when using the hardware watchdog timer (disabled by default, see RuntimeWatchdogSec= in systemd-system.conf(5) § OPTIONS). A buggy watchdog timer may reset the computer before the system finishes creating the hibernation image.
Sometimes the screen goes black due to device initialization from within the initramfs. Removing any modules you might have in Mkinitcpio#MODULES, removing the kms hook and rebuilding the initramfs can possibly solve this issue, in particular with 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 the blog article best practices to debug suspend issues.
Moving from the ATI video driver to the newer AMDGPU driver could also help to make the hibernation and awakening process successful.
For NVIDIA users, blacklisting the module nvidiafb might help. [7]
Laptops with an Intel CPU that load the intel_lpss_pci module for a touchpad may face kernel panic on resume (blinking caps lock) [8]. The module needs to be added to initramfs as:
/etc/mkinitcpio.conf
MODULES=(... intel_lpss_pci ...)
Then regenerate the initramfs.
Wake-on-LAN
If Wake-on-LAN is active, the network interface card will consume power even if the computer is hibernated.
Instantaneous wakeups from suspend
See Wakeup triggers#Instantaneous wakeups from suspend.
If you are using Linux kernel 6.1 and above on an AMD CPU, this can also be caused by an S3-related control policy issue in the kernel. A temporary solution would be turning off wakeup on related i2c devices. You can find them by
$ ls /sys/bus/i2c/devices/*/power/wakeup
And the format of the device name should be i2c-ELAN0679:00 or i2c-MSFT0001:00. Then, test if the below command can enter suspend:
# echo disabled > /sys/bus/i2c/devices/device_name/power/wakeup # systemctl suspend
If it works, you can persist this config by adding udev rules:
/etc/udev/rules.d/99-avoid-i2c-wakeup.rules
KERNEL=="device_name", SUBSYSTEM=="i2c", ATTR{power/wakeup}="disabled"
System does not power off when hibernating
When you hibernate your system, the system should power off (after saving the state on the disk). Sometimes, you might see the power LED is still glowing. If that happens, it might be instructive to set the HibernateMode to shutdown in sleep.conf.d(5):
/etc/systemd/sleep.conf.d/hibernatemode.conf
[Sleep] HibernateMode=shutdown
With the above configuration, if everything else is set up correctly, on invocation of a systemctl hibernate the machine will shut down, saving state to disk as it does so.
Operating system not found (or wrong OS booting) when booting after hibernation
This can happen when the boot disk is an external disk, and seems to be caused by a BIOS/firmware limitation. The BIOS/firmware tries to boot from an internal disk, while hibernation was done from an OS on an external (or other) disk.
Set HibernateMode=shutdown as shown in #System does not power off when hibernating to solve the problem permanently. If you have already locked yourself out, you can try rebooting your system 4 times (wait for the error to appear each time), which on some BIOS'es forces a normal boot procedure.