410 lines
16 KiB
Plaintext
410 lines
16 KiB
Plaintext
|
What: /sys/power/
|
||
|
|
Date: August 2006
|
||
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||
|
|
Description:
|
||
|
|
The /sys/power directory will contain files that will
|
||
|
|
provide a unified interface to the power management
|
||
|
|
subsystem.
|
||
|
|
|
||
|
|
What: /sys/power/state
|
||
|
|
Date: November 2016
|
||
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||
|
|
Description:
|
||
|
|
The /sys/power/state file controls system sleep states.
|
||
|
|
Reading from this file returns the available sleep state
|
||
|
|
labels, which may be "mem" (suspend), "standby" (power-on
|
||
|
|
suspend), "freeze" (suspend-to-idle) and "disk" (hibernation).
|
||
|
|
|
||
|
|
Writing one of the above strings to this file causes the system
|
||
|
|
to transition into the corresponding state, if available.
|
||
|
|
|
||
|
|
See Documentation/admin-guide/pm/sleep-states.rst for more
|
||
|
|
information.
|
||
|
|
|
||
|
|
What: /sys/power/mem_sleep
|
||
|
|
Date: November 2016
|
||
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||
|
|
Description:
|
||
|
|
The /sys/power/mem_sleep file controls the operating mode of
|
||
|
|
system suspend. Reading from it returns the available modes
|
||
|
|
as "s2idle" (always present), "shallow" and "deep" (present if
|
||
|
|
supported). The mode that will be used on subsequent attempts
|
||
|
|
to suspend the system (by writing "mem" to the /sys/power/state
|
||
|
|
file described above) is enclosed in square brackets.
|
||
|
|
|
||
|
|
Writing one of the above strings to this file causes the mode
|
||
|
|
represented by it to be used on subsequent attempts to suspend
|
||
|
|
the system.
|
||
|
|
|
||
|
|
See Documentation/admin-guide/pm/sleep-states.rst for more
|
||
|
|
information.
|
||
|
|
|
||
|
|
What: /sys/power/disk
|
||
|
|
Date: September 2006
|
||
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||
|
|
Description:
|
||
|
|
The /sys/power/disk file controls the operating mode of the
|
||
|
|
suspend-to-disk mechanism. Reading from this file returns
|
||
|
|
the name of the method by which the system will be put to
|
||
|
|
sleep on the next suspend. There are four methods supported:
|
||
|
|
'firmware' - means that the memory image will be saved to disk
|
||
|
|
by some firmware, in which case we also assume that the
|
||
|
|
firmware will handle the system suspend.
|
||
|
|
'platform' - the memory image will be saved by the kernel and
|
||
|
|
the system will be put to sleep by the platform driver (e.g.
|
||
|
|
ACPI or other PM registers).
|
||
|
|
'shutdown' - the memory image will be saved by the kernel and
|
||
|
|
the system will be powered off.
|
||
|
|
'reboot' - the memory image will be saved by the kernel and
|
||
|
|
the system will be rebooted.
|
||
|
|
|
||
|
|
Additionally, /sys/power/disk can be used to turn on one of the
|
||
|
|
two testing modes of the suspend-to-disk mechanism: 'testproc'
|
||
|
|
or 'test'. If the suspend-to-disk mechanism is in the
|
||
|
|
'testproc' mode, writing 'disk' to /sys/power/state will cause
|
||
|
|
the kernel to disable nonboot CPUs and freeze tasks, wait for 5
|
||
|
|
seconds, unfreeze tasks and enable nonboot CPUs. If it is in
|
||
|
|
the 'test' mode, writing 'disk' to /sys/power/state will cause
|
||
|
|
the kernel to disable nonboot CPUs and freeze tasks, shrink
|
||
|
|
memory, suspend devices, wait for 5 seconds, resume devices,
|
||
|
|
unfreeze tasks and enable nonboot CPUs. Then, we are able to
|
||
|
|
look in the log messages and work out, for example, which code
|
||
|
|
is being slow and which device drivers are misbehaving.
|
||
|
|
|
||
|
|
The suspend-to-disk method may be chosen by writing to this
|
||
|
|
file one of the accepted strings:
|
||
|
|
|
||
|
|
'firmware'
|
||
|
|
'platform'
|
||
|
|
'shutdown'
|
||
|
|
'reboot'
|
||
|
|
'testproc'
|
||
|
|
'test'
|
||
|
|
|
||
|
|
It will only change to 'firmware' or 'platform' if the system
|
||
|
|
supports that.
|
||
|
|
|
||
|
|
What: /sys/power/image_size
|
||
|
|
Date: August 2006
|
||
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||
|
|
Description:
|
||
|
|
The /sys/power/image_size file controls the size of the image
|
||
|
|
created by the suspend-to-disk mechanism. It can be written a
|
||
|
|
string representing a non-negative integer that will be used
|
||
|
|
as an upper limit of the image size, in bytes. The kernel's
|
||
|
|
suspend-to-disk code will do its best to ensure the image size
|
||
|
|
will not exceed this number. However, if it turns out to be
|
||
|
|
impossible, the kernel will try to suspend anyway using the
|
||
|
|
smallest image possible. In particular, if "0" is written to
|
||
|
|
this file, the suspend image will be as small as possible.
|
||
|
|
|
||
|
|
Reading from this file will display the current image size
|
||
|
|
limit, which is set to 500 MB by default.
|
||
|
|
|
||
|
|
What: /sys/power/pm_trace
|
||
|
|
Date: August 2006
|
||
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||
|
|
Description:
|
||
|
|
The /sys/power/pm_trace file controls the code which saves the
|
||
|
|
last PM event point in the RTC across reboots, so that you can
|
||
|
|
debug a machine that just hangs during suspend (or more
|
||
|
|
commonly, during resume). Namely, the RTC is only used to save
|
||
|
|
the last PM event point if this file contains '1'. Initially
|
||
|
|
it contains '0' which may be changed to '1' by writing a
|
||
|
|
string representing a nonzero integer into it.
|
||
|
|
|
||
|
|
To use this debugging feature you should attempt to suspend
|
||
|
|
the machine, then reboot it and run
|
||
|
|
|
||
|
|
dmesg -s 1000000 | grep 'hash matches'
|
||
|
|
|
||
|
|
If you do not get any matches (or they appear to be false
|
||
|
|
positives), it is possible that the last PM event point
|
||
|
|
referred to a device created by a loadable kernel module. In
|
||
|
|
this case cat /sys/power/pm_trace_dev_match (see below) after
|
||
|
|
your system is started up and the kernel modules are loaded.
|
||
|
|
|
||
|
|
CAUTION: Using it will cause your machine's real-time (CMOS)
|
||
|
|
clock to be set to a random invalid time after a resume.
|
||
|
|
|
||
|
|
What; /sys/power/pm_trace_dev_match
|
||
|
|
Date: October 2010
|
||
|
|
Contact: James Hogan <jhogan@kernel.org>
|
||
|
|
Description:
|
||
|
|
The /sys/power/pm_trace_dev_match file contains the name of the
|
||
|
|
device associated with the last PM event point saved in the RTC
|
||
|
|
across reboots when pm_trace has been used. More precisely it
|
||
|
|
contains the list of current devices (including those
|
||
|
|
registered by loadable kernel modules since boot) which match
|
||
|
|
the device hash in the RTC at boot, with a newline after each
|
||
|
|
one.
|
||
|
|
|
||
|
|
The advantage of this file over the hash matches printed to the
|
||
|
|
kernel log (see /sys/power/pm_trace), is that it includes
|
||
|
|
devices created after boot by loadable kernel modules.
|
||
|
|
|
||
|
|
Due to the small hash size necessary to fit in the RTC, it is
|
||
|
|
possible that more than one device matches the hash, in which
|
||
|
|
case further investigation is required to determine which
|
||
|
|
device is causing the problem. Note that genuine RTC clock
|
||
|
|
values (such as when pm_trace has not been used), can still
|
||
|
|
match a device and output it's name here.
|
||
|
|
|
||
|
|
What: /sys/power/pm_async
|
||
|
|
Date: January 2009
|
||
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||
|
|
Description:
|
||
|
|
The /sys/power/pm_async file controls the switch allowing the
|
||
|
|
user space to enable or disable asynchronous suspend and resume
|
||
|
|
of devices. If enabled, this feature will cause some device
|
||
|
|
drivers' suspend and resume callbacks to be executed in parallel
|
||
|
|
with each other and with the main suspend thread. It is enabled
|
||
|
|
if this file contains "1", which is the default. It may be
|
||
|
|
disabled by writing "0" to this file, in which case all devices
|
||
|
|
will be suspended and resumed synchronously.
|
||
|
|
|
||
|
|
What: /sys/power/wakeup_count
|
||
|
|
Date: July 2010
|
||
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||
|
|
Description:
|
||
|
|
The /sys/power/wakeup_count file allows user space to put the
|
||
|
|
system into a sleep state while taking into account the
|
||
|
|
concurrent arrival of wakeup events. Reading from it returns
|
||
|
|
the current number of registered wakeup events and it blocks if
|
||
|
|
some wakeup events are being processed at the time the file is
|
||
|
|
read from. Writing to it will only succeed if the current
|
||
|
|
number of wakeup events is equal to the written value and, if
|
||
|
|
successful, will make the kernel abort a subsequent transition
|
||
|
|
to a sleep state if any wakeup events are reported after the
|
||
|
|
write has returned.
|
||
|
|
|
||
|
|
What: /sys/power/reserved_size
|
||
|
|
Date: May 2011
|
||
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||
|
|
Description:
|
||
|
|
The /sys/power/reserved_size file allows user space to control
|
||
|
|
the amount of memory reserved for allocations made by device
|
||
|
|
drivers during the "device freeze" stage of hibernation. It can
|
||
|
|
be written a string representing a non-negative integer that
|
||
|
|
will be used as the amount of memory to reserve for allocations
|
||
|
|
made by device drivers' "freeze" callbacks, in bytes.
|
||
|
|
|
||
|
|
Reading from this file will display the current value, which is
|
||
|
|
set to 1 MB by default.
|
||
|
|
|
||
|
|
What: /sys/power/autosleep
|
||
|
|
Date: April 2012
|
||
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||
|
|
Description:
|
||
|
|
The /sys/power/autosleep file can be written one of the strings
|
||
|
|
returned by reads from /sys/power/state. If that happens, a
|
||
|
|
work item attempting to trigger a transition of the system to
|
||
|
|
the sleep state represented by that string is queued up. This
|
||
|
|
attempt will only succeed if there are no active wakeup sources
|
||
|
|
in the system at that time. After every execution, regardless
|
||
|
|
of whether or not the attempt to put the system to sleep has
|
||
|
|
succeeded, the work item requeues itself until user space
|
||
|
|
writes "off" to /sys/power/autosleep.
|
||
|
|
|
||
|
|
Reading from this file causes the last string successfully
|
||
|
|
written to it to be returned.
|
||
|
|
|
||
|
|
What: /sys/power/wake_lock
|
||
|
|
Date: February 2012
|
||
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||
|
|
Description:
|
||
|
|
The /sys/power/wake_lock file allows user space to create
|
||
|
|
wakeup source objects and activate them on demand (if one of
|
||
|
|
those wakeup sources is active, reads from the
|
||
|
|
/sys/power/wakeup_count file block or return false). When a
|
||
|
|
string without white space is written to /sys/power/wake_lock,
|
||
|
|
it will be assumed to represent a wakeup source name. If there
|
||
|
|
is a wakeup source object with that name, it will be activated
|
||
|
|
(unless active already). Otherwise, a new wakeup source object
|
||
|
|
will be registered, assigned the given name and activated.
|
||
|
|
If a string written to /sys/power/wake_lock contains white
|
||
|
|
space, the part of the string preceding the white space will be
|
||
|
|
regarded as a wakeup source name and handled as descrived above.
|
||
|
|
The other part of the string will be regarded as a timeout (in
|
||
|
|
nanoseconds) such that the wakeup source will be automatically
|
||
|
|
deactivated after it has expired. The timeout, if present, is
|
||
|
|
set regardless of the current state of the wakeup source object
|
||
|
|
in question.
|
||
|
|
|
||
|
|
Reads from this file return a string consisting of the names of
|
||
|
|
wakeup sources created with the help of it that are active at
|
||
|
|
the moment, separated with spaces.
|
||
|
|
|
||
|
|
|
||
|
|
What: /sys/power/wake_unlock
|
||
|
|
Date: February 2012
|
||
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||
|
|
Description:
|
||
|
|
The /sys/power/wake_unlock file allows user space to deactivate
|
||
|
|
wakeup sources created with the help of /sys/power/wake_lock.
|
||
|
|
When a string is written to /sys/power/wake_unlock, it will be
|
||
|
|
assumed to represent the name of a wakeup source to deactivate.
|
||
|
|
If a wakeup source object of that name exists and is active at
|
||
|
|
the moment, it will be deactivated.
|
||
|
|
|
||
|
|
Reads from this file return a string consisting of the names of
|
||
|
|
wakeup sources created with the help of /sys/power/wake_lock
|
||
|
|
that are inactive at the moment, separated with spaces.
|
||
|
|
|
||
|
|
What: /sys/power/pm_print_times
|
||
|
|
Date: May 2012
|
||
|
|
Contact: Sameer Nanda <snanda@chromium.org>
|
||
|
|
Description:
|
||
|
|
The /sys/power/pm_print_times file allows user space to
|
||
|
|
control whether the time taken by devices to suspend and
|
||
|
|
resume is printed. These prints are useful for hunting down
|
||
|
|
devices that take too long to suspend or resume.
|
||
|
|
|
||
|
|
Writing a "1" enables this printing while writing a "0"
|
||
|
|
disables it. The default value is "0". Reading from this file
|
||
|
|
will display the current value.
|
||
|
|
|
||
|
|
What: /sys/power/pm_wakeup_irq
|
||
|
|
Date: April 2015
|
||
|
|
Contact: Alexandra Yates <alexandra.yates@linux.intel.org>
|
||
|
|
Description:
|
||
|
|
The /sys/power/pm_wakeup_irq file reports to user space the IRQ
|
||
|
|
number of the first wakeup interrupt (that is, the first
|
||
|
|
interrupt from an IRQ line armed for system wakeup) seen by the
|
||
|
|
kernel during the most recent system suspend/resume cycle.
|
||
|
|
|
||
|
|
This output is useful for system wakeup diagnostics of spurious
|
||
|
|
wakeup interrupts.
|
||
|
|
|
||
|
|
What: /sys/power/pm_debug_messages
|
||
|
|
Date: July 2017
|
||
|
|
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
|
||
|
|
Description:
|
||
|
|
The /sys/power/pm_debug_messages file controls the printing
|
||
|
|
of debug messages from the system suspend/hiberbation
|
||
|
|
infrastructure to the kernel log.
|
||
|
|
|
||
|
|
Writing a "1" to this file enables the debug messages and
|
||
|
|
writing a "0" (default) to it disables them. Reads from
|
||
|
|
this file return the current value.
|
||
|
|
|
||
|
|
What: /sys/power/resume_offset
|
||
|
|
Date: April 2018
|
||
|
|
Contact: Mario Limonciello <mario.limonciello@dell.com>
|
||
|
|
Description:
|
||
|
|
This file is used for telling the kernel an offset into a disk
|
||
|
|
to use when hibernating the system such as with a swap file.
|
||
|
|
|
||
|
|
Reads from this file will display the current offset
|
||
|
|
the kernel will be using on the next hibernation
|
||
|
|
attempt.
|
||
|
|
|
||
|
|
Using this sysfs file will override any values that were
|
||
|
|
set using the kernel command line for disk offset.
|
||
|
|
|
||
|
|
What: /sys/power/suspend_stats
|
||
|
|
Date: July 2019
|
||
|
|
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
|
||
|
|
Description:
|
||
|
|
The /sys/power/suspend_stats directory contains suspend related
|
||
|
|
statistics.
|
||
|
|
|
||
|
|
What: /sys/power/suspend_stats/success
|
||
|
|
Date: July 2019
|
||
|
|
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
|
||
|
|
Description:
|
||
|
|
The /sys/power/suspend_stats/success file contains the number
|
||
|
|
of times entering system sleep state succeeded.
|
||
|
|
|
||
|
|
What: /sys/power/suspend_stats/fail
|
||
|
|
Date: July 2019
|
||
|
|
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
|
||
|
|
Description:
|
||
|
|
The /sys/power/suspend_stats/fail file contains the number
|
||
|
|
of times entering system sleep state failed.
|
||
|
|
|
||
|
|
What: /sys/power/suspend_stats/failed_freeze
|
||
|
|
Date: July 2019
|
||
|
|
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
|
||
|
|
Description:
|
||
|
|
The /sys/power/suspend_stats/failed_freeze file contains the
|
||
|
|
number of times freezing processes failed.
|
||
|
|
|
||
|
|
What: /sys/power/suspend_stats/failed_prepare
|
||
|
|
Date: July 2019
|
||
|
|
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
|
||
|
|
Description:
|
||
|
|
The /sys/power/suspend_stats/failed_prepare file contains the
|
||
|
|
number of times preparing all non-sysdev devices for
|
||
|
|
a system PM transition failed.
|
||
|
|
|
||
|
|
What: /sys/power/suspend_stats/failed_resume
|
||
|
|
Date: July 2019
|
||
|
|
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
|
||
|
|
Description:
|
||
|
|
The /sys/power/suspend_stats/failed_resume file contains the
|
||
|
|
number of times executing "resume" callbacks of
|
||
|
|
non-sysdev devices failed.
|
||
|
|
|
||
|
|
What: /sys/power/suspend_stats/failed_resume_early
|
||
|
|
Date: July 2019
|
||
|
|
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
|
||
|
|
Description:
|
||
|
|
The /sys/power/suspend_stats/failed_resume_early file contains
|
||
|
|
the number of times executing "early resume" callbacks
|
||
|
|
of devices failed.
|
||
|
|
|
||
|
|
What: /sys/power/suspend_stats/failed_resume_noirq
|
||
|
|
Date: July 2019
|
||
|
|
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
|
||
|
|
Description:
|
||
|
|
The /sys/power/suspend_stats/failed_resume_noirq file contains
|
||
|
|
the number of times executing "noirq resume" callbacks
|
||
|
|
of devices failed.
|
||
|
|
|
||
|
|
What: /sys/power/suspend_stats/failed_suspend
|
||
|
|
Date: July 2019
|
||
|
|
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
|
||
|
|
Description:
|
||
|
|
The /sys/power/suspend_stats/failed_suspend file contains
|
||
|
|
the number of times executing "suspend" callbacks
|
||
|
|
of all non-sysdev devices failed.
|
||
|
|
|
||
|
|
What: /sys/power/suspend_stats/failed_suspend_late
|
||
|
|
Date: July 2019
|
||
|
|
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
|
||
|
|
Description:
|
||
|
|
The /sys/power/suspend_stats/failed_suspend_late file contains
|
||
|
|
the number of times executing "late suspend" callbacks
|
||
|
|
of all devices failed.
|
||
|
|
|
||
|
|
What: /sys/power/suspend_stats/failed_suspend_noirq
|
||
|
|
Date: July 2019
|
||
|
|
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
|
||
|
|
Description:
|
||
|
|
The /sys/power/suspend_stats/failed_suspend_noirq file contains
|
||
|
|
the number of times executing "noirq suspend" callbacks
|
||
|
|
of all devices failed.
|
||
|
|
|
||
|
|
What: /sys/power/suspend_stats/last_failed_dev
|
||
|
|
Date: July 2019
|
||
|
|
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
|
||
|
|
Description:
|
||
|
|
The /sys/power/suspend_stats/last_failed_dev file contains
|
||
|
|
the last device for which a suspend/resume callback failed.
|
||
|
|
|
||
|
|
What: /sys/power/suspend_stats/last_failed_errno
|
||
|
|
Date: July 2019
|
||
|
|
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
|
||
|
|
Description:
|
||
|
|
The /sys/power/suspend_stats/last_failed_errno file contains
|
||
|
|
the errno of the last failed attempt at entering
|
||
|
|
system sleep state.
|
||
|
|
|
||
|
|
What: /sys/power/suspend_stats/last_failed_step
|
||
|
|
Date: July 2019
|
||
|
|
Contact: Kalesh Singh <kaleshsingh96@gmail.com>
|
||
|
|
Description:
|
||
|
|
The /sys/power/suspend_stats/last_failed_step file contains
|
||
|
|
the last failed step in the suspend/resume path.
|