On Tue, Jan 11, 2011 at 08:22:12AM -0800, H. Peter Anvin wrote: > 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 Gotcha, so this is a kexec utility issue then, rather than a kernel problem, in that kexec fills out the bzimage header without taking memory holes into account ok, that makes more sense. Thanks! Neil
