Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 06df6a5c authored by Pavel Machek's avatar Pavel Machek Committed by Linus Torvalds
Browse files

[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: default avatarPavel Machek <pavel@suse.cz>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
parent 59a49335

Documentation/power/s2ram.txt

0 → 100644
+56 −0
Original line number Original line Diff line number Diff line 
			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.