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
