How to get s2ram working

s2ram 문제의 첫 점검

이 문서는 Linus Torvalds와 Pavel Machek가 정리한 suspend-to-RAM(s2ram) 진단 절차입니다. 먼저 `suspend.sf.net`의 s2ram program이 제공하는 정상 동작 machine whitelist와 machine별 우회법을 확인합니다.

해결되지 않으면 `tricks.txt`와 `video.txt`를 읽습니다. 고장 난 module 하나가 원인이라 단순히 unload하는 것만으로 해결될 수 있습니다. 마지막으로 아래의 Linus `TRACE_RESUME` infrastructure로 resume 실패 지점을 추적합니다.

========================
How to get s2ram working
========================

2006 Linus Torvalds
2006 Pavel Machek

1) Check suspend.sf.net, program s2ram there has long whitelist of
   "known ok" machines, along with tricks to use on each one.

2) If that does not help, try reading tricks.txt and
   video.txt. Perhaps problem is as simple as broken module, and
   simple module unload can fix it.

3) You can use Linus' TRACE_RESUME infrastructure, described below.

TRACE_RESUME 사용법

STR 실패는 대개 buggy driver이며 suspend/resume debugging이 유일한 진단 수단인 경우가 많습니다. 강력하지만 resume하지 못하는 driver에 `TRACE_RESUME()` marker를 넣고 compile과 reboot를 반복해야 하므로 시간이 듭니다.

`PM_DEBUG`와 `PM_TRACE`를 enable한 뒤 script에서 `sync`, `echo 1 > /sys/power/pm_trace`, `echo mem > /sys/power/state`를 차례로 실행해 suspend합니다.

Resume하지 못하면 전원 버튼으로 빠르게 reboot하고 `dmesg`의 magic number와 hash match를 확인합니다. 예제의 마지막 trace event는 `0000:01:00.0` device resume 직전입니다. `lspci`와 `/sys/devices/pci*`로 driver를 찾아 수정·disable하거나 resume function 내부에 marker를 더 넣습니다.

Hash와 일치하는 device가 없거나 false positive라면 hash 검사 뒤에 load되는 kernel module의 device일 수 있습니다. Module을 더 load한 후 `cat /sys/power/pm_trace_dev_match`로 현재 device에 다시 대조합니다.

문서의 EVO 예제에서는 ATI Radeon mobility VGA를 다루던 `radeonfb`가 PLL 설정 중 hang되어 resume하지 못했습니다. Regular VGA console을 쓰고 X가 resume하도록 하자 정상 동작했습니다.

Using TRACE_RESUME
~~~~~~~~~~~~~~~~~~

I've been working at making the machines I have able to STR, and almost
always it's a driver that is buggy. Thank God for the suspend/resume
debugging - the thing that Chuck tried to disable. That's often the _only_
way to debug these things, and it's actually pretty powerful (but
time-consuming - having to insert TRACE_RESUME() markers into the device
driver that doesn't resume and recompile and reboot).

Anyway, the way to debug this for people who are interested (have a
machine that doesn't boot) is:

 - enable PM_DEBUG, and PM_TRACE

 - use a script like this::

        #!/bin/sh
        sync
        echo 1 > /sys/power/pm_trace
        echo mem > /sys/power/state

   to suspend

 - if it doesn't come back up (which is usually the problem), reboot by
   holding the power button down, and look at the dmesg output for things
   like::

        Magic number: 4:156:725
        hash matches drivers/base/power/resume.c:28
        hash matches device 0000:01:00.0

   which means that the last trace event was just before trying to resume
   device 0000:01:00.0. Then figure out what driver is controlling that
   device (lspci and /sys/devices/pci* is your friend), and see if you can
   fix it, disable it, or trace into its resume function.

   If no device matches the hash (or any matches appear to be false positives),
   the culprit may be a device from a loadable kernel module that is not loaded
   until after the hash is checked. You can check the hash against the current
   devices again after more modules are loaded using sysfs::

        cat /sys/power/pm_trace_dev_match

For example, the above happens to be the VGA device on my EVO, which I
used to run with "radeonfb" (it's an ATI Radeon mobility). It turns out
that "radeonfb" simply cannot resume that device - it tries to set the
PLL's, and it just _hangs_. Using the regular VGA console and letting X
resume it instead works fine.

pm_trace의 RTC 제약

`pm_trace`는 reboot 뒤에도 값을 보존하면서 resume 중 확실히 사용할 수 있는 hardware가 RTC(Real Time Clock)뿐이므로 magic number를 system RTC에 저장합니다.

`pm_trace`는 asynchronous suspend와 호환되지 않아 이를 끕니다. 따라서 timing 또는 ordering bug가 우연히 가려질 수도 있습니다.

Resume이 성공해도 system clock에는 올바른 날짜·시간 대신 magic number에 대응하는 값이 남습니다. `ntp-date`나 `rdate`로 외부 time source에서 시간을 복원해야 합니다. RTC는 계속 진행하므로 실패 뒤 reboot도 빨리 해야 하며, 너무 늦으면 seconds와 minute 하위 bit를 쓰지 않더라도 magic value가 손상됩니다.

NOTE
====
pm_trace uses the system's Real Time Clock (RTC) to save the magic number.
Reason for this is that the RTC is the only reliably available piece of
hardware during resume operations where a value can be set that will
survive a reboot.

pm_trace is not compatible with asynchronous suspend, so it turns
asynchronous suspend off (which may work around timing or
ordering-sensitive bugs).

Consequence is that after a resume (even if it is successful) your system
clock will have a value corresponding to the magic number instead of the
correct date/time! It is therefore advisable to use a program like ntp-date
or rdate to reset the correct date/time from an external time source when
using this trace option.

As the clock keeps ticking it is also essential that the reboot is done
quickly after the resume failure. The trace option does not use the seconds
or the low order bits of the minutes of the RTC, but a too long delay will
corrupt the magic value.