1 ======================== 2 How to get s2ram working 3 ======================== 4 5 2006 Linus Torvalds 6 2006 Pavel Machek 7 8 1) Check suspend.sf.net, program s2ram there has long whitelist of 9 "known ok" machines, along with tricks to use on each one. 10 11 2) If that does not help, try reading tricks.txt and 12 video.txt. Perhaps problem is as simple as broken module, and 13 simple module unload can fix it. 14 15 3) You can use Linus' TRACE_RESUME infrastructure, described below. 16 17 Using TRACE_RESUME 18 ~~~~~~~~~~~~~~~~~~ 19 20 I've been working at making the machines I have able to STR, and almost 21 always it's a driver that is buggy. Thank God for the suspend/resume 22 debugging - the thing that Chuck tried to disable. That's often the _only_ 23 way to debug these things, and it's actually pretty powerful (but 24 time-consuming - having to insert TRACE_RESUME() markers into the device 25 driver that doesn't resume and recompile and reboot). 26 27 Anyway, the way to debug this for people who are interested (have a 28 machine that doesn't boot) is: 29 30 - enable PM_DEBUG, and PM_TRACE 31 32 - use a script like this:: 33 34 #!/bin/sh 35 sync 36 echo 1 > /sys/power/pm_trace 37 echo mem > /sys/power/state 38 39 to suspend 40 41 - if it doesn't come back up (which is usually the problem), reboot by 42 holding the power button down, and look at the dmesg output for things 43 like:: 44 45 Magic number: 4:156:725 46 hash matches drivers/base/power/resume.c:28 47 hash matches device 0000:01:00.0 48 49 which means that the last trace event was just before trying to resume 50 device 0000:01:00.0. Then figure out what driver is controlling that 51 device (lspci and /sys/devices/pci* is your friend), and see if you can 52 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 loaded 56 until after the hash is checked. You can check the hash against the current 57 devices again after more modules are loaded using sysfs:: 58 59 cat /sys/power/pm_trace_dev_match 60 61 For example, the above happens to be the VGA device on my EVO, which I 62 used to run with "radeonfb" (it's an ATI Radeon mobility). It turns out 63 that "radeonfb" simply cannot resume that device - it tries to set the 64 PLL's, and it just _hangs_. Using the regular VGA console and letting X 65 resume it instead works fine. 66 67 NOTE 68 ==== 69 pm_trace uses the system's Real Time Clock (RTC) to save the magic number. 70 Reason for this is that the RTC is the only reliably available piece of 71 hardware during resume operations where a value can be set that will 72 survive a reboot. 73 74 pm_trace is not compatible with asynchronous suspend, so it turns 75 asynchronous suspend off (which may work around timing or 76 ordering-sensitive bugs). 77 78 Consequence is that after a resume (even if it is successful) your system 79 clock will have a value corresponding to the magic number instead of the 80 correct date/time! It is therefore advisable to use a program like ntp-date 81 or rdate to reset the correct date/time from an external time source when 82 using this trace option. 83 84 As the clock keeps ticking it is also essential that the reboot is done 85 quickly after the resume failure. The trace option does not use the seconds 86 or the low order bits of the minutes of the RTC, but a too long delay will 87 corrupt the magic value.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.