kexec and relocatable kernels

H. Peter Anvin hpa at
Tue Jan 11 11:22:12 EST 2011

On 01/11/2011 04:06 AM, Neil Horman wrote:
> Not sure I completely follow here.  Clearly kdump uses relocatable kernels, and
> so can avoid this problem.  But what part of the reboot path affects relocation
> such that if your not using kdump, you wind up relocating into a memory hole.
> As I understood it (and I admittedly haven't gone back to look as I write this),
> the relocation code lives in the header of the kernel image, so it should be the
> same weather we're booting on panic (via kdump), or just booting a new kernel
> (via kexec -e).  Is something getting messed up in the header data that kexec
> doesn't inform the kernel of the presence of a memory hole in some cases?

No, the problem is that kexec doesn't check if the placement of the
kernel will interfere with a memory hole when picking a default load
location; it always load a replacement (as opposed to kdump) kernel at
0x100000.  For at least a >= 2.10 kernel, it can do better: check to see
if the actual placement will interfere with the memory map and if so,
place it differently.


More information about the kexec mailing list