Power Management: Difference between revisions
imported>Lelgenio Add workaround for systems that immediatly wakeup after beign suspended |
imported>Skylark Drop a redlink, add See also: Laptop which overlaps with this article |
||
| Line 13: | Line 13: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
It is also possible | It is also possible to use the <code>post-resume</code> target directly to make a service. | ||
<syntaxhighlight lang="nix"> | <syntaxhighlight lang="nix"> | ||
| Line 30: | Line 29: | ||
=== Troubleshooting === | === Troubleshooting === | ||
==== System | ==== System immediately wakes up from suspend ==== | ||
Particularly in some | Particularly in some Gigabyte motherboards with NVMe drives, the system may immediately wake up from being suspended. | ||
This can be worked around by disabling the wakeup triggers for the offending components: | This can be worked around by disabling the wakeup triggers for the offending components: | ||
===== Solution 1: Disabling wakeup triggers for all PCIe devices ===== | ===== Solution 1: Disabling wakeup triggers for all PCIe devices ===== | ||
If you don't need your system to wakeup via PCIe components you can simply disable it for all without needing to | If you don't need your system to wakeup via PCIe components you can simply disable it for all without needing to determine which component is causing problems. | ||
<syntaxhighlight lang="nix"> | <syntaxhighlight lang="nix"> | ||
| Line 45: | Line 44: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
===== Solution 2: | ===== Solution 2: Disable a common NVMe interface ===== | ||
Specifically on Gigabyte motherboards you can try targetting only the NVMe ports. | Specifically on Gigabyte motherboards you can try targetting only the NVMe ports. | ||
| Line 55: | Line 54: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
===== Solution 3: | ===== Solution 3: Disable a single device's wakeup triggers ===== | ||
If you wish to be more granular in what components should no longer be able to wakeup your system you can | If you wish to be more granular in what components should no longer be able to wakeup your system, you can find out which component is causing the wakeup events. | ||
First, list all components and their current wakeup status: | First, list all components and their current wakeup status: | ||
| Line 72: | Line 71: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
You can temporarily toggle a device by | You can temporarily toggle a device by writing its "Device" name back into <code>/proc/acpi/wakeup</code> | ||
<syntaxhighlight lang="sh"> | <syntaxhighlight lang="sh"> | ||
| Line 87: | Line 86: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
And finally use those values in a udev rule: | And finally use those values in a <code>udev</code> rule: | ||
<syntaxhighlight lang="nix"> | <syntaxhighlight lang="nix"> | ||
| Line 94: | Line 93: | ||
''; | ''; | ||
</syntaxhighlight> | </syntaxhighlight> | ||
== See also == | |||
* [[Laptop]] | |||
== External resources == | == External resources == | ||
* {{manual:nixos|sec=#sec-rebooting|chapter=Chapter 23. Rebooting and Shutting Down}} | * {{manual:nixos|sec=#sec-rebooting|chapter=Chapter 23. Rebooting and Shutting Down}} | ||
Revision as of 13:26, 20 October 2023
 |
This article or section needs expansion.
Reason: This article is a stub. (Discuss in Talk:Power Management#)
Please consult the pedia article metapage for guidelines on contributing. |
Suspend
Suspend hooks
NixOS provides the powerManagement.resumeCommands option which defines commands that are added to a global script that will be executed after resuming.
powerManagement.resumeCommands = ''
echo "This should show up in the journal after resuming."
'';
It is also possible to use the post-resume target directly to make a service.
systemd.services.your-service-name = {
description = "Service description here";
wantedBy = [ "post-resume.target" ];
after = [ "post-resume.target" ];
script = ''
echo "This should show up in the journal after resuming."
'';
serviceConfig.Type = "oneshot";
};
Troubleshooting
System immediately wakes up from suspend
Particularly in some Gigabyte motherboards with NVMe drives, the system may immediately wake up from being suspended. This can be worked around by disabling the wakeup triggers for the offending components:
Solution 1: Disabling wakeup triggers for all PCIe devices
If you don't need your system to wakeup via PCIe components you can simply disable it for all without needing to determine which component is causing problems.
services.udev.extraRules = ''
ACTION=="add", SUBSYSTEM=="pci", DRIVER=="pcieport", ATTR{power/wakeup}="disabled"
'';
Solution 2: Disable a common NVMe interface
Specifically on Gigabyte motherboards you can try targetting only the NVMe ports.
services.udev.extraRules = ''
ACTION=="add" SUBSYSTEM=="pci" ATTR{vendor}=="0x1022" ATTR{device}=="0x1483" ATTR{power/wakeup}="disabled"
'';
Solution 3: Disable a single device's wakeup triggers
If you wish to be more granular in what components should no longer be able to wakeup your system, you can find out which component is causing the wakeup events.
First, list all components and their current wakeup status:
$ cat /proc/acpi/wakeup
Device S-state Status Sysfs node
GP12 S4 *enabled pci:0000:00:07.1
GP13 S4 *disabled pci:0000:00:08.1
XHC0 S4 *enabled pci:0000:0a:00.3
GP30 S4 *disabled
....
PT27 S4 *disabled
PT28 S4 *disabled
PT29 S4 *disabled pci:0000:03:09.0
You can temporarily toggle a device by writing its "Device" name back into /proc/acpi/wakeup
echo GPP0 | sudo tee /proc/acpi/wakeup
After finding out which component is causing unwanted wakeups you can use the sysfs id to find out the "vendor" and "device" fields:
$ cat /sys/class/pci_bus/0000:04/device/0000:04:00.0/vendor
0x1987
$ cat /sys/class/pci_bus/0000:04/device/0000:04:00.0/device
0x5013
And finally use those values in a udev rule:
services.udev.extraRules = ''
ACTION=="add" SUBSYSTEM=="pci" ATTR{vendor}=="0x1987" ATTR{device}=="0x5013" ATTR{power/wakeup}="disabled"
'';