Re: kexec and relocatable kernels

["H. Peter Anvin" <hpa@zytor.com>]

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.

	-hpa

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec