Lines Matching refs:the
6 To check if hibernation works, you can try to hibernate in the "reboot" mode:
11 and the system should create a hibernation image, reboot, resume and get back to
12 the command prompt where you have started the transition. If that happens,
13 hibernation is most likely to work correctly. Still, you need to repeat the
16 resuming the system.] Moreover, hibernating in the "reboot" and "shutdown"
17 modes causes the PM core to skip some platform-related callbacks which on ACPI
19 to hibernate or resume in the "reboot" mode, you should try the "platform" mode:
24 which is the default and recommended mode of hibernation.
26 Unfortunately, the "platform" mode of hibernation does not work on some systems
27 with broken BIOSes. In such cases the "shutdown" mode of hibernation might
33 (it is similar to the "reboot" mode, but it requires you to press the power
34 button to make the system resume).
42 facility available if the kernel is compiled with CONFIG_PM_DEBUG set. Then,
43 there is the file /sys/power/pm_test that can be used to make the hibernation
47 - test the freezing of processes
50 - test the freezing of processes and suspending of devices
53 - test the freezing of processes, suspending of devices and platform
57 - test the freezing of processes, suspending of devices, platform
58 global control methods(*) and the disabling of nonboot CPUs
61 - test the freezing of processes, suspending of devices, platform global
62 control methods(*), the disabling of nonboot CPUs and suspending of
65 (*) the platform global control methods are only available on ACPI systems
66 and are only tested if the hibernation mode is set to "platform"
68 To use one of them it is necessary to write the corresponding string to
69 /sys/power/pm_test (eg. "devices" to test the freezing of processes and
70 suspending devices) and issue the standard hibernation commands. For example,
71 to use the "devices" test mode along with the "platform" mode of hibernation,
72 you should do the following:
78 Then, the kernel will try to freeze processes, suspend devices, wait a few
79 seconds (5 by default, but configurable by the suspend.pm_test_delay module
81 /sys/power/pm_test , then after suspending devices the kernel will additionally
82 invoke the global control methods (eg. ACPI global control methods) used to
83 prepare the platform firmware for hibernation. Next, it will wait a
84 configurable number of seconds and invoke the platform (eg. ACPI) global
87 Writing "none" to /sys/power/pm_test causes the kernel to switch to the normal
90 represents the normal functionality) in which the current test level is
93 Generally, as you can see, each test level is more "invasive" than the previous
94 one and the "core" level tests the hardware and drivers as deeply as possible
95 without creating a hibernation image. Obviously, if the "devices" test fails,
96 the "platform" test will fail as well and so on. Thus, as a rule of thumb, you
97 should try the test modes starting from "freezer", through "devices", "platform"
98 and "processors" up to "core" (repeat the test on each level a couple of times
101 If the "freezer" test fails, there is a task that cannot be frozen (in that case
102 it usually is possible to identify the offending task by analysing the output of
103 dmesg obtained after the failing test). Failure at this level usually means
104 that there is a problem with the tasks freezer subsystem that should be
107 If the "devices" test fails, most likely there is a driver that cannot suspend
108 or resume its device (in the latter case the system may hang or become unstable
109 after the test, so please take that into consideration). To find this driver,
110 you can carry out a binary search according to the rules:
111 - if the test fails, unload a half of the drivers currently loaded and repeat
112 (that would probably involve rebooting the system, so always note what drivers
113 have been loaded before the test),
114 - if the test succeeds, load a half of the drivers you have unloaded most
117 Once you have found the failing driver (there can be more than just one of
119 make sure to report the problem with the driver.
121 It is also possible that the "devices" test will still fail after you have
123 configuration for the drivers that can be compiled as modules (and test again
127 If the "platform" test fails, there is a problem with the handling of the
128 platform (eg. ACPI) firmware on your system. In that case the "platform" mode
129 of hibernation is not likely to work. You can try the "shutdown" mode, but that
132 If the "processors" test fails, the disabling/enabling of nonboot CPUs does not
133 work (of course, this only may be an issue on SMP systems) and the problem
134 should be reported. In that case you can also try to switch the nonboot CPUs
135 off and on using the /sys/devices/system/cpu/cpu*/online sysfs attributes and
138 If the "core" test fails, which means that suspending of the system/platform
140 the problem is most probably hardware-related and serious, so it should be
143 A failure of any of the "platform", "processors" or "core" tests may cause your
145 indicates a serious problem that very well may be related to the hardware, but
150 If all of the hibernation test modes work, you can boot the system with the
151 "init=/bin/bash" command line parameter and attempt to hibernate in the
153 probably is a problem with a driver statically compiled into the kernel and you
156 find it by loading a half of the modules you normally use and binary searching
157 in accordance with the algorithm:
158 - if there are n modules loaded and the attempt to suspend and resume fails,
159 unload n/2 of the modules and try again (that would probably involve rebooting
160 the system),
161 - if there are n modules loaded and the attempt to suspend and resume succeeds,
164 Again, if you find the offending module(s), it(they) must be unloaded every time
165 before hibernation, and please report the problem with it(them).
169 In case that hibernation does not work on your system even in the minimal
171 modules cannot be unloaded, you can use one of the more advanced debugging
172 techniques to find the problem. First, if there is a serial port in your box,
173 you can boot the kernel with the 'no_console_suspend' parameter and try to log
174 kernel messages using the serial console. This may provide you with some
175 information about the reasons of the suspend (resume) failure. Alternatively,
178 use the PM_TRACE mechanism documented in Documentation/power/s2ram.txt .
182 To verify that the STR works, it is generally more convenient to use the s2ram
187 into /sys/power/pm_test (available if the kernel is compiled with
188 CONFIG_PM_DEBUG set) the suspend code will work in the test mode corresponding
189 to given string. The STR test modes are defined in the same way as for
191 particular, the "core" test allows you to test everything except for the actual
192 invocation of the platform firmware in order to put the system into the sleep
195 Among other things, the testing with the help of /sys/power/pm_test may allow
199 Next, you can follow the instructions at S2RAM_LINK to test the system, but if
200 it does not work "out of the box", you may need to boot it with
201 "init=/bin/bash" and test s2ram in the minimal configuration. In that case,
202 you may be able to search for failing drivers by following the procedure
203 analogous to the one described in section 1. If you find some failing drivers,
205 you run s2ram), and please report the problems with them.
207 There is a debugfs entry which shows the suspend to RAM statistics. Here is an
226 Field success means the success number of suspend to RAM, and field fail means
227 the failure number. Others are the failure number of different steps of suspend
228 to RAM. suspend_stats just lists the last 2 failed devices, error number and