Re: [RFC][PATCH 0/2 -mm] kexec based hibernation -v3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



huang ying wrote:
On 9/21/07, Mika Penttilä <mika.penttila@xxxxxxxxxxx> wrote:
huang ying wrote:
On 9/21/07, Mika Penttilä <mika.penttila@xxxxxxxxxxx> wrote:

Usage:

1. Compile kernel with following options selected:

CONFIG_X86_32=y
CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore memory image
CONFIG_PM=y
CONFIG_KEXEC_JUMP=y

2. Download the kexec-tools-testing git tree, apply the kexec-tools
   kjump patches (or download the source tar ball directly) and
   compile.

3. Download and compile the krestore tool.

4. Prepare 2 root partition used by kernel A and kernel B/C, referred
   as /dev/hda, /dev/hdb in following text. This is not strictly
   necessary, I use this scheme for testing during development.

5. Boot kernel compiled for normal usage (kernal A).

6. Load kernel compiled for hibernating/restore usage (kernel B) with
   kexec, the same kernel as that of 5 can be used if
   CONFIG_RELOCATABLE=y and CONFIG_CRASH_DUMP=y are selected.

   The --elf64-core-headers should be specified in command line of
   kexec, because only the 64bit ELF is supported by krestore tool.

   For example, the shell command line can be as follow:

   kexec -p -n /boot/bzImage --mem-min=0x100000 --mem-max=0xffffff
       --elf64-core-headers --append="root=/dev/hdb single"

7. Jump to the hibernating kernel (kernel B) with following shell
   command line:

   kexec -j

8. In the hibernating kernel (kernel B), the memory image of
   hibernated kernel (kernel A) can be saved as follow:

   cp /proc/vmcore .
   cp /sys/kernel/kexec_jump_back_entry .


Here we save also kernel B's pages.

No, the kernel B's pages will not be saved. Because when we build the
elfcore (/proc/vmcore) header, we exclude memory area used by kernel
B. The details can be found in kexec-tools patches.


Ok I see. But should the kernel B's e820 mem map be limited to 1m-16m in
order not to allocate pages found also in A's space? Or does does the
--mem-min and --mem-max do that also?

That is what "memmap=exactmap memmap=640K@0K memmap=15M@1M" for. The
contents of e820 memmap will be overrided when these kernel parameters
are specified.

Best Regards,
Huang Ying
Yes, you just didn't specify exactmap for kernel B in your instructions, but only for C. But it is also required for kernel B then?

Thanks,
Mika

_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux