Re: kdump broken on 2.6.37-rc4

["H. Peter Anvin" <hpa@zytor.com>]

On 12/16/2010 08:46 PM, Yinghai Lu wrote:
>>
>> Second, this patch only applies if "crashkernel=" is not specified, so
>> it doesn't even apply to your situation.
> current code:
>         /* 0 means: find the address automatically */
>         if (crash_base <= 0) {
>                 const unsigned long long alignment = 16<<20;    /* 16M */
> 
>                 /*
>                  *  kexec want bzImage is below DEFAULT_BZIMAGE_ADDR_MAX
>                  */
>                 crash_base = memblock_find_in_range(alignment,
>                                DEFAULT_BZIMAGE_ADDR_MAX, crash_size, alignment);
> 
>                 if (crash_base == MEMBLOCK_ERROR) {
>                         pr_info("crashkernel reservation failed - No suitable area found.\n");
>                         return;
>                 }
>         } else {
>                 unsigned long long start;
> 
>                 start = memblock_find_in_range(crash_base,
>                                  crash_base + crash_size, crash_size, 1<<20);
>                 if (start != crash_base) {
>                         pr_info("crashkernel reservation failed - memory is in use.\n");
>                         return;
>                 }
>         }
> 
> first branch : will take only crash_size.
> second branch : will need to specify crash_base and crash_size.
> 
>>
>> Third, if you have to specify "crashkernel=" that means that there is
>> yet another problem here that should be fixed.
> 
> no, every kdump need to specify crashkernel=128M or more.
> 

Oh, you're referring to crashkernel size.  Okay, this is somewhat
different.  However, the margin is just too small on 64 bits, then.  How
far up can we actually get away with on 64 bits currently?  4 GiB?

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.