| Pavel Machek | 06df6a5 | 2006-12-06 20:34:46 -0800 | [diff] [blame] | 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. |