Try   HackMD

Power Management References - Special Files

References

  1. Symbols under /sys/power of Linux ABI documentation.
  2. 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 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
Last changed by 
 
0xff07
Mise-en-place for the omnivores!
0
335
Published on HackMD