From: Jay Lan <jlan@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [Patch] min_low_pfn and max_low_pfn calcultion fix
Date: Thu, 15 Mar 2007 02:11:43 +0000 [thread overview]
Message-ID: <45F8AB5F.1010909@sgi.com> (raw)
In-Reply-To: <1172619535.20006.334.camel@linux-znh>
Horms wrote:
> On Wed, Mar 14, 2007 at 11:48:15AM -0700, Jay Lan wrote:
>> 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_addr027fe4000, ELFCORE_ADDR_MAXÿffffffffffffff
>>> 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.
>
> I take it that elfcorehdr is also correct in this environment?
Yes. I got a good vmcore.
Regards,
- jay
>
> The latest (ia64) kernels need a fairly recent kexec-tools-testing
> because of the change "kexec: Use EFI_LOADER_DATA for ELF core header".
> A recent kexec-tools-testing is probably needed for other reasons,
> though I can't think of them off-hand.
>
next prev parent reply other threads:[~2007-03-15 2:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-27 23:38 [Patch] min_low_pfn and max_low_pfn calcultion fix Zou Nan hai
2007-02-28 1:48 ` Jay Lan
2007-02-28 10:01 ` Magnus Damm
2007-03-12 20:35 ` Jay Lan
2007-03-12 22:08 ` Luck, Tony
2007-03-13 19:28 ` Jay Lan
2007-03-14 4:38 ` Magnus Damm
2007-03-14 15:27 ` Jay Lan
2007-03-14 15:55 ` Jay Lan
2007-03-14 18:48 ` Jay Lan
2007-03-15 1:55 ` Horms
2007-03-15 2:11 ` Jay Lan [this message]
2007-03-16 5:15 ` Horms
2007-03-20 18:59 ` Jay Lan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45F8AB5F.1010909@sgi.com \
--to=jlan@sgi.com \
--cc=linux-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox