Hi, Bernhard Walle wrote: > From: Bernhard Walle <bernhard.walle at gmx.de> > > On a x86-64 machine (nothing special I could encounter) I had the problem that > crashkernel reservation with the usual "64M at 16M" failed. While debugging that, > I encountered that dma32_reserve_bootmem() reserves a memory region which is in > that area. I tested your patch on x86_64 linux-2.6.26, and it works fine. Good catching, Bernhard :-) Before applying Bernhard's patch, kernel output the following message and could not reserve the memory area for kdump. So kdump did not work. Jul 14 11:15:48 localhost kernel: Bootmem setup node 0 0000000000000000-0000000170000000 Jul 14 11:15:48 localhost kdump: No crashkernel parameter specified for running kernel Jul 14 11:15:48 localhost kernel: NODE_DATA [000000000000f000 - 0000000000014fff] Jul 14 11:15:48 localhost kdump: failed to start up Jul 14 11:15:48 localhost kernel: bootmap [0000000000015000 - 0000000000042fff] pages 2e Jul 14 11:15:48 localhost kernel: early res: 0 [0-fff] BIOS data page Jul 14 11:15:48 localhost kernel: early res: 1 [6000-7fff] TRAMPOLINE Jul 14 11:15:48 localhost kernel: early res: 2 [200000-9b1c97] TEXT DATA BSS Jul 14 11:15:48 localhost kernel: early res: 3 [37ce4000-37fef146] RAMDISK Jul 14 11:15:48 localhost kernel: early res: 4 [9b400-fffff] BIOS reserved Jul 14 11:15:48 localhost kernel: early res: 5 [8000-efff] PGTABLE Jul 14 11:15:48 localhost kernel: crashkernel reservation failed - memory is in use After applying Bernhard's patch, kernel outputs the following message, and kdump works. Jul 14 11:27:39 localhost kernel: Bootmem setup node 0 0000000000000000-0000000170000000 Jul 14 11:27:39 localhost kernel: NODE_DATA [000000000000f000 - 0000000000014fff] Jul 14 11:27:39 localhost kernel: bootmap [0000000000015000 - 0000000000042fff] pages 2e Jul 14 11:27:39 localhost kernel: early res: 0 [0-fff] BIOS data page Jul 14 11:27:39 localhost kernel: early res: 1 [6000-7fff] TRAMPOLINE Jul 14 11:27:39 localhost kernel: early res: 2 [200000-9b1c97] TEXT DATA BSS Jul 14 11:27:39 localhost kernel: early res: 3 [37ce4000-37fef14a] RAMDISK Jul 14 11:27:39 localhost kernel: early res: 4 [9b400-fffff] BIOS reserved Jul 14 11:27:39 localhost kernel: early res: 5 [8000-efff] PGTABLE Jul 14 11:27:39 localhost kernel: Reserving 128MB of memory at 16MB for crashkernel (System RAM: 5888MB) > Because dma32_reserve_bootmem() does not rely on a specific offset but > crashkernel does, it makes sense to move the crashkernel reservation up a bit. > I tested that patch and it works without problems. I don't see any negative > effects of that move, but maybe I oversaw something ... > > While the long-term solution is to make the crashkernel reservation dynamic > (which is already done in -tip), this bug should be fixed also short-term for > 2.6.26 (or 2.6.26-stable if it's too short), and that's why I made that patch. I hope so. > Signed-off-by: Bernhard Walle <bwalle at suse.de> > Signed-off-by: Bernhard Walle <bernhard.walle at gmx.de> Tested-by: Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp> Thanks Ken'ichi Ohmichi > --- > arch/x86/kernel/setup_64.c | 7 ++++++- > 1 files changed, 6 insertions(+), 1 deletions(-) > > diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c > index 6dff128..158cefe 100644 > --- a/arch/x86/kernel/setup_64.c > +++ b/arch/x86/kernel/setup_64.c > @@ -444,6 +444,12 @@ void __init setup_arch(char **cmdline_p) > contig_initmem_init(0, end_pfn); > #endif > > + /* > + * dma32_reserve_bootmem() allocates bootmem which may conflict > + * with the crashkernel command line, so do that before > + */ > + reserve_crashkernel(); > + > dma32_reserve_bootmem(); > > #ifdef CONFIG_ACPI_SLEEP > @@ -484,7 +490,6 @@ void __init setup_arch(char **cmdline_p) > } > } > #endif > - reserve_crashkernel(); > > reserve_ibft_region(); >
