]> git.proxmox.com Git - mirror_ubuntu-zesty-kernel.git/blame - Documentation/power/s2ram.txt
Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel...
[mirror_ubuntu-zesty-kernel.git] / Documentation / power / s2ram.txt
CommitLineData
06df6a5c
PM
1 How to get s2ram working
2 ~~~~~~~~~~~~~~~~~~~~~~~~
3 2006 Linus Torvalds
4 2006 Pavel Machek
5
61) Check suspend.sf.net, program s2ram there has long whitelist of
7 "known ok" machines, along with tricks to use on each one.
8
92) If that does not help, try reading tricks.txt and
10 video.txt. Perhaps problem is as simple as broken module, and
11 simple module unload can fix it.
12
133) You can use Linus' TRACE_RESUME infrastructure, described below.
14
15 Using TRACE_RESUME
16 ~~~~~~~~~~~~~~~~~~
17
18I've been working at making the machines I have able to STR, and almost
19always it's a driver that is buggy. Thank God for the suspend/resume
20debugging - the thing that Chuck tried to disable. That's often the _only_
21way to debug these things, and it's actually pretty powerful (but
22time-consuming - having to insert TRACE_RESUME() markers into the device
23driver that doesn't resume and recompile and reboot).
24
25Anyway, the way to debug this for people who are interested (have a
26machine that doesn't boot) is:
27
28 - enable PM_DEBUG, and PM_TRACE
29
30 - use a script like this:
31
32 #!/bin/sh
33 sync
34 echo 1 > /sys/power/pm_trace
35 echo mem > /sys/power/state
36
37 to suspend
38
39 - if it doesn't come back up (which is usually the problem), reboot by
40 holding the power button down, and look at the dmesg output for things
41 like
42
43 Magic number: 4:156:725
44 hash matches drivers/base/power/resume.c:28
45 hash matches device 0000:01:00.0
46
47 which means that the last trace event was just before trying to resume
48 device 0000:01:00.0. Then figure out what driver is controlling that
49 device (lspci and /sys/devices/pci* is your friend), and see if you can
50 fix it, disable it, or trace into its resume function.
51
d33ac60b
JH
52 If no device matches the hash (or any matches appear to be false positives),
53 the culprit may be a device from a loadable kernel module that is not loaded
54 until after the hash is checked. You can check the hash against the current
55 devices again after more modules are loaded using sysfs:
56
57 cat /sys/power/pm_trace_dev_match
58
06df6a5c
PM
59For example, the above happens to be the VGA device on my EVO, which I
60used to run with "radeonfb" (it's an ATI Radeon mobility). It turns out
61that "radeonfb" simply cannot resume that device - it tries to set the
62PLL's, and it just _hangs_. Using the regular VGA console and letting X
63resume it instead works fine.
b25f29b0
FP
64
65NOTE
66====
67pm_trace uses the system's Real Time Clock (RTC) to save the magic number.
68Reason for this is that the RTC is the only reliably available piece of
69hardware during resume operations where a value can be set that will
70survive a reboot.
71
72Consequence is that after a resume (even if it is successful) your system
19f59460 73clock will have a value corresponding to the magic number instead of the
b25f29b0
FP
74correct date/time! It is therefore advisable to use a program like ntp-date
75or rdate to reset the correct date/time from an external time source when
76using this trace option.
77
78As the clock keeps ticking it is also essential that the reboot is done
79quickly after the resume failure. The trace option does not use the seconds
80or the low order bits of the minutes of the RTC, but a too long delay will
81corrupt the magic value.