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
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
