Power management/Suspend and hibernate: Difference between revisions

From ArchWiki
(update interlanguage links)
(→‎Configure the initramfs: include microcode hook to match the default /etc/mkinitcpio.conf)
 
(118 intermediate revisions by 25 users not shown)
Line 2: Line 2:
[[de:Bereitschaft und Ruhezustand]]
[[de:Bereitschaft und Ruhezustand]]
[[es:Power management (Español)/Suspend and hibernate]]
[[es:Power management (Español)/Suspend and hibernate]]
[[ja:サスペンドとハイバネート]]
[[ja:電源管理/サスペンドとハイバネート]]
[[pt:Power management (Português)/Suspend and hibernate]]
[[ru:Power management (Русский)/Suspend and hibernate]]
[[ru:Power management (Русский)/Suspend and hibernate]]
[[zh-hans:Power management/Suspend and hibernate]]
[[zh-hans:Power management/Suspend and hibernate]]
{{Related articles start}}
{{Related articles start}}
{{Related|Uswsusp}}
{{Related|systemd}}
{{Related|systemd}}
{{Related|Power management}}
{{Related|Power management}}
Line 13: Line 13:
{{Related articles end}}
{{Related articles end}}


Currently there are three methods of suspending available:
There are [https://docs.kernel.org/admin-guide/pm/sleep-states.html multiple methods] of suspending available, notably:


; Suspend to idle: Called [https://www.intel.com/content/www/us/en/docs/vtune-profiler/user-guide/2023-0/s0ix-states.html S0ix] by Intel, [https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby Modern Standby] (previously "Connected Standby") by Microsoft and [https://docs.kernel.org/admin-guide/pm/sleep-states.html#suspend-to-idle S2Idle] by the kernel. Designed to be used instead of the '''S3''' [[Wikipedia:ACPI#Global states|sleeping state]] for supported systems, by providing identical energy savings but a drastically reduced wake-up time. {{Tip|While this state is subject to battery drain issues on [https://www.dell.com/support/kbdoc/en-us/000143524/the-battery-drains-quicker-than-expected-on-a-dell-notebook-with-modern-standby-mode-enabled Windows] or [https://support.apple.com/guide/mac-help/mh40773/mac macOS] since they support waking devices in this state for network activity, the Linux software ecosystem does not currently make use of this feature and should be unaffected.}}
; 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 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 [[Wikipedia:Standby power|zero]] power consumption.
; 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 [[Wikipedia:Standby power|zero]] power consumption.
; Suspend to both: A hybrid of the aforementioned methods, sometimes called '''hybrid suspend'''. 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.
; 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).
The kernel provides basic functionality, and some high level interfaces provide tweaks to handle problematic hardware drivers/kernel modules (e.g. video card re-initialization).


{{Expansion|Document "suspend to idle" (called [https://docs.kernel.org/admin-guide/pm/sleep-states.html#suspend-to-idle S2Idle] by the kernel, [https://01.org/blogs/qwang59/2018/how-achieve-s0ix-states-linux S0ix] by Intel and [https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby Modern Standby] by Microsoft) and {{ic|/sys/power/mem_sleep}} values.}}
== Kernel interface (swsusp) ==


== Low level interfaces ==
{{Note|Although the kernel interface can be used directly, which is faster since no extra userspace handling is performed, it is advisable to use the [[#High level interface (systemd)|high level interface]]. It does a better job by performing additional safety checks, as well as providing pre- and post-suspend hook mechanisms in order to properly set the hardware clock, restore wireless, etc.}}


Though these interfaces can be used directly, it is advisable to use the [[#High level interfaces|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.
It is possible 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 {{ic|/sys/power/state}} is the primary mechanism to trigger this suspend.


=== Kernel (swsusp) ===
See [https://docs.kernel.org/admin-guide/pm/sleep-states.html#basic-sysfs-interfaces-for-system-suspend-and-hibernation kernel documentation] for details.


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 {{ic|/sys/power/state}} is the primary mechanism to trigger this suspend.
== High level interface (systemd) ==


See [https://docs.kernel.org/admin-guide/pm/sleep-states.html kernel documentation] for details.
{{Note|The goal of the high level interface is to provide binaries/scripts that can be invoked to perform suspend/hibernate and ways to hook extra preparatory/cleanup work into the said process. For automatically enter sleep state on power buttons, menu clicks, or laptop lid events, refer to [[Power management#ACPI events]].}}


=== Userspace (uswsusp) ===
[[systemd]] provides native commands for suspend, hibernate and a hybrid suspend. This is the default interface used in Arch Linux.


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.
{{ic|systemctl suspend}} should work out of the box. For {{ic|systemctl hibernate}} to work on your system you might need to follow the instructions at [[#Hibernation]].


See main article [[Uswsusp]].
There are also two modes combining suspend and hibernate:


== High level interfaces ==
* {{ic|systemctl hybrid-sleep}} suspends the system both to RAM and disk, so a complete power loss does not result in lost data. This mode is also called ''suspend to both''.
* {{ic|systemctl suspend-then-hibernate}} initially suspends the system to RAM as long as possible, then wakes it with an RTC alarm and hibernates. The RTC alarm is set with {{ic|HibernateDelaySec}} in {{man|5|systemd-sleep.conf}}. The default value is set by estimating the battery discharge rate to keep the system with 5% of battery, or two hours without one. Said estimation is obtained from the change in battery level after the time specified by {{ic|SuspendEstimationSec}} in {{man|5|systemd-sleep.conf}}, at which the system will briefly wake up to do the measurement (a measure is also made if the system is manually woken up from suspension).


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 [[#Sleep hooks]] for additional information on configuring suspend/hibernate hooks. Also see {{man|1|systemctl}}, {{man|8|systemd-sleep}}, and {{man|7|systemd.special}}.


=== systemd ===
== Changing suspend method ==


[[systemd]] provides native commands for suspend, hibernate and a hybrid suspend, see [[Power management#Power management with systemd]] for details. This is the default interface used in Arch Linux.
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.


See [[Power management#Sleep hooks]] for additional information on configuring suspend/hibernate hooks. Also see {{man|1|systemctl}}, {{man|8|systemd-sleep}}, and {{man|7|systemd.special}}.
{{Tip|S0ix is supposed to provide identical or better energy savings as S3 sleep. See Intel blog posts [https://web.archive.org/web/20230614200816/https://01.org/blogs/qwang59/2018/how-achieve-s0ix-states-linux How to achieve S0ix states in Linux], [https://web.archive.org/web/20230614200306/https://01.org/blogs/qwang59/2020/linux-s0ix-troubleshooting Linux S0ix Troubleshooting] and [https://web.archive.org/web/20230503102522/https://01.org/blogs/thac0/2019/idling-efficiently-linux-case-study Idling Efficiently on Linux: A Case Study] to check if you can make it work as intended. Users on Intel systems can use [https://github.com/intel/S0ixSelftestTool S0ixSelftestTool].}}
 
Run the following command to see all suspend methods hardware advertises support for (current method is shown in square brackets[https://docs.kernel.org/admin-guide/pm/sleep-states.html#basic-sysfs-interfaces-for-system-suspend-and-hibernation]):
 
{{hc|$ cat /sys/power/mem_sleep|
[s2idle] shallow deep
}}
 
If your hardware does not advertise the {{ic|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 {{ic|s2idle}}, consider using [[hibernation]] or try to patch the [[DSDT]] tables (or find a patched version online).
 
{{Note|This last solution is likely going to cause issues. Manufacturers have stopped fixing bugs with the ACPI S3 state since systems shipping with Windows are encouraged to use "Modern standby" by default; if they have voluntarily not advertised it, it is probably broken in some way.}}
 
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 {{ic|1=mem_sleep_default=deep}} [[kernel parameter]].
 
In some opposite situations, faulty firmware advertises support for {{ic|deep}} sleep, while only {{ic|s2idle}} is supported. In this case, an alternative method for using {{ic|s2idle}} is available through the {{ic|SuspendState}} in {{man|5|sleep.conf.d}}:
 
{{hc|/etc/systemd/sleep.conf.d/freeze.conf|2=
[Sleep]
SuspendState=freeze
}}


== Hibernation ==
== Hibernation ==


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 {{ic|1=resume=}} kernel parameter, which is configured via the boot loader. You will also need to [[#Configure the initramfs|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.
In order to use hibernation, you must create a [[swap]] partition or file, [[#Configure the initramfs|configure the initramfs]] so that the resume process will be initiated in early userspace, and specify the location of the swap space in a way that is available to the initramfs, e.g. {{ic|HibernateLocation}} EFI variable defined by [[systemd]] or {{ic|1=resume=}} [[kernel parameter]]. These three steps are described in detail below.


{{Note|
{{Note|
* See [[Dm-crypt/Swap encryption#With suspend-to-disk support]] when using [[encryption]].
* See [[dm-crypt/Swap encryption#With suspend-to-disk support]] when using [[encryption]].
* {{Pkg|linux-hardened}} does not support hibernation, see {{Bug|63648}}.
* {{Pkg|linux-hardened}} does not support hibernation, see {{Bug|63648}}.
* Hibernating to [[zram#Usage as swap|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. As an alternative, you can create multiple swap spaces, then hibernate into a swap file while keeping another swap space for zram enabled. See details in [[#Maintaining swap file for hibernation with zram]].
}}
}}


=== About swap partition/file size ===
=== About swap partition/file size ===


Even if your swap partition is smaller than RAM, you still have a big chance of hibernating successfully. See "image_size" in the [https://docs.kernel.org/admin-guide/pm/sleep-states.html?highlight=image_size#basic-sysfs-interfaces-for-system-suspend-and-hibernation kernel documentation] for information on the {{ic|image_size}} {{man|5|sysfs}} pseudo-file.
Even if your swap partition is smaller than RAM, you still have a good chance of hibernating successfully. See "image_size" in the [https://docs.kernel.org/admin-guide/pm/sleep-states.html?highlight=image_size#basic-sysfs-interfaces-for-system-suspend-and-hibernation kernel documentation] for information on the {{ic|image_size}} {{man|5|sysfs}} pseudo-file.


You may either decrease the value of {{ic|/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:
You may either decrease the value of {{ic|/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:
Line 73: Line 99:
=== Configure the initramfs ===
=== Configure the initramfs ===


* When an [[initramfs]] with the {{ic|base}} hook is used, which is the default, the {{ic|resume}} hook is required in {{ic|/etc/mkinitcpio.conf}}. Whether by label or by UUID, the swap partition is referred to with a udev device node, so the {{ic|resume}} hook must go ''after'' the {{ic|udev}} hook. This example was made starting from the default hook configuration:
* When using a busybox-based [[initramfs]], which is the default, the {{ic|resume}} hook is required in {{ic|/etc/mkinitcpio.conf}}. Whether by label or by UUID, the swap partition is referred to with a udev device node, so the {{ic|resume}} hook must go ''after'' the {{ic|udev}} hook. This example was made starting from the default hook configuration:


:{{bc|1=HOOKS=(base udev autodetect keyboard modconf block filesystems '''resume''' fsck)}}
:{{bc|1=HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block filesystems '''resume''' fsck)}}


:Remember to [[regenerate the initramfs]] for these changes to take effect.
:Remember to [[regenerate the initramfs]] for these changes to take effect.


:{{Note|[[LVM]] users should add the {{ic|resume}} hook after {{ic|lvm2}}.}}
:{{Note|If stacked storage is used for the swap space, e.g. [[dm-crypt]], [[RAID]] or [[LVM]], the final mapped device must be available in the early userspace and before the resume process is initiated. I.e. the {{ic|resume}} hook must be placed after hooks like {{ic|encrypt}}, {{ic|lvm2}}, etc. in such setups.}}


* When an initramfs with the {{ic|systemd}} hook is used, a resume mechanism is already provided, and no further hooks need to be added.
* When an initramfs with the {{ic|systemd}} hook is used, a resume mechanism is already provided, and no further hooks need to be added.


=== Required kernel parameters ===
=== Pass hibernate location to initramfs ===
 
When the system hibernates, the memory image is dumped to the swap space, which also includes the state of mounted file systems. Therefore, the hibernate location must be made available to the initramfs, i.e. before the root file system is mounted for resuming from hibernate to work.
 
Since {{Pkg|systemd}} v255 and {{Pkg|mkinitcpio}} v38, when the system is running on [[UEFI]], {{man|8|systemd-sleep}} will automatically pick a suitable swap space to hibernate into, and the information of the used swap space is stored in {{ic|HibernateLocation}} EFI variable. Upon next boot, {{man|8|systemd-hibernate-resume}} reads the location off the EFI variable and the system resumes. This means the following steps are not necessary unless the system is using legacy [[Arch boot process#BIOS|BIOS]] or you want to choose a different swap space from the automatically-selected one.
 
==== Manually specify hibernate location ====


The [[kernel parameter]] {{ic|1=resume=''swap_device''}} must be used. Any of the [[persistent block device naming]] methods can be used as {{ic|''swap_device''}}. For example:
The [[kernel parameter]] {{ic|1=resume=''swap_device''}} can be used, where ''swap_device'' follows the [[persistent block device naming]]. For example:


* {{ic|1=resume=UUID=4209c845-f495-4c43-8a03-5363dd433153}}
* {{ic|1=resume=UUID=4209c845-f495-4c43-8a03-5363dd433153}}
* {{ic|1=resume="PARTLABEL=Swap partition"}}
* {{ic|1=resume="PARTLABEL=Swap partition"}}
* {{ic|1=resume=/dev/archVolumeGroup/archLogicalVolume}} -- if swap is on a [[LVM]] logical volume (UUID and Label should also work)
* {{ic|1=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 be able to hibernate right away, obtain the volume's major and minor device numbers from [[lsblk]] and echo them in format {{ic|''major'':''minor''}} to {{ic|/sys/power/resume}}. If using a swap file, additionally echo the resume offset to {{ic|/sys/power/resume_offset}}.[https://docs.kernel.org/power/swsusp.html]
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 {{ic|''major'':''minor''}} to {{ic|/sys/power/resume}}.


For example, if the swap device is {{ic|8:3}}:
For example, if the swap device is {{ic|8:3}}:
Line 97: Line 129:
  # echo 8:3 > /sys/power/resume
  # echo 8:3 > /sys/power/resume


Or when hibernating to a swap file, if the swap file is on volume {{ic|8:2}} and has the offset {{ic|38912}}:
If using a swap file, additionally follow the procedures in [[#Acquire swap file offset]].
 
# echo 8:2 > /sys/power/resume
# echo 38912 > /sys/power/resume_offset


==== Hibernation into swap file ====
===== Acquire swap file offset =====


{{Warning|[[Btrfs#Swap file|Btrfs]] on Linux kernel before version 5.0 does not support swap files. Failure to heed this warning may result in file system corruption. While a swap file may be used on Btrfs when mounted through a loop device, this will result in severely degraded swap performance.}}
When using a [[swap file]] for hibernation, the block device on which the file system lies should be specified in {{ic|1=resume=}}, and additionally the physical offset of swap file must be specified through {{ic|1=resume_offset=}} [[kernel parameter]]. [https://docs.kernel.org/power/swsusp-and-swap-files.html]


Using a [[swap#Manually|swap file]] requires also setting the {{ic|1=resume=UUID=''swap_device_uuid''}} and additionally a {{ic|1=resume_offset=''swap_file_offset''}} [[kernel parameters]]. See [https://docs.kernel.org/power/swsusp-and-swap-files.html the kernel documentation].
On file systems other than [[Btrfs]], the value of {{ic|1=resume_offset=}} can be obtained by running {{ic|filefrag -v ''swap_file''}}. The output is in a table format and the required value is in the first row of the {{ic|physical_offset}} column.


{{ic|''swap_device''}} is the volume where the swap file resides and it follows the same format as for the [[Persistent block device naming#Kernel parameters|root parameter]]. The value of {{ic|''swap_file_offset''}} can be obtained by running {{ic|filefrag -v ''swap_file''}}, the output is in a table format and the required value is located in the first row of the {{ic|physical_offset}} column. For example:
For example:


{{hc|# filefrag -v /swapfile|
{{hc|# filefrag -v /swapfile|
Line 114: Line 143:
File size of /swapfile is 4294967296 (1048576 blocks of 4096 bytes)
File size of /swapfile is 4294967296 (1048576 blocks of 4096 bytes)
  ext:    logical_offset:        physical_offset: length:  expected: flags:
  ext:    logical_offset:        physical_offset: length:  expected: flags:
   0:        0..      0:      '''38912'''..    38912:      1:          
   0:        0..      0:      '''38912'''..    38912:      1:
   1:        1..  22527:      38913..    61439:  22527:            unwritten
   1:        1..  22527:      38913..    61439:  22527:            unwritten
   2:    22528..  53247:    899072..    929791:  30720:      61440: unwritten
   2:    22528..  53247:    899072..    929791:  30720:      61440: unwritten
Line 120: Line 149:
}}
}}


In the example the value of {{ic|''swap_file_offset''}} is the first {{ic|38912}} with the two periods.
In the example the value of {{ic|1=resume_offset=}} is the first {{ic|38912}}.
 
Alternatively, to directly acquire the offset value:
 
# filefrag -v ''swap_file'' | awk '$1=="0:" {print substr($4, 1, length($4)-2)}'
 
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.[https://bugzilla.kernel.org/show_bug.cgi?id=202803] Instead, use the {{man|8|btrfs-inspect-internal}} command. E.g.:


{{Tip|
{{hc|# btrfs inspect-internal map-swapfile -r ''swap_file''|
* The following command may be used to identify {{ic|''swap_device_uuid''}}: {{ic|1=findmnt -no UUID -T /swapfile}}
198122980
* The following command may be used to identify {{ic|''swap_file_offset''}}: {{ic|1=filefrag -v /swapfile {{!}} awk '$1=="0:" {print substr($4, 1, length($4)-2)}'}}
* The value of {{ic|''swap_file_offset''}} can also be obtained by running {{ic|swap-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 {{ic|/etc/suspend.conf}} via the keys {{ic|resume device}} and {{ic|resume offset}}. No reboot is required in this case.
}}
}}


{{Note|
In this example, the kernel parameter would be {{ic|resume_offset{{=}}198122980}}.
* For a stacked block device such as an encrypted container (LUKS), RAID or LVM, the {{ic|resume}} parameter must point to the unlocked/mapped device that contains the file system with the swap file.
* If the swap file is in {{ic|/home/}}, ''systemd-logind'' will not be able to determine its size and thus will prevent hibernation with the following message: {{ic|Failed to hibernate system via logind: Not enough swap space for hibernation}}. See [https://github.com/systemd/systemd/issues/15354 systemd issue 15354] for two workarounds.
}}


{{Tip|You might want to decrease the [[swappiness]] for your swap file if the only purpose is to be able to hibernate and not expand RAM.}}
To apply the change immediately (without rebooting), echo the resume offset to {{ic|/sys/power/resume_offset}}. For example, if the offset is {{ic|38912}}:


==== Hibernation into swap file on Btrfs ====
# echo 38912 > /sys/power/resume_offset


The resume_offset number can be computed using the [https://github.com/osandov/osandov-linux/blob/master/scripts/btrfs_map_physical.c tool btrfs_map_physical.c].
{{Tip|The following command may be used to identify the backing device of the swap file: {{ic|1=findmnt -no UUID -T ''swap_file''}}}}
Do not try to use the filefrag tool, on [[Btrfs]] 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. [https://bugzilla.kernel.org/show_bug.cgi?id=202803]


Download or copy the [https://github.com/osandov/osandov-linux/blob/master/scripts/btrfs_map_physical.c tool btrfs_map_physical.c] into a file named {{ic|btrfs_map_physical.c}}, then compile it,
{{Note|For a stacked block device such as an encrypted container (LUKS), RAID or LVM, the {{ic|resume}} parameter must point to the unlocked/mapped device that contains the file system with the swap file.}}


$ gcc -O2 -o btrfs_map_physical btrfs_map_physical.c
==== Maintaining swap file for hibernation with zram ====


and run it. An example output is shown below.
{{Tip|Instead of the following setup which involves multiple swap spaces, [[Zswap]] can be used to establish a similar behavior.}}


{{hc|# ./btrfs_map_physical ''/path/to/swapfile''|
It is possible solving the hibernation problem with RAM compression (zram) by maintaining two or more swap spaces at the same time. [[systemd]] will always ignore zram block devices before triggering hibernation, therefore keeping both spaces enabled should work without further intervention.
FILE OFFSET  EXTENT TYPE  LOGICAL SIZE  LOGICAL OFFSET  PHYSICAL SIZE  DEVID  PHYSICAL OFFSET
0            regular      4096          2927632384      268435456      1      '''4009762816'''
4096        prealloc    268431360    2927636480      268431360      1      4009766912
268435456    prealloc    268435456    3251634176      268435456      1      4333764608
536870912    prealloc    268435456    3520069632      268435456      1      4602200064
805306368    prealloc    268435456    3788505088      268435456      1      4870635520
1073741824  prealloc    268435456    4056940544      268435456      1      5139070976
1342177280  prealloc    268435456    4325376000      268435456      1      5407506432
1610612736  prealloc    268435456    4593811456      268435456      1      5675941888
}}


Note the the first physical offset returned by this tool. In this example, we use {{ic|4009762816}}. Also note the pagesize that can be found with {{ic|getconf PAGESIZE}}.
After [[#Acquire swap file offset|configured the swap file]], follow the [[zram]] page. Make sure zram has the '''higher swap priority''' (e.g. {{ic|1=pri=100}}).


To compute the {{ic|resume_offset}} value, divide the physical offset by the pagesize. In this example, it is {{ic|1=4009762816 / 4096 = 978946}}.
{{Note|
* '''Do not''' create an on-demand swap unit for hibernation as it is not officially supported. See systemd issues [https://github.com/systemd/systemd/issues/16708 #16708] and [https://github.com/systemd/systemd/issues/30083 #30083].
* The kernel alone is responsible for reclaiming anonymous memory of pages and swapping them; not using a swap space can actually lead to bad memory usage. The user can manage priorities in reclaiming memory for certain applications in the form of {{ic|memory.low}}, tunable by [[control groups]]. Overall this is more effective than setting the [[swappiness]] parameter.
* Read the [https://www.kernel.org/doc/gorman/html/understand/understand014.html Swap Management in kernel documentation] and the [https://chrisdown.name/2018/01/02/in-defence-of-swap.html Chris Down's article - In defence of swap: common misconceptions] for more details.
}}


==== Hibernation into a thinly-provisioned LVM volume ====
==== Hibernation into a thinly-provisioned LVM volume ====
Line 173: Line 196:


{{hc|# lvs|
{{hc|# lvs|
LV                  VG  Attr      LSize  Pool Origin    Data%  Meta%  Move Log Cpy%Sync Convert
  LV                  VG  Attr      LSize  Pool Origin    Data%  Meta%  Move Log Cpy%Sync Convert
swap                vg0 Vwi-aot--- 10.00g  pool          100
  swap                vg0 Vwi-aot--- 10.00g  pool          100
}}
}}


Line 181: Line 204:
{{Warning|Do not to use [[TRIM]] on thinly-provisioned swap volumes that are used for hibernation, i.e. do not use {{ic|discard}} in {{ic|/etc/fstab}} and the {{ic|-d}}/{{ic|--discard}} option of ''swapon''. Otherwise the used space will be deallocated.}}
{{Warning|Do not to use [[TRIM]] on thinly-provisioned swap volumes that are used for hibernation, i.e. do not use {{ic|discard}} in {{ic|/etc/fstab}} and the {{ic|-d}}/{{ic|--discard}} option of ''swapon''. Otherwise the used space will be deallocated.}}


== Intel Rapid Start Technology (IRST) ==
== Sleep hooks ==
 
=== Custom systemd units ===
 
[[systemd]] starts {{ic|suspend.target}}, {{ic|hibernate.target}}, {{ic|hybrid-sleep.target}}, or {{ic|suspend-then-hibernate.target}} for each sleep state, respectively. All the aforementioned targets pull in {{ic|sleep.target}}. Any of the targets can be used to invoke [[systemd#Writing unit files|custom units]] before or after suspend/hibernate. Separate files should be created for user actions and root/system actions. Examples:
 
{{hc|/etc/systemd/system/user-suspend@.service|2=
[Unit]
Description=User suspend actions
Before=sleep.target
 
[Service]
User=%I
Type=forking
Environment=DISPLAY=:0
ExecStartPre= -/usr/bin/pkill -u %u unison ; /usr/local/bin/music.sh stop
ExecStart=/usr/bin/sflock
ExecStartPost=/usr/bin/sleep 1
 
[Install]
WantedBy=sleep.target
}}
 
{{hc|/etc/systemd/system/user-resume@.service|2=
[Unit]
Description=User resume actions
After=suspend.target
 
[Service]
User=%I
Type=simple
ExecStart=/usr/local/bin/ssh-connect.sh
 
[Install]
WantedBy=suspend.target
}}
 
Enable {{ic|user-suspend@''user''.service}} and/or {{ic|user-resume@''user''.service}} for the change to take effect.
 
{{Note|As screen lockers may return before the screen is "locked", the screen may flash on resuming from suspend. Adding a small delay via {{ic|1=ExecStartPost=/usr/bin/sleep 1}} helps prevent this.}}
 
For root/system actions:
 
{{hc|/etc/systemd/system/root-suspend.service|2=
[Unit]
Description=Local system suspend actions
Before=sleep.target
 
[Service]
Type=simple
ExecStart=-/usr/bin/pkill sshfs
 
[Install]
WantedBy=sleep.target
}}
 
{{hc|/etc/systemd/system/root-resume.service|2=
[Unit]
Description=Local system resume actions
After=suspend.target
 
[Service]
Type=simple
ExecStart=/usr/bin/systemctl restart mnt-media.automount
 
[Install]
WantedBy=suspend.target
}}
 
==== Combined sleep/resume unit ====
 
With the combined unit file, a single hook does all the work for different phases (sleep/resume) and for different targets.
 
Example and explanation:
 
{{hc|/etc/systemd/system/wicd-sleep.service|2=
[Unit]
Description=Wicd sleep hook
Before=sleep.target
StopWhenUnneeded=yes
 
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=-/usr/share/wicd/daemon/suspend.py
ExecStop=-/usr/share/wicd/daemon/autoconnect.py
 
[Install]
WantedBy=sleep.target
}}
 
* {{ic|1=RemainAfterExit=yes}}: After started, the service is considered active until it is explicitly stopped.
* {{ic|1=StopWhenUnneeded=yes}}: When active, the service will be stopped if no other active service requires it. In this specific example, it will be stopped after {{ic|sleep.target}} is stopped.
* Because {{ic|sleep.target}} has {{ic|1=StopWhenUnneeded=yes}}, the hook is guaranteed to start/stop properly for different tasks.
 
=== Hooks in /usr/lib/systemd/system-sleep ===
 
{{Note|This method is considered a hack by systemd according to {{man|8|systemd-sleep}}. ''systemd-sleep'' will run these hooks concurrently rather than one after another. For a more well-defined interface with support for ordering, see [[#Custom systemd units]].}}
 
''systemd-sleep'' runs all executables in {{ic|/usr/lib/systemd/system-sleep/}}, passing two arguments to each of them:
 
# Either {{ic|pre}} or {{ic|post}}, depending on whether the machine is going to sleep or waking up.
# {{ic|suspend}}, {{ic|hibernate}} or {{ic|hybrid-sleep}}, depending on which is being invoked.
 
The output of any custom script will be logged by ''systemd-suspend.service'', ''systemd-hibernate.service'' or ''systemd-hybrid-sleep.service''. You can see its output in ''systemd''<nowiki>'</nowiki>s [[journalctl]]:
 
# journalctl -b -u systemd-suspend.service
 
An example of a custom sleep script:
 
{{hc|/usr/lib/systemd/system-sleep/example.sh|
#!/bin/sh
case $1/$2 in
  pre/*)
    echo "Going to $2..."
    ;;
  post/*)
    echo "Waking up from $2..."
    ;;
esac
}}
 
Do not forget to make your script [[executable]].
 
== Tips and Tricks ==


Intel Rapid Start Technology is a firmware solution to hibernation that allows hibernating from sleep after a predefined interval or 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.
=== Disable sleep completely ===
 
When using a device as e.g a server, suspending might not be needed or it could even be undesired. Each sleep state can be disabled through {{man|5|systemd-sleep.conf}}:
 
{{hc|/etc/systemd/sleep.conf.d/disable-suspend.conf|2=
[Sleep]
AllowSuspend=no
AllowHibernation=no
AllowHybridSleep=no
AllowSuspendThenHibernate=no
}}
 
=== 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 "[https://mjg59.dreamwidth.org/26022.html a few seconds longer than resuming from S3 but is far faster than resuming from hibernation]".
With Intel Rapid Start Technology (IRST) enabled, resuming from a deep sleep takes "[https://mjg59.dreamwidth.org/26022.html 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 already have a preexisting 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.
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.


{{Warning|The Intel Rapid Start partition is not encrypted; "Intel recommends disabling Intel Rapid Start Technology if you are using software-based disk encryption".[https://www.intel.com/content/www/us/en/support/articles/000024080/technologies.html]}}
{{Warning|The Intel Rapid Start partition is not encrypted; "Intel recommends disabling Intel Rapid Start Technology if you are using software-based disk encryption".[https://www.intel.com/content/www/us/en/support/articles/000024080/technologies.html]}}


However, 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 [[Wikipedia:GUID Partition Table#Partition type GUIDs|GUID]] {{ic|D3BFE2DE-3DAF-11DF-BA40-E3A556D89593}} for a [[GPT]] partition or [[Wikipedia:Partition type|ID]] {{ic|0x84}} for an [[MBR]] partition. You may also need to enable support for IRST in your system's firmware settings.
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 [[Wikipedia:GUID Partition Table#Partition type GUIDs|GUID]] {{ic|D3BFE2DE-3DAF-11DF-BA40-E3A556D89593}} for a [[GPT]] partition or [[Wikipedia:Partition type|ID]] {{ic|0x84}} for an [[MBR]] partition. You may also need to enable support for IRST in your system's firmware settings.


{{Tip|The duration of time before IRST kicks in (after suspending) can be adjusted in the system's firmware settings.}}
{{Tip|The duration of time before IRST kicks in (after suspending) can be adjusted in the system's firmware settings.}}
Line 197: Line 358:
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.
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 Linux requires {{ic|1=CONFIG_INTEL_RST=y}} or if set to module, the intel-rst module loaded. Once loaded via {{ic|modprobe intel_rst}}, it should create files wakeup_events and wakeup_time under for e.g. {{ic|/sys/bus/acpi/drivers/intel_rapid_start/*/wakeup_events}} that can be used for further configuration. This module is tersely documented, see the source [https://github.com/torvalds/linux/blob/143a6252e1b8ab424b4b293512a97cca7295c182/drivers/platform/x86/intel/rst.c drivers/platform/x86/intel/rst.c] for more details.
Configuring IRST hibernation events in the Linux kernel requires {{ic|CONFIG_INTEL_RST}} built-in or as a module. Once loaded via {{ic|modprobe intel_rst}}, it should create the files {{ic|wakeup_events}} and {{ic|wakeup_time}} under {{ic|/sys/bus/acpi/drivers/intel_rapid_start/*/}} that can be used for further configuration. This module is tersely documented, see the source [https://github.com/torvalds/linux/blob/143a6252e1b8ab424b4b293512a97cca7295c182/drivers/platform/x86/intel/rst.c drivers/platform/x86/intel/rst.c] for more details.


See also the [https://www.intel.com/content/www/us/en/support/articles/000024078/technologies.html general Q&A] and [https://www.intel.com/content/www/us/en/support/articles/000005836/boards-and-kits/desktop-boards.html user guides] for Intel Rapid Start Technology.
See also the [https://www.intel.com/content/www/us/en/support/articles/000024078/technologies.html general Q&A] and [https://www.intel.com/content/www/us/en/support/articles/000024273/technologies/intel-vpro-platform.html?wapkw=user%20guide%20Intel%20rapid%20start%20 user guides] for Intel Rapid Start Technology.


== Troubleshooting ==
== Troubleshooting ==
Line 208: Line 369:


=== Suspend/hibernate does not work, or does not work consistently ===
=== Suspend/hibernate does not work, or does not work consistently ===
{{Accuracy|This section mixes several unrelated causes.}}


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.
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.


Also problem may arise when using hardware watchdog timer (disabled by default, see {{ic|1=RuntimeWatchdogSec=}} in {{man|5|systemd-system.conf|OPTIONS}}). Bugged watchdog timer may reset the computer before the system finished creating the hibernation image.
A problem may arise when using the hardware watchdog timer (disabled by default, see {{ic|1=RuntimeWatchdogSec=}} in {{man|5|systemd-system.conf|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]] and rebuilding the initramfs, can possibly solve this issue, specially graphics drivers for [[Kernel mode setting#Early KMS start|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 [https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues best practices to debug suspend issues].


Moving from the [[radeon]] video driver to the newer [[AMDGPU]] driver could also help to make the hibernation and awakening process successful.
Sometimes the screen goes black due to device initialization from within the initramfs. Removing any modules you might have in [[Mkinitcpio#MODULES]], removing the {{ic|kms}} hook and rebuilding the initramfs can possibly solve this issue, in particular with graphics drivers for [[Kernel mode setting#Early KMS start|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 [https://web.archive.org/web/20230502010825/https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues best practices to debug suspend 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.
Moving from the [[ATI]] video driver to the newer [[AMDGPU]] driver could also help to make the hibernation and awakening process successful.


After upgrading to kernel 4.15.3, resume may fail with a static (non-blinking) cursor on a black screen. [[Blacklisting]] the module {{ic|nvidiafb}} might help. [https://bbs.archlinux.org/viewtopic.php?id=234646]
For [[NVIDIA]] users, [[blacklisting]] the module {{ic|nvidiafb}} might help. [https://bbs.archlinux.org/viewtopic.php?id=234646]


Laptops with Intel CPU that load {{ic|intel_lpss_pci}} module for touchpad, may face kernel panic on resume (blinking caps lock) [https://bbs.archlinux.org/viewtopic.php?id=231881]. The module needs to be added to [[initramfs]] as:
Laptops with an Intel CPU that load the {{ic|intel_lpss_pci}} module for a touchpad may face kernel panic on resume (blinking caps lock) [https://bbs.archlinux.org/viewtopic.php?id=231881]. The module needs to be added to [[initramfs]] as:


{{hc|head=/etc/mkinitcpio.conf|output=
{{hc|/etc/mkinitcpio.conf|2=
MODULES=(... intel_lpss_pci ...)
MODULES=(... intel_lpss_pci ...)
}}
}}
Line 236: Line 397:


See [[Wakeup triggers#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 [https://gitlab.freedesktop.org/drm/amd/-/issues/2357 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 {{ic|i2c-ELAN0679:00}} or {{ic|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:
{{hc|/etc/udev/rules.d/99-avoid-i2c-wakeup.rules|2=KERNEL=="''device_name''", SUBSYSTEM=="i2c", ATTR{power/wakeup}="disabled"}}


=== System does not power off when hibernating ===
=== System does not power off when hibernating ===
Line 246: Line 420:
}}
}}


With the above configuration, if everything else is set up correctly, on invocation of a {{ic|systemctl hibernate}} the machine will shutdown saving state to disk as it does so.
With the above configuration, if everything else is set up correctly, on invocation of a {{ic|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 ===
=== Operating system not found (or wrong OS booting) when booting after hibernation ===
Line 253: Line 427:


Set {{ic|1=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.
Set {{ic|1=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.
=== Swap file in /home ===
If the swap file is in {{ic|/home/}}, ''systemd-logind'' will not be able to access it, giving the {{ic|Call to Hibernate failed: No such file or directory}} warning message and resulting in a need for authentication on {{ic|systemctl hibernate}}. This setup should be avoided, as it is considered [https://github.com/systemd/systemd/issues/31100 unsupported upstream]. See [https://github.com/systemd/systemd/issues/15354#issuecomment-611077881 systemd issue 15354] for two workarounds.
=== PC will not wake from sleep on A520I and B550I motherboards ===
On some motherboards with A520i and B550i chipsets, the system will not completely enter the sleep state or come out of it. Symptoms include the system entering sleep and the monitor turning off while internal LEDs on the motherboard or the power LED stay on. Subsequently, the system will not come back from this state and require a hard power off. If you have similar issues with AMD, first make sure your system is fully updated and check whether the AMD [[microcode]] package is installed.
Verify the line starting with {{ic|GPP0}} has the enabled status:
{{hc|$ cat /proc/acpi/wakeup|
Device S-state   Status  Sysfs node
GP12   S4 *enabled  pci:0000:00:07.1
GP13   S4 *enabled  pci:0000:00:08.1
XHC0   S4 *enabled  pci:0000:0b:00.3
GP30   S4 *disabled
GP31   S4 *disabled
PS2K   S3 *disabled
'''GPP0'''   S4 '''*enabled'''  pci:0000:00:01.1
GPP8   S4 *enabled  pci:0000:00:03.1
PTXH   S4 *enabled  pci:0000:05:00.0
PT20   S4 *disabled
PT24   S4 *disabled
PT26   S4 *disabled
PT27   S4 *disabled
PT28   S4 *enabled  pci:0000:06:08.0
PT29   S4 *enabled  pci:0000:06:09.0
}}
If that is enabled, you can run the following command:
# echo GPP0 > /proc/acpi/wakeup
Now test by running {{ic|systemctl suspend}} and let the system go to sleep. Then try to wake the system after a few seconds. If it works, you can make the workaround permanent. [[Create]] a systemd [[Systemd#Writing unit files|unit file]]:
{{hc|/etc/systemd/system/toggle-gpp0-to-fix-wakeup.service|2=
[Unit]
Description="Disable GPP0 to fix suspend issue"
[Service]
ExecStart=/bin/sh -c "/bin/echo GPP0 > /proc/acpi/wakeup"
[Install]
WantedBy=multi-user.target
}}
Do a [[daemon-reload]] and [[start/enable]] the newly created unit.
Alternatively, you can create a [[udev]] rule. Assuming {{ic|GPP0}}’s sysfs node is {{ic|pci:0000:00:01.1}} like in the example, run {{ic|udevadm info -a -p /sys/bus/pci/devices/0000\:00\:01.1}} to get the relevant information and create a udev rule like this one:
{{hc|/etc/udev/rules.d/10-gpp0-acpi-fix.rules|2=
KERNEL=="0000:00:01.1", SUBSYSTEM=="pci", DRIVERS=="pcieport", ATTR{vendor}=="0x1022", ATTR{device}=="0x1483", ATTR{power/wakeup}="disabled"
}}
The udev daemon is already watching for changes in your system by default. If needed you can [[udev#Loading new rules|reload the rules manually]].
=== Suspend from corresponding laptop Fn key not working ===
If, regardless of the setting in logind.conf, the sleep button does not work (pressing it does not even produce a message in syslog), then logind is probably not watching the keyboard device. [https://lists.freedesktop.org/archives/systemd-devel/2015-February/028325.html] Do:
# journalctl --grep="Watching system buttons"
You might see something like this:
May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event2 (Power Button)
May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event3 (Sleep Button)
May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event4 (Video Bus)
Notice no keyboard device. List keyboard devices as follows:
{{hc|$ stat -c%N /dev/input/by-id/*-kbd|2=
...
/dev/input/by-id/usb-SIGMACHIP_USB_Keyboard-event-kbd -> '''../event6'''
...
}}
Now obtain {{ic|ATTRS{name}<nowiki/>}} for the parent keyboard device [https://systemd-devel.freedesktop.narkive.com/Rbi3rjNN/patch-1-2-logind-add-support-for-tps65217-power-button]. As an example, on the above list this keyboard device has {{ic|'''event6'''}} as device input event, it can be used to search its respective attribute name:
{{hc|# udevadm info -a /dev/input/'''event6'''|2=
...
KERNEL=="event6"
...
ATTRS{name}=="SIGMACHIP USB Keyboard"
}}
Now write a custom udev rule to add the "power-switch" tag:
{{hc|/etc/udev/rules.d/70-power-switch-my.rules|2=
ACTION=="remove", GOTO="power_switch_my_end"
SUBSYSTEM=="input", KERNEL=="event*", ATTRS{name}=="SIGMACHIP USB Keyboard", TAG+="power-switch"
LABEL="power_switch_my_end"
}}
After [[Udev#Loading new rules|reloading the udev rules]] and [[Restart|restarting]] {{ic|systemd-logind.service}}, you should see {{ic|Watching system buttons on /dev/input/event6}} in the journal of ''logind''.

Latest revision as of 08:23, 18 March 2024

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.
Tip: While this state is subject to battery drain issues on Windows or macOS since they support waking devices in this state for network activity, the Linux software ecosystem does not currently make use of this feature and should be unaffected.
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.

The kernel provides basic functionality, and some high level interfaces provide tweaks to handle problematic hardware drivers/kernel modules (e.g. video card re-initialization).

Kernel interface (swsusp)

Note: Although the kernel interface can be used directly, which is faster since no extra userspace handling is performed, it is advisable to use the high level interface. It does a better job by performing additional safety checks, as well as providing pre- and post-suspend hook mechanisms in order to properly set the hardware clock, restore wireless, etc.

It is possible 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.

High level interface (systemd)

Note: The goal of the high level interface is to provide binaries/scripts that can be invoked to perform suspend/hibernate and ways to hook extra preparatory/cleanup work into the said process. For automatically enter sleep state on power buttons, menu clicks, or laptop lid events, refer to Power management#ACPI events.

systemd provides native commands for suspend, hibernate and a hybrid suspend. This is the default interface used in Arch Linux.

systemctl suspend should work out of the box. For systemctl hibernate to work on your system you might need to follow the instructions at #Hibernation.

There are also two modes combining suspend and hibernate:

  • systemctl hybrid-sleep suspends the system both to RAM and disk, so a complete power loss does not result in lost data. This mode is also called suspend to both.
  • systemctl suspend-then-hibernate initially suspends the system to RAM as long as possible, then wakes it with an RTC alarm and hibernates. The RTC alarm is set with HibernateDelaySec in systemd-sleep.conf(5). The default value is set by estimating the battery discharge rate to keep the system with 5% of battery, or two hours without one. Said estimation is obtained from the change in battery level after the time specified by SuspendEstimationSec in systemd-sleep.conf(5), at which the system will briefly wake up to do the measurement (a measure is also made if the system is manually woken up from suspension).

See #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.

Tip: S0ix is supposed to provide identical or better energy savings as S3 sleep. See Intel blog posts How to achieve S0ix states in Linux, Linux S0ix Troubleshooting and Idling Efficiently on Linux: A Case Study to check if you can make it work as intended. Users on Intel systems can use S0ixSelftestTool.

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).

Note: This last solution is likely going to cause issues. Manufacturers have stopped fixing bugs with the ACPI S3 state since systems shipping with Windows are encouraged to use "Modern standby" by default; if they have voluntarily not advertised it, it is probably broken in some way.

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, configure the initramfs so that the resume process will be initiated in early userspace, and specify the location of the swap space in a way that is available to the initramfs, e.g. HibernateLocation EFI variable defined by systemd or resume= kernel parameter. These three steps are described in detail below.

Note:

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.[2]

Configure the initramfs

  • When using a busybox-based initramfs, which is the default, the resume hook 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 resume hook must go after the udev hook. This example was made starting from the default hook configuration:
HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block filesystems resume fsck)
Remember to regenerate the initramfs for these changes to take effect.
Note: If stacked storage is used for the swap space, e.g. dm-crypt, RAID or LVM, the final mapped device must be available in the early userspace and before the resume process is initiated. I.e. the resume hook must be placed after hooks like encrypt, lvm2, etc. in such setups.
  • When an initramfs with the systemd hook is used, a resume mechanism is already provided, and no further hooks need to be added.

Pass hibernate location to initramfs

When the system hibernates, the memory image is dumped to the swap space, which also includes the state of mounted file systems. Therefore, the hibernate location must be made available to the initramfs, i.e. before the root file system is mounted for resuming from hibernate to work.

Since systemd v255 and mkinitcpio v38, when the system is running on UEFI, systemd-sleep(8) will automatically pick a suitable swap space to hibernate into, and the information of the used swap space is stored in HibernateLocation EFI variable. Upon next boot, systemd-hibernate-resume(8) reads the location off the EFI variable and the system resumes. This means the following steps are not necessary unless the system is using legacy BIOS or you want to choose a different swap space from the automatically-selected one.

Manually specify hibernate location

The kernel parameter resume=swap_device can be used, where swap_device follows the persistent block device naming. For example:

  • resume=UUID=4209c845-f495-4c43-8a03-5363dd433153
  • resume="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.

For example, if the swap device is 8:3:

# echo 8:3 > /sys/power/resume

If using a swap file, additionally follow the procedures in #Acquire swap file offset.

Acquire swap file offset

When using a swap file for hibernation, the block device on which the file system lies should be specified in resume=, and additionally the physical offset of swap file must be specified through resume_offset= kernel parameter. [3]

On file systems other than Btrfs, the value of resume_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 resume_offset= is the first 38912.

Alternatively, to directly acquire the offset value:

# filefrag -v swap_file | awk '$1=="0:" {print substr($4, 1, length($4)-2)}'

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.[4] Instead, use the btrfs-inspect-internal(8) command. E.g.:

# btrfs inspect-internal map-swapfile -r swap_file
198122980

In this example, the kernel parameter would be resume_offset=198122980.

To apply the change immediately (without rebooting), echo the resume offset to /sys/power/resume_offset. For example, if the offset is 38912:

# echo 38912 > /sys/power/resume_offset
Tip: The following command may be used to identify the backing device of the swap file: findmnt -no UUID -T swap_file
Note: For a stacked block device such as an encrypted container (LUKS), RAID or LVM, the resume parameter must point to the unlocked/mapped device that contains the file system with the swap file.

Maintaining swap file for hibernation with zram

Tip: Instead of the following setup which involves multiple swap spaces, Zswap can be used to establish a similar behavior.

It is possible solving the hibernation problem with RAM compression (zram) by maintaining two or more swap spaces at the same time. systemd will always ignore zram block devices before triggering hibernation, therefore keeping both spaces enabled should work without further intervention.

After configured the swap file, follow the zram page. Make sure zram has the higher swap priority (e.g. pri=100).

Note:

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.

Warning: Do not to use TRIM on thinly-provisioned swap volumes that are used for hibernation, i.e. do not use discard in /etc/fstab and the -d/--discard option of swapon. Otherwise the used space will be deallocated.

Sleep hooks

Custom systemd units

systemd starts suspend.target, hibernate.target, hybrid-sleep.target, or suspend-then-hibernate.target for each sleep state, respectively. All the aforementioned targets pull in sleep.target. Any of the targets can be used to invoke custom units before or after suspend/hibernate. Separate files should be created for user actions and root/system actions. Examples:

/etc/systemd/system/user-suspend@.service
[Unit]
Description=User suspend actions
Before=sleep.target

[Service]
User=%I
Type=forking
Environment=DISPLAY=:0
ExecStartPre= -/usr/bin/pkill -u %u unison ; /usr/local/bin/music.sh stop
ExecStart=/usr/bin/sflock
ExecStartPost=/usr/bin/sleep 1

[Install]
WantedBy=sleep.target
/etc/systemd/system/user-resume@.service
[Unit]
Description=User resume actions
After=suspend.target

[Service]
User=%I
Type=simple
ExecStart=/usr/local/bin/ssh-connect.sh

[Install]
WantedBy=suspend.target

Enable user-suspend@user.service and/or user-resume@user.service for the change to take effect.

Note: As screen lockers may return before the screen is "locked", the screen may flash on resuming from suspend. Adding a small delay via ExecStartPost=/usr/bin/sleep 1 helps prevent this.

For root/system actions:

/etc/systemd/system/root-suspend.service
[Unit]
Description=Local system suspend actions
Before=sleep.target

[Service]
Type=simple
ExecStart=-/usr/bin/pkill sshfs

[Install]
WantedBy=sleep.target
/etc/systemd/system/root-resume.service
[Unit]
Description=Local system resume actions
After=suspend.target

[Service]
Type=simple
ExecStart=/usr/bin/systemctl restart mnt-media.automount

[Install]
WantedBy=suspend.target

Combined sleep/resume unit

With the combined unit file, a single hook does all the work for different phases (sleep/resume) and for different targets.

Example and explanation:

/etc/systemd/system/wicd-sleep.service
[Unit]
Description=Wicd sleep hook
Before=sleep.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=-/usr/share/wicd/daemon/suspend.py
ExecStop=-/usr/share/wicd/daemon/autoconnect.py

[Install]
WantedBy=sleep.target
  • RemainAfterExit=yes: After started, the service is considered active until it is explicitly stopped.
  • StopWhenUnneeded=yes: When active, the service will be stopped if no other active service requires it. In this specific example, it will be stopped after sleep.target is stopped.
  • Because sleep.target has StopWhenUnneeded=yes, the hook is guaranteed to start/stop properly for different tasks.

Hooks in /usr/lib/systemd/system-sleep

Note: This method is considered a hack by systemd according to systemd-sleep(8). systemd-sleep will run these hooks concurrently rather than one after another. For a more well-defined interface with support for ordering, see #Custom systemd units.

systemd-sleep runs all executables in /usr/lib/systemd/system-sleep/, passing two arguments to each of them:

  1. Either pre or post, depending on whether the machine is going to sleep or waking up.
  2. suspend, hibernate or hybrid-sleep, depending on which is being invoked.

The output of any custom script will be logged by systemd-suspend.service, systemd-hibernate.service or systemd-hybrid-sleep.service. You can see its output in systemd's journalctl:

# journalctl -b -u systemd-suspend.service

An example of a custom sleep script:

/usr/lib/systemd/system-sleep/example.sh
#!/bin/sh
case $1/$2 in
  pre/*)
    echo "Going to $2..."
    ;;
  post/*)
    echo "Waking up from $2..."
    ;;
esac

Do not forget to make your script executable.

Tips and Tricks

Disable sleep completely

When using a device as e.g a server, suspending might not be needed or it could even be undesired. Each sleep state can be disabled through systemd-sleep.conf(5):

/etc/systemd/sleep.conf.d/disable-suspend.conf
[Sleep]
AllowSuspend=no
AllowHibernation=no
AllowHybridSleep=no
AllowSuspendThenHibernate=no

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.

Warning: The Intel Rapid Start partition is not encrypted; "Intel recommends disabling Intel Rapid Start Technology if you are using software-based disk encryption".[5]

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.

Tip: The duration of time before IRST kicks in (after suspending) can be adjusted in the 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

The factual accuracy of this article or section is disputed.

Reason: This section mixes several unrelated causes. (Discuss in Talk:Power management/Suspend and hibernate)

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. [6]

Laptops with an Intel CPU that load the intel_lpss_pci module for a touchpad may face kernel panic on resume (blinking caps lock) [7]. 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.

Swap file in /home

If the swap file is in /home/, systemd-logind will not be able to access it, giving the Call to Hibernate failed: No such file or directory warning message and resulting in a need for authentication on systemctl hibernate. This setup should be avoided, as it is considered unsupported upstream. See systemd issue 15354 for two workarounds.

PC will not wake from sleep on A520I and B550I motherboards

On some motherboards with A520i and B550i chipsets, the system will not completely enter the sleep state or come out of it. Symptoms include the system entering sleep and the monitor turning off while internal LEDs on the motherboard or the power LED stay on. Subsequently, the system will not come back from this state and require a hard power off. If you have similar issues with AMD, first make sure your system is fully updated and check whether the AMD microcode package is installed.

Verify the line starting with GPP0 has the enabled status:

$ cat /proc/acpi/wakeup
Device	S-state	  Status   Sysfs node
GP12	  S4	*enabled   pci:0000:00:07.1
GP13	  S4	*enabled   pci:0000:00:08.1
XHC0	  S4	*enabled   pci:0000:0b:00.3
GP30	  S4	*disabled
GP31	  S4	*disabled
PS2K	  S3	*disabled
GPP0	  S4	*enabled   pci:0000:00:01.1
GPP8	  S4	*enabled   pci:0000:00:03.1
PTXH	  S4	*enabled   pci:0000:05:00.0
PT20	  S4	*disabled
PT24	  S4	*disabled
PT26	  S4	*disabled
PT27	  S4	*disabled
PT28	  S4	*enabled   pci:0000:06:08.0
PT29	  S4	*enabled   pci:0000:06:09.0

If that is enabled, you can run the following command:

# echo GPP0 > /proc/acpi/wakeup

Now test by running systemctl suspend and let the system go to sleep. Then try to wake the system after a few seconds. If it works, you can make the workaround permanent. Create a systemd unit file:

/etc/systemd/system/toggle-gpp0-to-fix-wakeup.service
[Unit]
Description="Disable GPP0 to fix suspend issue"

[Service]
ExecStart=/bin/sh -c "/bin/echo GPP0 > /proc/acpi/wakeup"

[Install]
WantedBy=multi-user.target

Do a daemon-reload and start/enable the newly created unit.

Alternatively, you can create a udev rule. Assuming GPP0’s sysfs node is pci:0000:00:01.1 like in the example, run udevadm info -a -p /sys/bus/pci/devices/0000\:00\:01.1 to get the relevant information and create a udev rule like this one:

/etc/udev/rules.d/10-gpp0-acpi-fix.rules
KERNEL=="0000:00:01.1", SUBSYSTEM=="pci", DRIVERS=="pcieport", ATTR{vendor}=="0x1022", ATTR{device}=="0x1483", ATTR{power/wakeup}="disabled"

The udev daemon is already watching for changes in your system by default. If needed you can reload the rules manually.

Suspend from corresponding laptop Fn key not working

If, regardless of the setting in logind.conf, the sleep button does not work (pressing it does not even produce a message in syslog), then logind is probably not watching the keyboard device. [8] Do:

# journalctl --grep="Watching system buttons"

You might see something like this:

May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event2 (Power Button)
May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event3 (Sleep Button)
May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event4 (Video Bus)

Notice no keyboard device. List keyboard devices as follows:

$ stat -c%N /dev/input/by-id/*-kbd
...
/dev/input/by-id/usb-SIGMACHIP_USB_Keyboard-event-kbd -> ../event6
...

Now obtain ATTRS{name} for the parent keyboard device [9]. As an example, on the above list this keyboard device has event6 as device input event, it can be used to search its respective attribute name:

# udevadm info -a /dev/input/event6
...
KERNEL=="event6"
...
ATTRS{name}=="SIGMACHIP USB Keyboard"

Now write a custom udev rule to add the "power-switch" tag:

/etc/udev/rules.d/70-power-switch-my.rules
ACTION=="remove", GOTO="power_switch_my_end"
SUBSYSTEM=="input", KERNEL=="event*", ATTRS{name}=="SIGMACHIP USB Keyboard", TAG+="power-switch"
LABEL="power_switch_my_end"

After reloading the udev rules and restarting systemd-logind.service, you should see Watching system buttons on /dev/input/event6 in the journal of logind.