User: Password:
|
|
Subscribe / Log in / New account

Yet another approach to software suspend

Yet another approach to software suspend

Posted Jul 21, 2007 18:48 UTC (Sat) by dlang (subscriber, #313)
In reply to: Yet another approach to software suspend by i3839
Parent article: Yet another approach to software suspend

there is contradictory information about how much work needs to be done for the restore

the current restore functions assume that all the hardware has been put into ACPI low-power mode or the restore image may not work

so the two options right now seem to be
enhance this mode
use kexec to do a kernel shuffle (boot one kernel, kexec to a second kernel that's in the reserved space, then restore the image to the origional location (overwriting the boot kernel) and then kexec into it

the second approach isn't elegant, but doesn't depend on the state of the hardware.


(Log in to post comments)

Yet another approach to software suspend

Posted Jul 22, 2007 10:17 UTC (Sun) by i3839 (guest, #31386) [Link]

Why let the kexec kernel do the restore instead of the boot kernel? As I see it there are two cases:

- The normal kernel and the kexec kernels share a kernel image. In this case the boot kernel just needs to allocate mem in the reserved area and kexec to the restored kernel when it's done restoring the image.

- They have two different kernel images. Now the bootup kernel needs to be loaded in the reserved area. Though this can be hard as the bootloader loads the kernel, so yes, in this case doing two kexeces seems simpler, though that would slow down the restore.

It's unclear what the ACPI hibernate mode does, but I guess it lets the bios boot up the machine quicker because it skips some hardware init stuff or something. So you'd want to support this as good as possible anyway, assuming it makes sense, no matter what else you do.

And the kexec approach also depends on the hardware state because the restored image depends on it. Only thing that kexec does well is making a good snapshot, but it doesn't solve the hardware side of it.

(Which could cause complications, because that state might be changed by loading the image.)

So no matter what approach is used (kexec, freezer, ...), 90% of the work will always be the suspend/hibernate/resume/wake-up functions in the drivers. Same for most problems caused.

If the current restore method works fine, why not continue using that?

Yet another approach to software suspend

Posted Jul 22, 2007 22:06 UTC (Sun) by dlang (subscriber, #313) [Link]

Quote:
If the current restore method works fine, why not continue using that?

becouse Rafael is telling everyone that if you completely power off the system the current restore method will not properly restore the box (most things should come up, but things will not be right)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds