Root/
1 | How to get s2ram working |
2 | ~~~~~~~~~~~~~~~~~~~~~~~~ |
3 | 2006 Linus Torvalds |
4 | 2006 Pavel Machek |
5 | |
6 | 1) Check suspend.sf.net, program s2ram there has long whitelist of |
7 | "known ok" machines, along with tricks to use on each one. |
8 | |
9 | 2) 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 | |
13 | 3) You can use Linus' TRACE_RESUME infrastructure, described below. |
14 | |
15 | Using TRACE_RESUME |
16 | ~~~~~~~~~~~~~~~~~~ |
17 | |
18 | I've been working at making the machines I have able to STR, and almost |
19 | always it's a driver that is buggy. Thank God for the suspend/resume |
20 | debugging - the thing that Chuck tried to disable. That's often the _only_ |
21 | way to debug these things, and it's actually pretty powerful (but |
22 | time-consuming - having to insert TRACE_RESUME() markers into the device |
23 | driver that doesn't resume and recompile and reboot). |
24 | |
25 | Anyway, the way to debug this for people who are interested (have a |
26 | machine 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 | |
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 | |
59 | For example, the above happens to be the VGA device on my EVO, which I |
60 | used to run with "radeonfb" (it's an ATI Radeon mobility). It turns out |
61 | that "radeonfb" simply cannot resume that device - it tries to set the |
62 | PLL's, and it just _hangs_. Using the regular VGA console and letting X |
63 | resume it instead works fine. |
64 | |
65 | NOTE |
66 | ==== |
67 | pm_trace uses the system's Real Time Clock (RTC) to save the magic number. |
68 | Reason for this is that the RTC is the only reliably available piece of |
69 | hardware during resume operations where a value can be set that will |
70 | survive a reboot. |
71 | |
72 | Consequence is that after a resume (even if it is successful) your system |
73 | clock will have a value corresponding to the magic number instead of the |
74 | correct date/time! It is therefore advisable to use a program like ntp-date |
75 | or rdate to reset the correct date/time from an external time source when |
76 | using this trace option. |
77 | |
78 | As the clock keeps ticking it is also essential that the reboot is done |
79 | quickly after the resume failure. The trace option does not use the seconds |
80 | or the low order bits of the minutes of the RTC, but a too long delay will |
81 | corrupt the magic value. |
82 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9