1================================= 2Debugging hibernation and suspend 3================================= 4 5 (C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL 6 71. Testing hibernation (aka suspend to disk or STD) 8=================================================== 9 10To check if hibernation works, you can try to hibernate in the "reboot" mode:: 11 12 # echo reboot > /sys/power/disk 13 # echo disk > /sys/power/state 14 15and the system should create a hibernation image, reboot, resume and get back to 16the command prompt where you have started the transition. If that happens, 17hibernation is most likely to work correctly. Still, you need to repeat the 18test at least a couple of times in a row for confidence. [This is necessary, 19because some problems only show up on a second attempt at suspending and 20resuming the system.] Moreover, hibernating in the "reboot" and "shutdown" 21modes causes the PM core to skip some platform-related callbacks which on ACPI 22systems might be necessary to make hibernation work. Thus, if your machine 23fails to hibernate or resume in the "reboot" mode, you should try the 24"platform" mode:: 25 26 # echo platform > /sys/power/disk 27 # echo disk > /sys/power/state 28 29which is the default and recommended mode of hibernation. 30 31Unfortunately, the "platform" mode of hibernation does not work on some systems 32with broken BIOSes. In such cases the "shutdown" mode of hibernation might 33work:: 34 35 # echo shutdown > /sys/power/disk 36 # echo disk > /sys/power/state 37 38(it is similar to the "reboot" mode, but it requires you to press the power 39button to make the system resume). 40 41If neither "platform" nor "shutdown" hibernation mode works, you will need to 42identify what goes wrong. 43 44a) Test modes of hibernation 45---------------------------- 46 47To find out why hibernation fails on your system, you can use a special testing 48facility available if the kernel is compiled with CONFIG_PM_DEBUG set. Then, 49there is the file /sys/power/pm_test that can be used to make the hibernation 50core run in a test mode. There are 5 test modes available: 51 52freezer 53 - test the freezing of processes 54 55devices 56 - test the freezing of processes and suspending of devices 57 58platform 59 - test the freezing of processes, suspending of devices and platform 60 global control methods [1]_ 61 62processors 63 - test the freezing of processes, suspending of devices, platform 64 global control methods [1]_ and the disabling of nonboot CPUs 65 66core 67 - test the freezing of processes, suspending of devices, platform global 68 control methods\ [1]_, the disabling of nonboot CPUs and suspending 69 of platform/system devices 70 71.. [1] 72 73 the platform global control methods are only available on ACPI systems 74 and are only tested if the hibernation mode is set to "platform" 75 76To 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 78suspending devices) and issue the standard hibernation commands. For example, 79to use the "devices" test mode along with the "platform" mode of hibernation, 80you should do the following:: 81 82 # echo devices > /sys/power/pm_test 83 # echo platform > /sys/power/disk 84 # echo disk > /sys/power/state 85 86Then, the kernel will try to freeze processes, suspend devices, wait a few 87seconds (5 by default, but configurable by the suspend.pm_test_delay module 88parameter), resume devices and thaw processes. If "platform" is written to 89/sys/power/pm_test , then after suspending devices the kernel will additionally 90invoke the global control methods (eg. ACPI global control methods) used to 91prepare the platform firmware for hibernation. Next, it will wait a 92configurable number of seconds and invoke the platform (eg. ACPI) global 93methods used to cancel hibernation etc. 94 95Writing "none" to /sys/power/pm_test causes the kernel to switch to the normal 96hibernation/suspend operations. Also, when open for reading, /sys/power/pm_test 97contains a space-separated list of all available tests (including "none" that 98represents the normal functionality) in which the current test level is 99indicated by square brackets. 100 101Generally, as you can see, each test level is more "invasive" than the previous 102one and the "core" level tests the hardware and drivers as deeply as possible 103without creating a hibernation image. Obviously, if the "devices" test fails, 104the "platform" test will fail as well and so on. Thus, as a rule of thumb, you 105should try the test modes starting from "freezer", through "devices", "platform" 106and "processors" up to "core" (repeat the test on each level a couple of times 107to make sure that any random factors are avoided). 108 109If the "freezer" test fails, there is a task that cannot be frozen (in that case 110it usually is possible to identify the offending task by analysing the output of 111dmesg obtained after the failing test). Failure at this level usually means 112that there is a problem with the tasks freezer subsystem that should be 113reported. 114 115If the "devices" test fails, most likely there is a driver that cannot suspend 116or resume its device (in the latter case the system may hang or become unstable 117after the test, so please take that into consideration). To find this driver, 118you can carry out a binary search according to the rules: 119 120- if the test fails, unload a half of the drivers currently loaded and repeat 121 (that would probably involve rebooting the system, so always note what drivers 122 have been loaded before the test), 123- if the test succeeds, load a half of the drivers you have unloaded most 124 recently and repeat. 125 126Once you have found the failing driver (there can be more than just one of 127them), you have to unload it every time before hibernation. In that case please 128make sure to report the problem with the driver. 129 130It is also possible that the "devices" test will still fail after you have 131unloaded all modules. In that case, you may want to look in your kernel 132configuration for the drivers that can be compiled as modules (and test again 133with these drivers compiled as modules). You may also try to use some special 134kernel command line options such as "noapic", "noacpi" or even "acpi=off". 135 136If the "platform" test fails, there is a problem with the handling of the 137platform (eg. ACPI) firmware on your system. In that case the "platform" mode 138of hibernation is not likely to work. You can try the "shutdown" mode, but that 139is rather a poor man's workaround. 140 141If the "processors" test fails, the disabling/enabling of nonboot CPUs does not 142work (of course, this only may be an issue on SMP systems) and the problem 143should be reported. In that case you can also try to switch the nonboot CPUs 144off and on using the /sys/devices/system/cpu/cpu*/online sysfs attributes and 145see if that works. 146 147If the "core" test fails, which means that suspending of the system/platform 148devices has failed (these devices are suspended on one CPU with interrupts off), 149the problem is most probably hardware-related and serious, so it should be 150reported. 151 152A failure of any of the "platform", "processors" or "core" tests may cause your 153system to hang or become unstable, so please beware. Such a failure usually 154indicates a serious problem that very well may be related to the hardware, but 155please report it anyway. 156 157b) Testing minimal configuration 158-------------------------------- 159 160If all of the hibernation test modes work, you can boot the system with the 161"init=/bin/bash" command line parameter and attempt to hibernate in the 162"reboot", "shutdown" and "platform" modes. If that does not work, there 163probably is a problem with a driver statically compiled into the kernel and you 164can try to compile more drivers as modules, so that they can be tested 165individually. Otherwise, there is a problem with a modular driver and you can 166find it by loading a half of the modules you normally use and binary searching 167in accordance with the algorithm: 168- if there are n modules loaded and the attempt to suspend and resume fails, 169unload n/2 of the modules and try again (that would probably involve rebooting 170the system), 171- if there are n modules loaded and the attempt to suspend and resume succeeds, 172load n/2 modules more and try again. 173 174Again, if you find the offending module(s), it(they) must be unloaded every time 175before hibernation, and please report the problem with it(them). 176 177c) Using the "test_resume" hibernation option 178--------------------------------------------- 179 180/sys/power/disk generally tells the kernel what to do after creating a 181hibernation image. One of the available options is "test_resume" which 182causes the just created image to be used for immediate restoration. Namely, 183after doing:: 184 185 # echo test_resume > /sys/power/disk 186 # echo disk > /sys/power/state 187 188a hibernation image will be created and a resume from it will be triggered 189immediately without involving the platform firmware in any way. 190 191That test can be used to check if failures to resume from hibernation are 192related to bad interactions with the platform firmware. That is, if the above 193works every time, but resume from actual hibernation does not work or is 194unreliable, the platform firmware may be responsible for the failures. 195 196On architectures and platforms that support using different kernels to restore 197hibernation images (that is, the kernel used to read the image from storage and 198load it into memory is different from the one included in the image) or support 199kernel address space randomization, it also can be used to check if failures 200to resume may be related to the differences between the restore and image 201kernels. 202 203d) Advanced debugging 204--------------------- 205 206In case that hibernation does not work on your system even in the minimal 207configuration and compiling more drivers as modules is not practical or some 208modules cannot be unloaded, you can use one of the more advanced debugging 209techniques to find the problem. First, if there is a serial port in your box, 210you can boot the kernel with the 'no_console_suspend' parameter and try to log 211kernel messages using the serial console. This may provide you with some 212information about the reasons of the suspend (resume) failure. Alternatively, 213it 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 215use the PM_TRACE mechanism documented in Documentation/power/s2ram.rst . 216 2172. Testing suspend to RAM (STR) 218=============================== 219 220To verify that the STR works, it is generally more convenient to use the s2ram 221tool available from http://suspend.sf.net and documented at 222http://en.opensuse.org/SDB:Suspend_to_RAM (S2RAM_LINK). 223 224Namely, after writing "freezer", "devices", "platform", "processors", or "core" 225into /sys/power/pm_test (available if the kernel is compiled with 226CONFIG_PM_DEBUG set) the suspend code will work in the test mode corresponding 227to given string. The STR test modes are defined in the same way as for 228hibernation, so please refer to Section 1 for more information about them. In 229particular, the "core" test allows you to test everything except for the actual 230invocation of the platform firmware in order to put the system into the sleep 231state. 232 233Among other things, the testing with the help of /sys/power/pm_test may allow 234you to identify drivers that fail to suspend or resume their devices. They 235should be unloaded every time before an STR transition. 236 237Next, you can follow the instructions at S2RAM_LINK to test the system, but if 238it does not work "out of the box", you may need to boot it with 239"init=/bin/bash" and test s2ram in the minimal configuration. In that case, 240you may be able to search for failing drivers by following the procedure 241analogous to the one described in section 1. If you find some failing drivers, 242you will have to unload them every time before an STR transition (ie. before 243you run s2ram), and please report the problems with them. 244 245There is a debugfs entry which shows the suspend to RAM statistics. Here is an 246example of its output:: 247 248 # mount -t debugfs none /sys/kernel/debug 249 # cat /sys/kernel/debug/suspend_stats 250 success: 20 251 fail: 5 252 failed_freeze: 0 253 failed_prepare: 0 254 failed_suspend: 5 255 failed_suspend_noirq: 0 256 failed_resume: 0 257 failed_resume_noirq: 0 258 failures: 259 last_failed_dev: alarm 260 adc 261 last_failed_errno: -16 262 -16 263 last_failed_step: suspend 264 suspend 265 266Field success means the success number of suspend to RAM, and field fail means 267the failure number. Others are the failure number of different steps of suspend 268to RAM. suspend_stats just lists the last 2 failed devices, error number and 269failed step of suspend. 270