Hi,

Bernhard Walle wrote:
> From: Bernhard Walle <[EMAIL PROTECTED]>
> 
> On a x86-64 machine (nothing special I could encounter) I had the problem that
> crashkernel reservation with the usual "[EMAIL PROTECTED]" 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 <[EMAIL PROTECTED]>
> Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>

Tested-by: Ken'ichi Ohmichi <[EMAIL PROTECTED]>


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();
>  



_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Reply via email to