Eric Lee / linux-smarc-t335x-v3.2

Commit 06df6a5c181f462c71ddcc20ff6c7ea0bec18ec8

Authored by Pavel Machek 2006-12-07 12:34:46 +0800

Committed by Linus Torvalds 2006-12-08 00:39:28 +0800

Exists in master and in 4 other branches

[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 <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Showing 1 changed file with 56 additions and 0 deletions Side-by-side Diff

Documentation/power/s2ram.txt

Documentation/power/s2ram.txt

Diff comments View file @ 06df6a5

	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.