Re: [Patch] min_low_pfn and max_low_pfn calcultion fix

From: Jay Lan <>
Date: 2007-03-15 05:48:15
Jay Lan wrote:
> Jay Lan wrote:
>> Magnus Damm wrote:
>> [snip]
>>>> I tested on 2.6.21-rc3 with DEBUG_VM turned on. The vanilla 2.6.21-rc3
>>>> without Nan-hai's patch, panicked on bugcheck on free_initmem->free_page
>>>> as predicted. We still need this patch.
>>> Ok, thanks for testing. =)
>>>> However, the zero-size vmcore problem is back on SN. But that is a
>>>> dfiffernet problem.
>>> Argh, more problems...
>> I found the problem. It was the "elfcorehdr" introduced in 2.6.21-rc1.
>> Without specifying it, the elfcorehdr_addr is initialized to
>> ELFCORE_ADDR_MAX. Later, a check in reserve_elfcorehdr will fail:
>>         if (elfcorehdr_addr >= ELFCORE_ADDR_MAX)
>>                 return -EINVAL;
>> Is it supposed to be a physical address to store elf core header?
>> If so, it is not possible for SN to provide a physical address at
>> boot time, just like in the case of crashkernel=X@Y where Y is not used.
> Sorry, the elfcorehdr parameter is provided to the kdump kernel by
> kexec. The problem is in the reserve_elfcorehdr logic introduced in
> 2.6.21-rc1.
> When booting up the kdump kernel, i observed a failure in
> reserve_elfcorehdr. The below are my debugging messages:
> elfcorehdr_addr=3027fe4000, ELFCORE_ADDR_MAX=ffffffffffffffff
> Cannot locate EFI vmcore descriptor
> reserve_elfcorehdr: vmcore descriptor size = 0
> reserve_memory: FAIL to reserve reserve_elfcorehdr

Hi Tony,

The kernel code 2.6.21-rc3+ is fine wrt zero-size-vmcore issue.

I have been testing on a rhel5 environment. The /sbin/kexec worked
for me up to 2.6.20.

I then built a new kexec from tot kexec-tools-testing git tree and
i no longer see the zero-size-vmcore problem.

 - jay
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to
More majordomo info at
Received on Thu Mar 15 05:50:29 2007

This archive was generated by hypermail 2.1.8 : 2007-03-15 05:50:41 EST