8f4ce8c32f
Currently, there's a CONFIG_DISABLE_CONSOLE_SUSPEND that allows one to stop the serial console from being suspended when the rest of the machine goes to sleep. This is incredibly useful for debugging power management-related things; however, having it as a compile-time option has proved to be incredibly inconvenient for us (OLPC). There are plenty of times that we want serial console to not suspend, but for the most part we'd like serial console to be suspended. This drops CONFIG_DISABLE_CONSOLE_SUSPEND, and replaces it with a kernel boot parameter (no_console_suspend). By default, the serial console will be suspended along with the rest of the system; by passing 'no_console_suspend' to the kernel during boot, serial console will remain alive during suspend. For now, this is pretty serial console specific; further fixes could be applied to make this work for things like netconsole. Signed-off-by: Andres Salomon <dilinger@debian.org> Acked-by: "Rafael J. Wysocki" <rjw@sisk.pl> Acked-by: Pavel Machek <pavel@ucw.cz> Cc: Nigel Cunningham <nigel@suspend2.net> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
107 lines
5.1 KiB
Plaintext
107 lines
5.1 KiB
Plaintext
Debugging suspend and resume
|
|
(C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL
|
|
|
|
1. Testing suspend to disk (STD)
|
|
|
|
To verify that the STD works, you can try to suspend in the "reboot" mode:
|
|
|
|
# echo reboot > /sys/power/disk
|
|
# echo disk > /sys/power/state
|
|
|
|
and the system should suspend, reboot, resume and get back to the command prompt
|
|
where you have started the transition. If that happens, the STD is most likely
|
|
to work correctly, but you need to repeat the test at least a couple of times in
|
|
a row for confidence. This is necessary, because some problems only show up on
|
|
a second attempt at suspending and resuming the system. You should also test
|
|
the "platform" and "shutdown" modes of suspend:
|
|
|
|
# echo platform > /sys/power/disk
|
|
# echo disk > /sys/power/state
|
|
|
|
or
|
|
|
|
# echo shutdown > /sys/power/disk
|
|
# echo disk > /sys/power/state
|
|
|
|
in which cases you will have to press the power button to make the system
|
|
resume. If that does not work, you will need to identify what goes wrong.
|
|
|
|
a) Test mode of STD
|
|
|
|
To verify if there are any drivers that cause problems you can run the STD
|
|
in the test mode:
|
|
|
|
# echo test > /sys/power/disk
|
|
# echo disk > /sys/power/state
|
|
|
|
in which case the system should freeze tasks, suspend devices, disable nonboot
|
|
CPUs (if any), wait for 5 seconds, enable nonboot CPUs, resume devices, thaw
|
|
tasks and return to your command prompt. If that fails, most likely there is
|
|
a driver that fails to either suspend or resume (in the latter case the system
|
|
may hang or be unstable after the test, so please take that into consideration).
|
|
To find this driver, you can carry out a binary search according to the rules:
|
|
- if the test fails, unload a half of the drivers currently loaded and repeat
|
|
(that would probably involve rebooting the system, so always note what drivers
|
|
have been loaded before the test),
|
|
- if the test succeeds, load a half of the drivers you have unloaded most
|
|
recently and repeat.
|
|
|
|
Once you have found the failing driver (there can be more than just one of
|
|
them), you have to unload it every time before the STD transition. In that case
|
|
please make sure to report the problem with the driver.
|
|
|
|
It is also possible that a cycle can still fail after you have unloaded
|
|
all modules. In that case, you would want to look in your kernel configuration
|
|
for the drivers that can be compiled as modules (testing again with them as
|
|
modules), and possibly also try boot time options such as "noapic" or "noacpi".
|
|
|
|
b) Testing minimal configuration
|
|
|
|
If the test mode of STD works, you can boot the system with "init=/bin/bash"
|
|
and attempt to suspend in the "reboot", "shutdown" and "platform" modes. If
|
|
that does not work, there probably is a problem with a driver statically
|
|
compiled into the kernel and you can try to compile more drivers as modules,
|
|
so that they can be tested individually. Otherwise, there is a problem with a
|
|
modular driver and you can find it by loading a half of the modules you normally
|
|
use and binary searching in accordance with the algorithm:
|
|
- if there are n modules loaded and the attempt to suspend and resume fails,
|
|
unload n/2 of the modules and try again (that would probably involve rebooting
|
|
the system),
|
|
- if there are n modules loaded and the attempt to suspend and resume succeeds,
|
|
load n/2 modules more and try again.
|
|
|
|
Again, if you find the offending module(s), it(they) must be unloaded every time
|
|
before the STD transition, and please report the problem with it(them).
|
|
|
|
c) Advanced debugging
|
|
|
|
In case the STD does not work on your system even in the minimal configuration
|
|
and compiling more drivers as modules is not practical or some modules cannot
|
|
be unloaded, you can use one of the more advanced debugging techniques to find
|
|
the problem. First, if there is a serial port in your box, you can boot the
|
|
kernel with the 'no_console_suspend' parameter and try to log kernel
|
|
messages using the serial console. This may provide you with some information
|
|
about the reasons of the suspend (resume) failure. Alternatively, it may be
|
|
possible to use a FireWire port for debugging with firescope
|
|
(ftp://ftp.firstfloor.org/pub/ak/firescope/). On i386 it is also possible to
|
|
use the PM_TRACE mechanism documented in Documentation/s2ram.txt .
|
|
|
|
2. Testing suspend to RAM (STR)
|
|
|
|
To verify that the STR works, it is generally more convenient to use the s2ram
|
|
tool available from http://suspend.sf.net and documented at
|
|
http://en.opensuse.org/s2ram . However, before doing that it is recommended to
|
|
carry out the procedure described in section 1.
|
|
|
|
Assume you have resolved the problems with the STD and you have found some
|
|
failing drivers. These drivers are also likely to fail during the STR or
|
|
during the resume, so it is better to unload them every time before the STR
|
|
transition. Now, you can follow the instructions at
|
|
http://en.opensuse.org/s2ram to test the system, but if it does not work
|
|
"out of the box", you may need to boot it with "init=/bin/bash" and test
|
|
s2ram in the minimal configuration. In that case, you may be able to search
|
|
for failing drivers by following the procedure analogous to the one described in
|
|
1b). If you find some failing drivers, you will have to unload them every time
|
|
before the STR transition (ie. before you run s2ram), and please report the
|
|
problems with them.
|