Hibernation과 suspend debugging

Hibernation mode 기본 시험

이 문서는 Rafael J. Wysocki가 2007년에 작성했으며 GPL로 배포됩니다. Hibernation은 suspend to disk 또는 STD라고도 합니다.

먼저 `reboot` mode에서 hibernation을 시험합니다. System은 image를 만들고 reboot한 뒤 resume하여 전환을 시작한 command prompt로 돌아와야 합니다.

# echo reboot > /sys/power/disk
# echo disk > /sys/power/state

성공하면 hibernation이 대체로 정상이라고 볼 수 있지만, 두 번째 suspend·resume에서만 드러나는 문제가 있으므로 최소 두세 번 연속 반복해야 합니다.

`reboot`와 `shutdown` mode는 ACPI system의 hibernation에 필요할 수 있는 일부 platform callback을 PM core가 건너뜁니다. `reboot`가 실패하면 기본이자 권장 mode인 `platform`을 시험합니다.

# echo platform > /sys/power/disk
# echo disk > /sys/power/state

BIOS가 깨진 system에서는 `platform` mode가 실패할 수 있으므로 `shutdown` mode를 시험합니다. 이는 `reboot`와 비슷하지만 resume하려면 power button을 눌러야 합니다.

# echo shutdown > /sys/power/disk
# echo disk > /sys/power/state

`platform`과 `shutdown` 모두 동작하지 않으면 무엇이 실패하는지 단계별로 식별해야 합니다.

=================================
Debugging hibernation and suspend
=================================

        (C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL

1. Testing hibernation (aka suspend to disk or STD)
===================================================

To check if hibernation works, you can try to hibernate in the "reboot" mode::

        # echo reboot > /sys/power/disk
        # echo disk > /sys/power/state

and the system should create a hibernation image, reboot, resume and get back to
the command prompt where you have started the transition.  If that happens,
hibernation is most likely to work correctly.  Still, you need to repeat the
test at least a couple of times in a row for confidence.  [This is necessary,
because some problems only show up on a second attempt at suspending and
resuming the system.]  Moreover, hibernating in the "reboot" and "shutdown"
modes causes the PM core to skip some platform-related callbacks which on ACPI
systems might be necessary to make hibernation work.  Thus, if your machine
fails to hibernate or resume in the "reboot" mode, you should try the
"platform" mode::

        # echo platform > /sys/power/disk
        # echo disk > /sys/power/state

which is the default and recommended mode of hibernation.

Unfortunately, the "platform" mode of hibernation does not work on some systems
with broken BIOSes.  In such cases the "shutdown" mode of hibernation might
work::

        # echo shutdown > /sys/power/disk
        # echo disk > /sys/power/state

(it is similar to the "reboot" mode, but it requires you to press the power
button to make the system resume).

If neither "platform" nor "shutdown" hibernation mode works, you will need to
identify what goes wrong.

CONFIG_PM_DEBUG와 pm_test 단계

Kernel을 `CONFIG_PM_DEBUG`로 build하면 `/sys/power/pm_test`로 hibernation core의 test mode를 선택할 수 있습니다.

Platform global control method는 ACPI system에서만 사용할 수 있고 hibernation mode가 `platform`으로 설정된 경우에만 시험합니다.

a) Test modes of hibernation
----------------------------

To find out why hibernation fails on your system, you can use a special testing
facility available if the kernel is compiled with CONFIG_PM_DEBUG set.  Then,
there is the file /sys/power/pm_test that can be used to make the hibernation
core run in a test mode.  There are 5 test modes available:

freezer
        - test the freezing of processes

devices
        - test the freezing of processes and suspending of devices

platform
        - test the freezing of processes, suspending of devices and platform
          global control methods [1]_

processors
        - test the freezing of processes, suspending of devices, platform
          global control methods [1]_ and the disabling of nonboot CPUs

core
        - test the freezing of processes, suspending of devices, platform global
          control methods\ [1]_, the disabling of nonboot CPUs and suspending
          of platform/system devices

.. [1]

    the platform global control methods are only available on ACPI systems
    and are only tested if the hibernation mode is set to "platform"

Test mode 실행과 순서

사용할 mode 문자열을 `/sys/power/pm_test`에 기록한 뒤 표준 hibernation command를 실행합니다. 다음 예제는 `platform` hibernation에서 `devices` test를 수행합니다.

# echo devices > /sys/power/pm_test
# echo platform > /sys/power/disk
# echo disk > /sys/power/state

Kernel은 process를 freeze하고 device를 suspend한 뒤 기본 5초 동안 기다립니다. Delay는 `suspend.pm_test_delay` module parameter로 조정할 수 있습니다. 이어 device를 resume하고 process를 thaw합니다.

`pm_test`에 `platform`을 기록하면 device suspend 뒤 ACPI global control method 같은 platform firmware 준비 method를 호출하고, 지정 시간 뒤 hibernation을 취소하는 platform method를 호출합니다.

`none`을 기록하면 정상 hibernation·suspend operation으로 돌아갑니다. File을 읽으면 `none`을 포함한 모든 test가 공백으로 구분되어 나오고 현재 level은 square bracket으로 표시됩니다.

각 level은 이전보다 침습적이며 `core`는 hibernation image를 만들지 않고 hardware와 driver를 가능한 깊게 검사합니다. `devices`가 실패하면 이후 `platform`도 실패하므로 `freezer`부터 `core`까지 순서대로 진행하고 각 level을 여러 번 반복합니다.

To use one of them it is necessary to write the corresponding string to
/sys/power/pm_test (eg. "devices" to test the freezing of processes and
suspending devices) and issue the standard hibernation commands.  For example,
to use the "devices" test mode along with the "platform" mode of hibernation,
you should do the following::

        # echo devices > /sys/power/pm_test
        # echo platform > /sys/power/disk
        # echo disk > /sys/power/state

Then, the kernel will try to freeze processes, suspend devices, wait a few
seconds (5 by default, but configurable by the suspend.pm_test_delay module
parameter), resume devices and thaw processes.  If "platform" is written to
/sys/power/pm_test , then after suspending devices the kernel will additionally
invoke the global control methods (eg. ACPI global control methods) used to
prepare the platform firmware for hibernation.  Next, it will wait a
configurable number of seconds and invoke the platform (eg. ACPI) global
methods used to cancel hibernation etc.

Writing "none" to /sys/power/pm_test causes the kernel to switch to the normal
hibernation/suspend operations.  Also, when open for reading, /sys/power/pm_test
contains a space-separated list of all available tests (including "none" that
represents the normal functionality) in which the current test level is
indicated by square brackets.

Generally, as you can see, each test level is more "invasive" than the previous
one and the "core" level tests the hardware and drivers as deeply as possible
without creating a hibernation image.  Obviously, if the "devices" test fails,
the "platform" test will fail as well and so on.  Thus, as a rule of thumb, you
should try the test modes starting from "freezer", through "devices", "platform"
and "processors" up to "core" (repeat the test on each level a couple of times
to make sure that any random factors are avoided).

Freezer·device 실패 진단

`freezer` test 실패는 freeze할 수 없는 task가 있다는 뜻입니다. 실패 뒤 `dmesg`를 분석하면 원인 task를 찾을 수 있으며 보통 tasks freezer subsystem 문제이므로 보고해야 합니다.

`devices` test 실패는 대개 device를 suspend 또는 resume할 수 없는 driver가 있다는 뜻입니다. Resume 실패 뒤 system이 hang하거나 불안정해질 수 있습니다.

원인 driver는 binary search로 찾습니다. 실패하면 현재 load된 driver 절반을 unload하고 반복하며, 성공하면 방금 unload한 driver의 절반을 다시 load해 반복합니다. Reboot가 필요할 수 있으므로 시험 전 load된 driver를 기록해야 합니다.

실패 driver가 하나 이상일 수 있습니다. 찾은 driver는 hibernation 전에 항상 unload하고 문제를 보고해야 합니다.

Module을 모두 unload해도 실패하면 kernel에 built-in된 driver 가운데 module로 build 가능한 것을 찾아 module로 다시 시험합니다. `noapic`, `noacpi`, `acpi=off` 같은 kernel command-line option도 시도할 수 있습니다.

If the "freezer" test fails, there is a task that cannot be frozen (in that case
it usually is possible to identify the offending task by analysing the output of
dmesg obtained after the failing test).  Failure at this level usually means
that there is a problem with the tasks freezer subsystem that should be
reported.

If the "devices" test fails, most likely there is a driver that cannot suspend
or resume its device (in the latter case the system may hang or become unstable
after the test, so please take that into consideration).  To find this driver,
you can carry out a binary search according to the rules:

- if the test fails, unload a half of the drivers currently loaded and repeat
  (that would probably involve rebooting the system, so always note what drivers
  have been loaded before the test),
- if the test succeeds, load a half of the drivers you have unloaded most
  recently and repeat.

Once you have found the failing driver (there can be more than just one of
them), you have to unload it every time before hibernation.  In that case please
make sure to report the problem with the driver.

It is also possible that the "devices" test will still fail after you have
unloaded all modules. In that case, you may want to look in your kernel
configuration for the drivers that can be compiled as modules (and test again
with these drivers compiled as modules).  You may also try to use some special
kernel command line options such as "noapic", "noacpi" or even "acpi=off".

Platform·processor·core 실패

`platform` test가 실패하면 ACPI 같은 platform firmware 처리에 문제가 있어 `platform` hibernation이 동작하기 어렵습니다. `shutdown` mode를 시도할 수 있지만 임시 workaround에 가깝습니다.

`processors` test 실패는 nonboot CPU disable·enable이 동작하지 않는다는 뜻이며 SMP system에서만 해당할 수 있습니다. `/sys/devices/system/cpu/cpu*/online`로 nonboot CPU를 직접 off/on하여 확인할 수 있습니다.

`core` test 실패는 interrupt를 끈 한 CPU에서 수행하는 system/platform device suspend가 실패했다는 뜻입니다. Hardware 관련일 가능성이 높고 심각하므로 보고해야 합니다.

`platform`, `processors`, `core` 실패는 system hang이나 불안정을 일으킬 수 있습니다. Hardware와 관련된 중대한 문제일 수 있으므로 주의하고 반드시 보고합니다.

If the "platform" test fails, there is a problem with the handling of the
platform (eg. ACPI) firmware on your system.  In that case the "platform" mode
of hibernation is not likely to work.  You can try the "shutdown" mode, but that
is rather a poor man's workaround.

If the "processors" test fails, the disabling/enabling of nonboot CPUs does not
work (of course, this only may be an issue on SMP systems) and the problem
should be reported.  In that case you can also try to switch the nonboot CPUs
off and on using the /sys/devices/system/cpu/cpu*/online sysfs attributes and
see if that works.

If the "core" test fails, which means that suspending of the system/platform
devices has failed (these devices are suspended on one CPU with interrupts off),
the problem is most probably hardware-related and serious, so it should be
reported.

A failure of any of the "platform", "processors" or "core" tests may cause your
system to hang or become unstable, so please beware.  Such a failure usually
indicates a serious problem that very well may be related to the hardware, but
please report it anyway.

Minimal configuration 시험

모든 hibernation test mode가 성공하면 kernel command line에 `init=/bin/bash`를 넣어 minimal system으로 boot한 뒤 `reboot`, `shutdown`, `platform` mode를 시험합니다.

Minimal configuration에서도 실패하면 kernel에 statically compiled된 driver 문제일 수 있습니다. 더 많은 driver를 module로 build해 개별 시험합니다.

Minimal configuration에서는 성공하면 modular driver 문제입니다. 평소 사용하는 module 절반을 load해 이분 탐색합니다. n개 module에서 실패하면 n/2를 unload하고, 성공하면 n/2를 더 load해 반복합니다.

원인 module을 찾으면 hibernation 전에 항상 unload하고 문제를 보고합니다.

b) Testing minimal configuration
--------------------------------

If all of the hibernation test modes work, you can boot the system with the
"init=/bin/bash" command line parameter and attempt to hibernate in the
"reboot", "shutdown" and "platform" modes.  If that does not work, there
probably is a problem with a driver statically compiled into the kernel and you
can try to compile more drivers as modules, so that they can be tested
individually.  Otherwise, there is a problem with a modular driver and you can
find it by loading a half of the modules you normally use and binary searching
in accordance with the algorithm:
- if there are n modules loaded and the attempt to suspend and resume fails,
unload n/2 of the modules and try again (that would probably involve rebooting
the system),
- if there are n modules loaded and the attempt to suspend and resume succeeds,
load n/2 modules more and try again.

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).

test_resume option

`/sys/power/disk`는 hibernation image를 만든 뒤 kernel이 수행할 동작을 정합니다. `test_resume`은 방금 만든 image로 즉시 restore합니다.

# echo test_resume > /sys/power/disk
# echo disk > /sys/power/state

Image를 만든 뒤 platform firmware를 전혀 거치지 않고 즉시 resume하므로 실제 hibernation resume 실패가 firmware interaction 때문인지 확인할 수 있습니다.

이 시험이 항상 성공하지만 실제 hibernation resume이 실패하거나 불안정하면 platform firmware가 원인일 수 있습니다.

다른 kernel로 image를 restore할 수 있는 architecture·platform 또는 kernel address space randomization을 지원하는 환경에서는 restore kernel과 image kernel 차이가 원인인지 검사하는 데도 사용할 수 있습니다.

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.

고급 debugging

Minimal configuration에서도 hibernation이 동작하지 않고 driver를 module로 바꾸기 어렵거나 unload할 수 없다면 고급 debugging 기법을 사용합니다.

Serial port가 있으면 kernel에 `no_console_suspend` parameter를 주고 serial console로 suspend·resume 실패 전후 kernel message를 기록합니다.

대안으로 FireWire port와 firescope(`http://v3.sk/~lkundrak/firescope/`)를 사용할 수 있습니다. x86에서는 `Documentation/power/s2ram.rst`에 문서화된 `PM_TRACE` mechanism도 사용할 수 있습니다.

d) Advanced debugging
---------------------

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
modules cannot be unloaded, you can use one of the more advanced debugging
techniques to find the problem.  First, if there is a serial port in your box,
you can boot the kernel with the 'no_console_suspend' parameter and try to log
kernel messages using the serial console.  This may provide you with some
information about the reasons of the suspend (resume) failure.  Alternatively,
it may be possible to use a FireWire port for debugging with firescope
(http://v3.sk/~lkundrak/firescope/).  On x86 it is also possible to
use the PM_TRACE mechanism documented in Documentation/power/s2ram.rst .

Suspend to RAM 시험

Suspend to RAM(STR)은 원문이 안내하는 `http://suspend.sf.net`의 `s2ram` tool과 S2RAM_LINK 문서를 사용하는 편이 편리합니다.

`CONFIG_PM_DEBUG` kernel에서는 `/sys/power/pm_test`에 `freezer`, `devices`, `platform`, `processors`, `core`를 기록하면 hibernation과 같은 정의의 STR test mode로 동작합니다.

`core` test는 system을 실제 sleep state로 넣는 platform firmware 호출을 제외한 모든 것을 검사합니다. `pm_test`를 통해 suspend·resume에 실패하는 driver를 식별할 수 있으며 STR 전에는 그 driver를 unload해야 합니다.

S2RAM_LINK 절차가 기본 상태에서 실패하면 `init=/bin/bash` minimal configuration으로 boot하고 앞서 설명한 것과 같은 driver 이분 탐색을 수행합니다. 실패 driver는 매 STR 전 unload하고 문제를 보고합니다.

2. Testing suspend to RAM (STR)
===============================

To verify that the STR works, it is generally more convenient to use the s2ram
tool available from http://suspend.sf.net and documented at
http://en.opensuse.org/SDB:Suspend_to_RAM (S2RAM_LINK).

Namely, after writing "freezer", "devices", "platform", "processors", or "core"
into /sys/power/pm_test (available if the kernel is compiled with
CONFIG_PM_DEBUG set) the suspend code will work in the test mode corresponding
to given string.  The STR test modes are defined in the same way as for
hibernation, so please refer to Section 1 for more information about them.  In
particular, the "core" test allows you to test everything except for the actual
invocation of the platform firmware in order to put the system into the sleep
state.

Among other things, the testing with the help of /sys/power/pm_test may allow
you to identify drivers that fail to suspend or resume their devices.  They
should be unloaded every time before an STR transition.

Next, you can follow the instructions at S2RAM_LINK to test the system, but if
it does not work "out of the box", you may need to boot it with
"init=/bin/bash" and test s2ram in the minimal configuration.  In that case,
you may be able to search for failing drivers by following the procedure
analogous to the one described in section 1.  If you find some failing drivers,
you will have to unload them every time before an STR transition (ie. before
you run s2ram), and please report the problems with them.

suspend_stats 해석

Debugfs의 `/sys/kernel/debug/suspend_stats`는 suspend to RAM 통계를 제공합니다. 먼저 debugfs를 mount한 뒤 file을 읽습니다.

# mount -t debugfs none /sys/kernel/debug
# cat /sys/kernel/debug/suspend_stats
success: 20
fail: 5
failed_freeze: 0
failed_prepare: 0
failed_suspend: 5
failed_suspend_noirq: 0
failed_resume: 0
failed_resume_noirq: 0
failures:
  last_failed_dev: alarm
                   adc
  last_failed_errno: -16
                     -16
  last_failed_step: suspend
                    suspend

`success`는 STR 성공 횟수, `fail`은 실패 횟수입니다. 나머지 `failed_*` field는 suspend 단계별 실패 횟수를 나타냅니다.

`suspend_stats`는 최근 실패 device, errno, 실패 step을 두 건까지만 나열합니다.

There is a debugfs entry which shows the suspend to RAM statistics. Here is an
example of its output::

        # mount -t debugfs none /sys/kernel/debug
        # cat /sys/kernel/debug/suspend_stats
        success: 20
        fail: 5
        failed_freeze: 0
        failed_prepare: 0
        failed_suspend: 5
        failed_suspend_noirq: 0
        failed_resume: 0
        failed_resume_noirq: 0
        failures:
          last_failed_dev:        alarm
                                adc
          last_failed_errno:        -16
                                -16
          last_failed_step:        suspend
                                suspend

Field success means the success number of suspend to RAM, and field fail means
the failure number. Others are the failure number of different steps of suspend
to RAM. suspend_stats just lists the last 2 failed devices, error number and
failed step of suspend.