[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