|  | 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. |