On Tue, 2007-07-17 at 01:13 -0700, david@xxxxxxx wrote: > however, since the resume designed for ACPI won't work would the following > approach work > > 1. boot one kernel > 2. setup a kexec the same way you would for hibernate > 3. kexec to the new kernel > 4. overwrite the memory of the first kernel > 5. kexec 'back' to the main kernel that has now been overwritten by what was saved? > > as part of this question, when you do a kexec, how does the kernel that > you are doing the kexec to know what to run next? For kernel in 3 that do kexec, the devices and CPU state are saved into memory before executing the new kernel. So when jumping back, the control will continue from kexec point. If the memory image of main kernel is restored from disk, the devices and CPU state in memory is restored too. Before jumping back in 5, the devices are put in the known state, after jumping back, the devices and CPU state is restored. If the "kexec -j" is used to trigger the kexec in 3, the system will continue with "kexec -j" exiting with exit code 0. > it needs to do some initialization first before it starts running normal > things, and at that point it the move back doesn't look for init like a > normal kernel boot (or the system would effectivly boot instead of picking > up where it left off) I think the early initialization can be done in a initramfs. At that point, the resume image can be checked, the next step depends on the result of checking. > is this 'restart point' flexible enough that either the pre-hibernate > kerenl or the small hibernate kernel could tell the pre-hibernate kernel > to go into suspend-to-ram mode before doing anything else? It is possible for hibernate kernel to pass information back to pre-hibernate kernel. For example, the information can be passed in jump buffer page. Best Regards, Huang Ying _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
