88 lines · plain
1========================2How to get s2ram working3========================4 52006 Linus Torvalds62006 Pavel Machek7 81) Check suspend.sf.net, program s2ram there has long whitelist of9 "known ok" machines, along with tricks to use on each one.10 112) If that does not help, try reading tricks.txt and12 video.txt. Perhaps problem is as simple as broken module, and13 simple module unload can fix it.14 153) You can use Linus' TRACE_RESUME infrastructure, described below.16 17Using TRACE_RESUME18~~~~~~~~~~~~~~~~~~19 20I've been working at making the machines I have able to STR, and almost21always it's a driver that is buggy. Thank God for the suspend/resume22debugging - the thing that Chuck tried to disable. That's often the _only_23way to debug these things, and it's actually pretty powerful (but24time-consuming - having to insert TRACE_RESUME() markers into the device25driver that doesn't resume and recompile and reboot).26 27Anyway, the way to debug this for people who are interested (have a28machine that doesn't boot) is:29 30 - enable PM_DEBUG, and PM_TRACE31 32 - use a script like this::33 34 #!/bin/sh35 sync36 echo 1 > /sys/power/pm_trace37 echo mem > /sys/power/state38 39 to suspend40 41 - if it doesn't come back up (which is usually the problem), reboot by42 holding the power button down, and look at the dmesg output for things43 like::44 45 Magic number: 4:156:72546 hash matches drivers/base/power/resume.c:2847 hash matches device 0000:01:00.048 49 which means that the last trace event was just before trying to resume50 device 0000:01:00.0. Then figure out what driver is controlling that51 device (lspci and /sys/devices/pci* is your friend), and see if you can52 fix it, disable it, or trace into its resume function.53 54 If no device matches the hash (or any matches appear to be false positives),55 the culprit may be a device from a loadable kernel module that is not loaded56 until after the hash is checked. You can check the hash against the current57 devices again after more modules are loaded using sysfs::58 59 cat /sys/power/pm_trace_dev_match60 61For example, the above happens to be the VGA device on my EVO, which I62used to run with "radeonfb" (it's an ATI Radeon mobility). It turns out63that "radeonfb" simply cannot resume that device - it tries to set the64PLL's, and it just _hangs_. Using the regular VGA console and letting X65resume it instead works fine.66 67NOTE68====69pm_trace uses the system's Real Time Clock (RTC) to save the magic number.70Reason for this is that the RTC is the only reliably available piece of71hardware during resume operations where a value can be set that will72survive a reboot.73 74pm_trace is not compatible with asynchronous suspend, so it turns75asynchronous suspend off (which may work around timing or76ordering-sensitive bugs).77 78Consequence is that after a resume (even if it is successful) your system79clock will have a value corresponding to the magic number instead of the80correct date/time! It is therefore advisable to use a program like ntp-date81or rdate to reset the correct date/time from an external time source when82using this trace option.83 84As the clock keeps ticking it is also essential that the reboot is done85quickly after the resume failure. The trace option does not use the seconds86or the low order bits of the minutes of the RTC, but a too long delay will87corrupt the magic value.88