On Sun, 15 Jul 2007, Alan Stern wrote:
(7) On ACPI systems special platform-related actions have to be carried
out at the right points, so that the platform works correctly after the
restore
The ACPI specification requires us to invoke some global ACPI methods
during the hibernation and during the restore. Moreover, the ordering
of code related to these ACPI methods may not be arbitrary (eg. some of
them have to be executed after devices are put into low power states
etc.).
This should be the responsibility of the kexec'd hibernating kernel. Note
though in (6), the normal kernel takes care of preparing devices, then the
hibernating kernel dumps the image and either calls S4 or S3. On resume
from S3 it can immediately switch over to the normal kernel, and from S4 the
known bootup would occur.
Is it really that simple? Somehow I doubt it. In order for some
devices to remain available for the kexec'd kernel to use, they cannot
be suspended at the ACPI level. So the kexec'd kernel will have to
handle the ACPI requirements for those devices. Likewise, it would
have to handle the ACPI interactions which need to be done after all
devices are prepared for the transition to S3 or S4.
so if there are two states for hardware
1. able to be detected and initialized with the standard boot routines
2. ACPI suspend mode, requireing ACPI specifics to wake up
is it possible to detect which is needed? cna you try the ACPI wakeup and
if it doesn't work go to the standard boot routine (or vice-versa)?
(8) Hibernation and restore should not be too slow
In my opinion, if more than one minute is needed to hibernate the
system with the help of certain hibernation framework, then this framework
is not very useful in practice. It might be useful to perform some
special tasks (eg. moving a server to another place without taking it
down), but it is not very useful, for example, to notebook users.
The latest hibernating kexec patches boot a kexec'd modular kernel with
initramfs into crashkernel=16M@16M in less than one second. Switch-back is
almost instant. Add to this the time required to either store or restore
the image, and it may be obvious that this approach isn't slower, but maybe
even faster than the current swsusp.
Does that include the time required for probing PCI buses? On my
desktop system, PCI probing incurs a five-second timeout delay because
of a bug in the BIOS's USB firmware. Don't be so sure that kexec will
always be lightning fast; it is always better to avoid unnecessary
boots.
some drivers will have delays on some machines (especially when you
consider hardware bugs that have to be worked around), but at the moment
nothing is remotely close to the 'limit' of 60 seconds being talked about
here.
although with some machines the mear trasnfer times for the data could
cause noticable delays (if you have a server with 128G of ram it may take
a while to get it to a drive)
David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
