Commit | Line | Data |
---|---|---|
06df6a5c PM |
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 | For example, the above happens to be the VGA device on my EVO, which I | |
53 | used to run with "radeonfb" (it's an ATI Radeon mobility). It turns out | |
54 | that "radeonfb" simply cannot resume that device - it tries to set the | |
55 | PLL's, and it just _hangs_. Using the regular VGA console and letting X | |
56 | resume it instead works fine. |