On 11/26/2009 12:22 AM, Bernhard Walle wrote:
M. Mohan Kumar schrieb:
Reserve memory for kdump kernel within RMO region
When the kernel size exceeds 32MB(observed with some distros), memory
for kdump kernel can not be reserved as kdump kernel base is assumed to
be 32MB always. When the kernel has CONFIG_RELOCATABLE option enabled,
provide the feature to reserve the memory for kdump kernel anywhere in
the RMO region.
Hi Bernhard,
Correct me if I'm wrong, but: CONFIG_RELOCATABLE is for the kernel that
gets loaded as crashkernel, not for the kernel that loads the
crashkernel. So it would be perfectly fine that a kernel that has not
CONFIG_RELOCATABLE set would load another kernel that has
CONFIG_RELOCATABLE set on an address != 32 M.
No, with relocatable option, the same kernel is used as both production
and kdump kernel. If the kernel is not relocatable, kdump kernel can be
loaded *only at* 32MB. So if a kernel has RELOCATABLE option enabled and
by chance if the production kernel size is beyond 32MB, current code
will not load the kdump kernel at 32MB as current kernel overlaps with
kdump kernel region. So if the kernel has RELOCATABLE option, we could
reserve memory for kdump kernel within RMO region.
So it would be part of the command line to determine whether a fixed or
a variable address is used. The system configuration (or the admin)
knows both: if the kernel that should be loaded is relocatable (can be
detected with the x86 bzImage header or with the ELF type for vmlinux)
and it can also influence the boot command line.
To sum it up: I'm not against reserving it anywhere, I'm only against
making it dependent on CONFIG_RELOCATABLE which has another function.
Regards,
Bernhard
_______________________________________________
kexec mailing list
ke...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
