[lkml]   [2006]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Patch in this message
    Subjects2ram 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 <>

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

    commit 10ef1d7d246e5d041eeb076f045dd21167311324
    tree a5deed96319360e4e1f4982d4a6574f23a4dfe23
    parent b6be65f0eb2ba9a7d2c8cef7a7af9ae481fe3ec9
    author Pavel <> Fri, 24 Nov 2006 09:57:12 +0100
    committer Pavel <> 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, 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.

    (cesky, pictures)
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-11-24 10:01    [W:0.023 / U:85.800 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site