# Power Management References - Special Files
[TOC]
## References
1. [Symbols under /sys/power](https://docs.kernel.org/admin-guide/abi-testing.html#symbols-under-sys-power) of Linux ABI documentation.
2. [File testing/sysfs-devices-power](https://docs.kernel.org/admin-guide/abi-testing.html#abi-file-testing-sysfs-devices-power) for device power management ABIs.
3. Under debugfs (usually mounted under `/sys/kernel/debug/`) also contains some files. Note that debugfs is not a part of Linux ABI and may subject to change. Documentation is relatively sparse.
## Useful files
### `/sys/power/pm_debug_messages`: enable debugging message in kernel log
Use the following to enable extra debugging message in the `dmesg`:
```=
$ sudo sh -c 'echo 1 > /sys/power/pm_debug_messages'
```
If the machine is send into suspension, you'll see the log starting with `PM` indicating the steps for suspension. In this case, it is the `s2idle`:
```
[ 2426.895635] PM: suspend entry (s2idle)
[ 2426.902296] Filesystems sync: 0.006 seconds
[ 2426.904284] Freezing user space processes
[ 2426.907261] Freezing user space processes completed (elapsed 0.002 seconds)
[ 2426.907263] OOM killer disabled.
[ 2426.907263] Freezing remaining freezable tasks
[ 2426.908255] Freezing remaining freezable tasks completed (elapsed 0.000 seconds)
[ 2426.908256] printk: Suspending console(s) (use no_console_suspend to debug)
[ 2427.460539] nvme-apple 27bcc0000.nvme: RTKit: syslog message: cmd.c:8123: NVMe shutdown start seg->lba: 0, seg->size: 0
[ 2428.406433] nvme-apple 27bcc0000.nvme: RTKit: syslog message: cmd.c:8151: seg->lba 0 saveCtx 1 took 945 ms - clog 985629
[ 2428.460658] PM: suspend of devices complete after 1552.305 msecs
[ 2428.460671] PM: start suspend of devices complete after 1552.399 msecs
[ 2428.460676] PM: suspend devices took 1.552 seconds
[ 2428.461569] PM: late suspend of devices complete after 0.888 msecs
[ 2428.474528] PM: noirq suspend of devices complete after 12.886 msecs
[ 2428.474534] PM: suspend-to-idle
```
And if it is resumed (for example, if I open the lid), then it'll show the resume steps as well:
```
[ 2428.474697] macsmc-hid macsmc-hid: Lid wakeup
[ 2428.474724] PM: resume from suspend-to-idle
[ 2428.487450] PM: noirq resume of devices complete after 12.722 msecs
[ 2428.487974] PM: early resume of devices complete after 0.401 msecs
[ 2428.488742] nvme-apple 27bcc0000.nvme: RTKit: Initializing (protocol version 12)
[ 2428.488793] nvme-apple 27bcc0000.nvme: RTKit: Unknown system endpoint: 0x0a
[ 2428.518728] nvme-apple 27bcc0000.nvme: RTKit: syslog message: pre_nand_eng.c:6162: enabled 1p0v 1, enabled prog-no-exec 1
[ 2428.518735] nvme-apple 27bcc0000.nvme: RTKit: syslog message: pre_nand_eng.c:6162: enabled 1p0v 1, enabled prog-no-exec 1
[ 2428.522091] nvme-apple 27bcc0000.nvme: RTKit: syslog message: cmd.c:6416: boot mode normal
[ 2428.532284] PM: resume of devices complete after 44.304 msecs
[ 2428.532633] PM: resume devices took 0.045 seconds
[ 2428.532738] OOM killer enabled.
[ 2428.532741] Restarting tasks ... done.
[ 2428.536390] random: crng reseeded on system resumption
[ 2428.536591] PM: suspend exit
```
### `/sys/kernel/debug/suspend_stats`: statistics for stagex of suspension
Linux divided system-wide suspension into different stages:
1. The suspend path are divided into `suspend`-`suspend_late`-`suspend_noirq`. Different type of suspensions (or rather "depth" of the suspension), e.g. s2idle vs. s2ram, it may further perform different actions after the `suspend_noirq`.
2. Likewise, the resume path are divided into `resume_noirq` - `resume-early` - `resume`. Depending on the way the system enter suspension, extra steps may be needed before `noirq` stage.
The `/sys/kernel/debug/suspend_stats` include counter for successful suspensions. For failure ones, in addition to the count, it also shows failure count on each stages. For example:
```=
$ cat /sys/kernel/debug/suspend_stats
```
You'll see statistics about successful suspensions, as well as failed ones:
```
success: 1
fail: 0
failed_freeze: 0
failed_prepare: 0
failed_suspend: 0
failed_suspend_late: 0
failed_suspend_noirq: 0
failed_resume: 0
failed_resume_early: 0
failed_resume_noirq: 0
failures:
last_failed_dev:
last_failed_errno: 0
0
last_failed_step:
```
### `/sys/devices/.../power/wakeup`: whether a device serves as wakeup source
The [`/sys/devices/.../power/wakeup`](https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-devices-power-wakeup) file for a device can be used for setting device as wakeup source for system suspend.
### `/sys/kernel/debug/wakeup_sources`: list of wakeup sources
The `/sys/kernel/debug/wakeup_sources` lists all such devices:
```=
$ cat /sys/kernel/debug/wakeup_sources
```
Will see the following output:
```
name active_count event_count wakeup_count expire_count active_since total_time max_time last_change prevent_suspend_time
0000:01:00.0 0 0 0 0 0 0 00 0
macsmc-hid 1 1 0 0 0 0 02428366 0
tps6598x-source-psy-0-003f 1 1 0 0 0 00 2877 0
tps6598x-source-psy-0-0038 1 1 0 0 0 00 2872 0
tps6598x-source-psy-0-003a 1 1 0 0 0 00 1467 0
macsmc-ac 1 1 0 0 0 1 11459 0
macsmc-battery 1 1 0 0 0 9 91467 0
deleted 0 0 0 0 0 0 00 0
```
Note that for PCI devices, the BDF numbers are used instead. Use the `lspci -s` to see what device it is. For example, to see what `0000:01:00.0` is:
```=
$ lspci -s 0000:01:00.0
```
It'll show the corresponding PCI device:
```
01:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4387 802.11ax Dual Band Wireless LAN Controller (rev 07)
```
Common `lspci` arguments are useful for debugging. For example `-vs`, `-vvs` show verbose output.
The `0000:01:00.0` device on the PCI bus being a wake up source can be verified by looking into its device file in sysfs:
```=
$ cat /sys/class/pci_bus/0000:01/device/0000:01:00.0/power/wakeup
```
It shows `enabled`:
```
enabled
```
This can be disabled by
```=
$ sudo sh -c 'echo disabled > /sys/class/pci_bus/0000:01/device/0000:01:00.0/power/wakeup'
```
Looking into the same file again:
```=
$ cat /sys/class/pci_bus/0000:01/device/0000:01:00.0/power/wakeup
```
You'll see it becomes `disabled`:
```
disabled
```
And under the debugfs entry:
```=
$ cat /sys/kernel/debug/wakeup_sources
```
The `0000:01:00.0` now disappears, indicating the it no longer serve as a wakeup source:
```
name active_count event_count wakeup_count expire_count active_since total_time max_time last_change prevent_suspend_time
macsmc-hid 1 1 0 0 0 0 02428366 0
tps6598x-source-psy-0-003f 1 1 0 0 0 00 2877 0
tps6598x-source-psy-0-0038 1 1 0 0 0 00 2872 0
tps6598x-source-psy-0-003a 1 1 0 0 0 00 1467 0
macsmc-ac 1 1 0 0 0 1 11459 0
macsmc-battery 1 1 0 0 0 9 91467 0
deleted 0 0 0 0 0 0 00 0
```
Note that if I close the lid and open it again, the statistic of `macsmc-hid` will bump up to `2`:
```
name active_count event_count wakeup_count expire_count active_since total_time max_time last_change prevent_suspend_time
macsmc-hid 2 2 0 0 0 0 03294732 0
tps6598x-source-psy-0-003f 1 1 0 0 0 00 2877 0
tps6598x-source-psy-0-0038 1 1 0 0 0 00 2872 0
tps6598x-source-psy-0-003a 1 1 0 0 0 00 1467 0
macsmc-ac 1 1 0 0 0 1 11459 0
macsmc-battery 1 1 0 0 0 9 91467 0
deleted 0 0 0 0 0 0 00 0
```
Sign in with Wallet
Connect another wallet