s2ram debugging documentation

[Pavel Machek <pavel@ucw.cz>]

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 <pavel@suse.cz>

Add linus' how-to-get s2ram to work.

---
commit 10ef1d7d246e5d041eeb076f045dd21167311324
tree a5deed96319360e4e1f4982d4a6574f23a4dfe23
parent b6be65f0eb2ba9a7d2c8cef7a7af9ae481fe3ec9
author Pavel <pavel@amd.ucw.cz> Fri, 24 Nov 2006 09:57:12 +0100
committer Pavel <pavel@amd.ucw.cz> Fri, 24 Nov 2006 09:57:12 +0100

 Documentation/power/s2ram.txt |   56 +++++++++++++++++++++++++++++++++++++++++
 1 files changed, 56 insertions(+), 0 deletions(-)

diff --git a/Documentation/power/s2ram.txt b/Documentation/power/s2ram.txt
new file mode 100644
index 0000000..50dce18
--- /dev/null
+++ b/Documentation/power/s2ram.txt
@@ -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:
+
+	#!/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.
+
+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.


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/