|author||Pavel Machek <firstname.lastname@example.org>||2006-12-06 20:34:46 -0800|
|committer||Linus Torvalds <email@example.com>||2006-12-07 08:39:28 -0800|
[PATCH] s2ram debugging documentation
Linus posted quite nice TRACE_RESUME how-to, and I think it is too nice to be hidden in archives of mailing list, so I turned it into Documentation piece. Signed-off-by: Pavel Machek <firstname.lastname@example.org> Signed-off-by: Andrew Morton <email@example.com> Signed-off-by: Linus Torvalds <firstname.lastname@example.org>
Diffstat (limited to 'Documentation/power/s2ram.txt')
1 files changed, 56 insertions, 0 deletions
diff --git a/Documentation/power/s2ram.txt b/Documentation/power/s2ram.txt
new file mode 100644
@@ -0,0 +1,56 @@
+ 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.
+ 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:
+ 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
+ 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.
+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.