Lines Matching +full:suspend +full:- +full:to +full:- +full:ram
2 Debugging hibernation and suspend
7 1. Testing hibernation (aka suspend to disk or STD)
10 To check if hibernation works, you can try to hibernate in the "reboot" mode::
15 and the system should create a hibernation image, reboot, resume and get back to
17 hibernation is most likely to work correctly. Still, you need to repeat the
21 modes causes the PM core to skip some platform-related callbacks which on ACPI
22 systems might be necessary to make hibernation work. Thus, if your machine
23 fails to hibernate or resume in the "reboot" mode, you should try the
38 (it is similar to the "reboot" mode, but it requires you to press the power
39 button to make the system resume).
41 If neither "platform" nor "shutdown" hibernation mode works, you will need to
45 ----------------------------
47 To find out why hibernation fails on your system, you can use a special testing
49 there is the file /sys/power/pm_test that can be used to make the hibernation
53 - test the freezing of processes
56 - test the freezing of processes and suspending of devices
59 - test the freezing of processes, suspending of devices and platform
63 - test the freezing of processes, suspending of devices, platform
67 - test the freezing of processes, suspending of devices, platform global
74 and are only tested if the hibernation mode is set to "platform"
76 To use one of them it is necessary to write the corresponding string to
77 /sys/power/pm_test (eg. "devices" to test the freezing of processes and
79 to use the "devices" test mode along with the "platform" mode of hibernation,
86 Then, the kernel will try to freeze processes, suspend devices, wait a few
87 seconds (5 by default, but configurable by the suspend.pm_test_delay module
88 parameter), resume devices and thaw processes. If "platform" is written to
90 invoke the global control methods (eg. ACPI global control methods) used to
93 methods used to cancel hibernation etc.
95 Writing "none" to /sys/power/pm_test causes the kernel to switch to the normal
96 hibernation/suspend operations. Also, when open for reading, /sys/power/pm_test
97 contains a space-separated list of all available tests (including "none" that
106 and "processors" up to "core" (repeat the test on each level a couple of times
107 to make sure that any random factors are avoided).
110 it usually is possible to identify the offending task by analysing the output of
115 If the "devices" test fails, most likely there is a driver that cannot suspend
117 after the test, so please take that into consideration). To find this driver,
118 you can carry out a binary search according to the rules:
120 - if the test fails, unload a half of the drivers currently loaded and repeat
123 - if the test succeeds, load a half of the drivers you have unloaded most
127 them), you have to unload it every time before hibernation. In that case please
128 make sure to report the problem with the driver.
131 unloaded all modules. In that case, you may want to look in your kernel
133 with these drivers compiled as modules). You may also try to use some special
138 of hibernation is not likely to work. You can try the "shutdown" mode, but that
143 should be reported. In that case you can also try to switch the nonboot CPUs
149 the problem is most probably hardware-related and serious, so it should be
153 system to hang or become unstable, so please beware. Such a failure usually
154 indicates a serious problem that very well may be related to the hardware, but
158 --------------------------------
161 "init=/bin/bash" command line parameter and attempt to hibernate in the
164 can try to compile more drivers as modules, so that they can be tested
168 - if there are n modules loaded and the attempt to suspend and resume fails,
171 - if there are n modules loaded and the attempt to suspend and resume succeeds,
178 ---------------------------------------------
180 /sys/power/disk generally tells the kernel what to do after creating a
182 causes the just created image to be used for immediate restoration. Namely,
191 That test can be used to check if failures to resume from hibernation are
192 related to bad interactions with the platform firmware. That is, if the above
196 On architectures and platforms that support using different kernels to restore
197 hibernation images (that is, the kernel used to read the image from storage and
199 kernel address space randomization, it also can be used to check if failures
200 to resume may be related to the differences between the restore and image
204 ---------------------
209 techniques to find the problem. First, if there is a serial port in your box,
210 you can boot the kernel with the 'no_console_suspend' parameter and try to log
212 information about the reasons of the suspend (resume) failure. Alternatively,
213 it may be possible to use a FireWire port for debugging with firescope
214 (http://v3.sk/~lkundrak/firescope/). On x86 it is also possible to
217 2. Testing suspend to RAM (STR)
220 To verify that the STR works, it is generally more convenient to use the s2ram
221 tool available from http://suspend.sf.net and documented at
226 CONFIG_PM_DEBUG set) the suspend code will work in the test mode corresponding
227 to given string. The STR test modes are defined in the same way as for
228 hibernation, so please refer to Section 1 for more information about them. In
229 particular, the "core" test allows you to test everything except for the actual
230 invocation of the platform firmware in order to put the system into the sleep
234 you to identify drivers that fail to suspend or resume their devices. They
237 Next, you can follow the instructions at S2RAM_LINK to test the system, but if
238 it does not work "out of the box", you may need to boot it with
240 you may be able to search for failing drivers by following the procedure
241 analogous to the one described in section 1. If you find some failing drivers,
242 you will have to unload them every time before an STR transition (ie. before
245 There is a debugfs entry which shows the suspend to RAM statistics. Here is an
248 # mount -t debugfs none /sys/kernel/debug
261 last_failed_errno: -16
262 -16
263 last_failed_step: suspend
264 suspend
266 Field success means the success number of suspend to RAM, and field fail means
267 the failure number. Others are the failure number of different steps of suspend
268 to RAM. suspend_stats just lists the last 2 failed devices, error number and
269 failed step of suspend.