PM / sleep: Update some system sleep documentation

Update some documentation related to system sleep to document new
features and remove outdated information from it.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Chen Yu <yu.c.chen@intel.com>
This commit is contained in:
Rafael J. Wysocki 2016-08-13 02:54:04 +02:00
parent 62822e2ec4
commit 947d2c2cd3
2 changed files with 85 additions and 59 deletions

View File

@ -164,7 +164,32 @@ load n/2 modules more and try again.
Again, if you find the offending module(s), it(they) must be unloaded every time Again, if you find the offending module(s), it(they) must be unloaded every time
before hibernation, and please report the problem with it(them). before hibernation, and please report the problem with it(them).
c) Advanced debugging c) Using the "test_resume" hibernation option
/sys/power/disk generally tells the kernel what to do after creating a
hibernation image. One of the available options is "test_resume" which
causes the just created image to be used for immediate restoration. Namely,
after doing:
# echo test_resume > /sys/power/disk
# echo disk > /sys/power/state
a hibernation image will be created and a resume from it will be triggered
immediately without involving the platform firmware in any way.
That test can be used to check if failures to resume from hibernation are
related to bad interactions with the platform firmware. That is, if the above
works every time, but resume from actual hibernation does not work or is
unreliable, the platform firmware may be responsible for the failures.
On architectures and platforms that support using different kernels to restore
hibernation images (that is, the kernel used to read the image from storage and
load it into memory is different from the one included in the image) or support
kernel address space randomization, it also can be used to check if failures
to resume may be related to the differences between the restore and image
kernels.
d) Advanced debugging
In case that hibernation does not work on your system even in the minimal In case that hibernation does not work on your system even in the minimal
configuration and compiling more drivers as modules is not practical or some configuration and compiling more drivers as modules is not practical or some

View File

@ -1,75 +1,76 @@
Power Management Interface Power Management Interface for System Sleep
Copyright (c) 2016 Intel Corp., Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The power management subsystem provides a unified sysfs interface to The power management subsystem provides userspace with a unified sysfs interface
userspace, regardless of what architecture or platform one is for system sleep regardless of the underlying system architecture or platform.
running. The interface exists in /sys/power/ directory (assuming sysfs The interface is located in the /sys/power/ directory (assuming that sysfs is
is mounted at /sys). mounted at /sys).
/sys/power/state controls system power state. Reading from this file /sys/power/state is the system sleep state control file.
returns what states are supported, which is hard-coded to 'freeze',
'standby' (Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk'
(Suspend-to-Disk).
Writing to this file one of those strings causes the system to Reading from it returns a list of supported sleep states, encoded as:
transition into that state. Please see the file
Documentation/power/states.txt for a description of each of those
states.
'freeze' (Suspend-to-Idle)
'standby' (Power-On Suspend)
'mem' (Suspend-to-RAM)
'disk' (Suspend-to-Disk)
/sys/power/disk controls the operating mode of the suspend-to-disk Suspend-to-Idle is always supported. Suspend-to-Disk is always supported
mechanism. Suspend-to-disk can be handled in several ways. We have a too as long the kernel has been configured to support hibernation at all
few options for putting the system to sleep - using the platform driver (ie. CONFIG_HIBERNATION is set in the kernel configuration file). Support
(e.g. ACPI or other suspend_ops), powering off the system or rebooting the for Suspend-to-RAM and Power-On Suspend depends on the capabilities of the
system (for testing). platform.
Additionally, /sys/power/disk can be used to turn on one of the two testing If one of the strings listed in /sys/power/state is written to it, the system
modes of the suspend-to-disk mechanism: 'testproc' or 'test'. If the will attempt to transition into the corresponding sleep state. Refer to
suspend-to-disk mechanism is in the 'testproc' mode, writing 'disk' to Documentation/power/states.txt for a description of each of those states.
/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.
Reading from this file will display all supported modes and the currently /sys/power/disk controls the operating mode of hibernation (Suspend-to-Disk).
selected one in brackets, for example Specifically, it tells the kernel what to do after creating a hibernation image.
[shutdown] reboot test testproc Reading from it returns a list of supported options encoded as:
Writing to this file will accept one of 'platform' (put the system into sleep using a platform-provided method)
'shutdown' (shut the system down)
'reboot' (reboot the system)
'suspend' (trigger a Suspend-to-RAM transition)
'test_resume' (resume-after-hibernation test mode)
'platform' (only if the platform supports it) The currently selected option is printed in square brackets.
'shutdown'
'reboot'
'testproc'
'test'
/sys/power/image_size controls the size of the image created by The 'platform' option is only available if the platform provides a special
the suspend-to-disk mechanism. It can be written a string mechanism to put the system to sleep after creating a hibernation image (ACPI
representing a non-negative integer that will be used as an upper does that, for example). The 'suspend' option is available if Suspend-to-RAM
limit of the image size, in bytes. The suspend-to-disk mechanism will is supported. Refer to Documentation/power/basic_pm_debugging.txt for the
do its best to ensure the image size will not exceed that number. However, description of the 'test_resume' option.
if this turns out to be impossible, it 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 To select an option, write the string representing it to /sys/power/disk.
is set to 2/5 of available RAM by default.
/sys/power/pm_trace controls the code which saves the last PM event point in /sys/power/image_size controls the size of hibernation images.
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 It can be written a string representing a non-negative integer that will be
reboot it and run used as a best-effort upper limit of the image size, in bytes. The hibernation
core will do its best to ensure that the image size will not exceed that number.
However, if that turns out to be impossible to achieve, a hibernation image will
still be created and its size will be as small as possible. In particular,
writing '0' to this file will enforce hibernation images to be as small as
possible.
dmesg -s 1000000 | grep 'hash matches' Reading from this file returns the current image size limit, which is set to
around 2/5 of available RAM by default.
CAUTION: Using it will cause your machine's real-time (CMOS) clock to be /sys/power/pm_trace controls the PM trace mechanism saving the last suspend
set to a random invalid time after a resume. or resume event point in the RTC across reboots.
It helps to debug hard lockups or reboots due to device driver failures that
occur during system suspend or resume (which is more common) more effectively.
If /sys/power/pm_trace contains '1', the fingerprint of each suspend/resume
event point in turn will be stored in the RTC memory (overwriting the actual
RTC information), so it will survive a system crash if one occurs right after
storing it and it can be used later to identify the driver that caused the crash
to happen (see Documentation/power/s2ram.txt for more information).
Initially it contains '0' which may be changed to '1' by writing a string
representing a nonzero integer into it.