[EMAIL PROTECTED] wrote: > On Mon, 16 Jul 2007, Al Boldi wrote: > > [EMAIL PROTECTED] wrote: > >> suspend-to-RAM should not involve kexec, the only reason for doing the > >> kexec to to get a seperate userspace to use for suspend-to-disk > >> operations instead of trying to partially freeze the sustem and keep > >> useing it. > > > > Or you could do suspend-to-disk-and-RAM. But in the above case, it was > > meant to test kexec compatibility with device suspend/resume calls. > > the point I am trying to make here is that there is no reason that the > kexec approach needs to do _any_ suspend/resume calls.
When you go through ACPI, then that implies calling suspend/resume calls. > all that is needed is the ability of the new kernel to initialize the > devices it needs. We have to go through ACPI, for wakeup functions to succeed. A simple power-off won't do. > suspend-to-disk-and-ram could be implemented as three > seperate steps > > 1. suspend-to-disk > > 2. resume-from-disk > > 3. suspend-to-ram > > followed by either > > 4. resume-from-ram > > or > > 4. battery dies and loptop powers off completely > > 5. power-on boot. > > 6. resume-from-disk > > all that you need to do is to make sure that the system doesn't run > anything that would affect permanent media or the outside world between > steps #2 and #3 Exactly, which is why your scheme would break down on #3, and that's why you need to call S3 from within the kexec'd hibernation kernel after saving the hibernation image. Thanks! -- Al - 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/
