On Sun, Feb 06, 2011 at 08:25:20PM -0600, Rob Landley wrote: > On 02/06/2011 03:57 PM, Simon Horman wrote: > > On Sun, Feb 06, 2011 at 05:41:08PM +0200, Ahmed S. Darwish wrote: > >> (Also applicable over 2.6.38-rc3) > >> > >> Had to explore two C code files to make sense of the 'crashkernel=' > >> kernel parameter values. Improve the situation. > >> > >> Signed-off-by: Ahmed S. Darwish <darwish.07 at gmail.com> > >> --- > >> > >> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt > >> index 89835a4..8f26b42 100644 > >> --- a/Documentation/kernel-parameters.txt > >> +++ b/Documentation/kernel-parameters.txt > >> @@ -545,9 +545,12 @@ and is between 256 and 4096 characters. It is defined in the file > >> Format: > >> <first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>] > >> > >> - crashkernel=nn[KMG]@ss[KMG] > >> - [KNL] Reserve a chunk of physical memory to > >> - hold a kernel to switch to with kexec on panic. > >> + crashkernel=size[KMG][@offset[KMG]] > >> + [KNL] Using kexec, Linux can switch to a 'crash kernel' > >> + upon panic. This parameter reserves the physical > >> + memory region [offset, offset + size] for that kernel > >> + image. If the '@offset' part was ignored, Linux finds > >> + a suitable crash image start address automatically. > > > > I think this would be further improved as: > > > > ... If '@offset' is omitted then a suitable > > offset is selected automatically. > > Suitable offset as in parses a known image type (ELF, bzImage, etc) to > find the start address? Or just assumes the entry point and load > address are the same? As in it finds a large enough area of contiguous free memory. I believe that originally it searched from the bottom of memory, it may be slightly smarter now. Suitable is perhaps too strong a term. In terms of the start address. On x86 at least it used to be important to make sure that the start address matched but these days using a relocatable kernel is an easier option. > Is this the size for just the kernel image, or also for the physical > memory it uses so it won't overwrite the existing kernel's stuff on the > way up? (If a compressed kernel wants to decompress itself or extract > an initramfs for itself, what happens?) It is the memory that is used by the crash-kernel to avoid overwriting the first-kernel's stuff. It is not the memory where the (usually compressed) second-kernel is stored before it is kexeced. If a compressed crash-kernel wants to decompress itself it does so in the available memory which is the region reserved by the crash-kernel parameter to the first-kernel.
