Messages in this thread | | | Date | Sun, 15 Jul 2007 16:58:54 -0700 (PDT) | From | david@lang ... | Subject | Re: Hibernation considerations |
| |
On Sun, 15 Jul 2007, Alan Stern wrote:
> On Sun, 15 Jul 2007, Al Boldi wrote: > >> Alan Stern wrote: >>> On Sun, 15 Jul 2007, Al Boldi wrote: > >>>> 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. >> >> Ok, after applying the latest kexec patches, I was able to use the kexec'd >> kernel to suspend to ram and resume to the normal kernel, while working >> under a full-blown X session. It went without a hitch. All that is needed >> now are the dump/restore hibernation-image routines. > > That's exactly my point. While doing suspend-to-RAM from a kexec'd > kernel may be simple, saving the hibernation image will add > complications.
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.
David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |