Re: Hibernation
Hello,
I have been trying to get hibernation mode working on several
different laptops of different brands (IBM, Toshiba), and unfortunately
there is (apparently) no way to have it work under linux. I expect some
messy APM BIOS hook into m$-win, for which I have (yet) not found any
documentation/specification. Moreover, I have been asking some IBM people
who told be that the hibernation file must be located on a DOS partition,
and that it cannot be recognized (I am not sure of it, the explanation
was very inaccurate) when not running DOS.
Although this last fact is quite IBM-specific (for Toshiba's I
have only seen dedicated partitions on the disk for the hibernation
space), I suspect that the APM BIOS is quite stuck when the Linux kernel
is loaded and running.
For short, the built-in "hibernation mode" in our laptops is, in many
cases, quite unuseable with Linux. (Any success with other models/brands
would be appreciated, I'd really like to know if there are any)
However, Tobias Bachmor <bachmor@cs.concordia.ca> reported the
existence of a "hibernation feature" for the kernel. I am using this
feature daily, and it works quite well. Explanations on it follow.
For any people that actually rely on the use of an "hibernation mode",
this kernel feature does a good job and can, in most cases, replace nearly
completely the built-in feature of the laptop. See also below for the
present bugs and caveats.
Raph
--
The Software Suspend (swsusp) extension to 2.2.x and 2.3.x kernels:
Its homepage can be found (again) at:
http://falcon.sch.bme.hu/~seasons/linux/swsusp.html
It is mainly a kernel patch which provides the feature of storing
the whole state of the system on swap space before halting the machine, so
that it can be resumed to its previous state on the next boot.
Its main advantage is that it only uses very high-level functions
of the kernel to handle the suspend/restore cycle. Therefore, it is rather
simple, thus short and fast, and doesn't require the hassle of hacking the
whole kernel source each time the kernel is patched to a new
version. Moreover, it is designed to work on most hardware, and thus is
not restricted to laptops (and work is undergoing to make it work even on
other platforms than the ibm/pc).
Its main drawback is that for hardware that can't survive a
power cycle without re-initialization, the system may be very unpleased
upon resume.
How it works:
When the system is running, the user can trigger the suspend by, either:
* use the keyboard shortcut Alt+SysRq+S, when the "Kernel magic
SysRq key" feature is activated,
* issue a "shutdown -s now" command, available with a patched SysVinit,
that will trigger the suspend after running some scripts,
* issue a "apm -s" command, or trigger the "system suspend" APM event
(i.e. invoking the hibernation mode key for most laptops), which the
suspend driver will understand as a trigger.
When the suspend is triggered, the kernel stops (i.e. sends a standard
SIGSTOP) all tasks, does some hardware cleaning, dumps the physical
memory and some control data to swap space, and then powers off the
computer.
Then, upon the next system startup, when the init scripts activate
swapping, the swsusp driver recognizes the swap space and starts
resuming: it loads back the physical memory, tries to do some hardware
cleaning, and then restarts all tasks (i.e. sends a SIGCONT to them).
It is rather simple, but works for most configurations. I have
used it on several desktop systems since kernel 2.2.9, and it seems quite
robust. Some problems sometimes happen, but all of them are related to the
hardware re-activation on resume (i.e. the suspend will nearly always
succeed, but sometimes the resume won't be possible).
What works well:
* resuming a hardware that do not depend on post-init initialisation. This
includes:
- Standard graphics output. Most video adapters are ready to restore
graphics when the kernel enters userspace. And because swsusp switches
consoles before and after the suspend/resume cycle, whenever the code
handling the graphics output handles the console switch, its state is
properly restored. This includes (tested):
+ many (probably nearly all) XFree86 servers,
+ svgalib (for most programs),
+ dosemu console graphics (although not properly checked),
+ vmware display (not tested by me),
+ fancy console textmodes, as long as the special textmode is
entered at startup *before* the swap space is recognized (guess
why)
+ console framebuffer, as long as the same graphics mode is
initialized before suspend and just before resume (tested, works
with vg16, svga and matrox graphics)
This should *not* (although not tested) include:
+ cases where the textmode/framebuffer mode at resume is
different from the one set before suspend. In most cases, it
will leave your console unuseable, and in some can completely
lock it.
+ 3Dfx or other such fancy graphics output devices that need, for
any image restoring, to be initialized in a complex way that
cannot be achieved by the kernel before the resume. I haven't
tested this, but I also expect that a resume attempt can lead to
strange system states with these devices.
- Standard hardware devices/controllers well-handled by the kernel,
as soon as the hardware configuration doesn't change between suspend and
resume (i.e. I/O ports, IRQ line or memory allocated for devices, and most
definately the devices' presence). This includes:
+ Standard IBM/PC/AT IDE/MCA/XT hard disk and floppy controllers,
serial UARTS (including those found on well-behaved internal modems) and
parallel ports (although for the latter any ongoing communication is
probably broken by the suspend process),
+ Well-behaved sound cards and network interface cards. In the
case of sound cards, it may happen that the card won't function directly
on resume, but for the many I have tested, unloading and loading the
driver module again fixes the problem.
For network devices, the kernel partially shuts down the different
interfaces before suspend, and on resume wakes them again. Some cards work
directly with this, and within those that don't, in most cases the card
driver "sees" that the card has a problem and successfully resets it. This
is untested for ISDN, AppleTalk and other serial/parallel point-to-point
interfaces (PPP, IrDA, ...), but look below for a workaround.
+ (important for resuming on X) most mice and pointer devices,
that are too dumb anyway to even see that the system was powered off for a
while.
This does *not* include:
+ For the moment, many internal SCSI host adapters. Unfortunately,
there is actually no way fo the kernel to shut down partially and properly
a SCSI card. Hopefully, unloading the device driver (if it's compiled as a
module) before suspend and loading it again on resume should work,
although this is not possible for SCSI-only configurations. I have yet not
tested the swsusp driver with SCSI adapters, but I guess that not all
adapters suffer this problem, and that anyway external SCSI host adapters,
such as the Iomega parallel ZIP disk are not affected.
+ For the most part, the PCMCIA package for linux, at least on my
IBM TP310E. I guess that it behaves the same for many other pcmcia
configurations, i.e. causes a kernel panic or a pcmcia lockup on
resume. However, ejecting (physically) all the cards before suspend fixes
the problem (again, on the TP310E, although I guess that it is not *that*
laptop-specific).
What works well (continued):
* Restoring the system time. The swsusp driver sets the system time on
resume to the time stored in the internal clock of the laptop, keeping
UTC/localtime settings.
* Having scripts run before suspend and after resume. This is a workaround
for *many* of the issues presented above. Simply have your suspend scripts
unload every driver that cannot properly resume, and the resume scripts
load them again.
You can also use the scripts to terminate or shut down any network
connection or communication that won't survive the 'shutdown', such as PPP
links, printing jobs, modem calls, AppleTalk or ISDN links, and so on. If
needed, you can start them again using resume scripts.
What doesn't work well:
* suspend/resume cycles by the Alt+SysRq keyboard shortcut. Indeed, this
way of triggering the suspend completely shortcuts the execution of
suspend scripts. Therefore, if any of your hardware requires to be shut
down before suspend, you are running into troubles.
* triggering the suspend with the "hibernation mode" key on some
laptops. Some laptops, like my TP310E, have a completely broken APM BIOS
(which doesn't even report properly the battery status), which do not send
the APM events in the right way (at least I think that's the problem). For
these, you must manually invoke the "apm -s" or "shutdown -s now" command,
or program an X applet that does so (easy to do with menus in window
managers).
And last but not least, a word on the installation of the driver: the
recent version that works best is only available for kernels 2.2.9 and
above, and is shown as a patch against 2.3.x. Don't worry, you can still
use it with 2.2 (high-level, remember?), but AFAIK there are some patch
adjustments needed.
In the future, if some people request it, I can make a clean patch
against 2.2.12 (which will probably nicely apply over 2.2.13 and
above) and put it on the web. Bug be about it if I forget.
After applying the pach, the configuration utility of the kernel will
present new items, which you can use to enable the swsusp feature and
control its options.
After compiling, you can boot into the new kernel and use the feature.
Beware! When testing, or without suspend scripts, be sure to shut down
manually any device that would not resume correctly.
And, most importantly, be sure to have enough swap space to hold the
contents of your physical memory *next to* the data already present in the
swap (that is important when you are short of RAM, because then often you
have some data always swapped out, and the available swap space may not be
sufficient). This means that to prevent any failure of the suspend, you
must have at least as much swap space than physical memory, and even a
little more. And remember that the resume occurs on activation of the
first swap space, and thus the suspend data cannot span across several
swap spaces!!
Then, if you want to be able to use suspend scripts, i.e. use the
"shutdown -s" command (in case you can't use "apm -s"), you should
download the modified utility from the swsusp homepage. After preparing
your scripts, you're done.
Configurations reported *not* to work (yet) with swsusp:
- SMP machines. Gabor Kuti is working on it, it may be even possible now,
but won't be completely fail-safe.
- Machines with more than 128Mb of RAM, where more than 128Mb of RAM is
used most of the time. In these configurations, a single swap space
can't hold the whole physical memory contents, and suspend will fail.
- Machines booting off SCSI devices, for which the SCSI host adapter is
unable to resume properly. This is a major issue preventing the release
of swsusp into the main kernel, but will probably be fixed soon.
Hopefully, these configurations are not common among laptops, so for us
laptop users there are not many things that prevent us from using swsusp.
Reply to: