[PATCH] x86: Move crashkernel reservation before dma32_reserve_bootmem()
Ken'ichi Ohmichi
oomichi at mxs.nes.nec.co.jp
Sun Jul 13 22:43:34 EDT 2008
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();
>
More information about the kexec
mailing list