s2ram.txt

  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.
 57 
 58 NOTE
 59 ====
 60 pm_trace uses the system's Real Time Clock (RTC) to save the magic number.
 61 Reason for this is that the RTC is the only reliably available piece of
 62 hardware during resume operations where a value can be set that will
 63 survive a reboot.
 64 
 65 Consequence is that after a resume (even if it is successful) your system
 66 clock will have a value corresponding to the magic number instead of the
 67 correct date/time! It is therefore advisable to use a program like ntp-date
 68 or rdate to reset the correct date/time from an external time source when
 69 using this trace option.
 70 
 71 As the clock keeps ticking it is also essential that the reboot is done
 72 quickly after the resume failure. The trace option does not use the seconds
 73 or the low order bits of the minutes of the RTC, but a too long delay will
 74 corrupt the magic value.
This page was automatically generated by LXR 0.3.1. • Linux is a registered trademark of Linus Torvalds
Linux Cross Reference

Free Electrons

Embedded Linux Experts

Linux/Documentation/power/s2ram.txt
