Re: 05e0caad3b7bd0d0fbeff980bca22f186241a501 breaks ia64 kdump

From: Andy Whitcroft <apw_at_shadowen.org>
Date: 2006-10-27 19:15:16
Zou, Nanhai wrote:
> 
>> -----Original Message-----
>> From: linux-ia64-owner@vger.kernel.org
>> [mailto:linux-ia64-owner@vger.kernel.org] On Behalf Of Zou, Nanhai
>> Sent: 2006年10月27日 9:41
>> To: Mel Gorman; Horms
>> Cc: linux-ia64@vger.kernel.org; Linus Torvalds; Bob Picco; Andrew Morton; Dave
>> Hansen; Andy Whitcroft; Andi Kleen; Benjamin Herrenschmidt; Paul Mackerras;
>> Keith Mannthey; Luck, Tony; KAMEZAWA Hiroyuki; Yasunori Goto; Khalid Aziz
>> Subject: RE: 05e0caad3b7bd0d0fbeff980bca22f186241a501 breaks ia64 kdump
>>
>>
>>> -----Original Message-----
>>> From: Mel Gorman [mailto:mel@csn.ul.ie]
>>> Sent: 2006年10月26日 21:27
>>> To: Horms
>>> Cc: linux-ia64@vger.kernel.org; Linus Torvalds; Bob Picco; Andrew Morton;
>> Dave
>>> Hansen; Andy Whitcroft; Andi Kleen; Benjamin Herrenschmidt; Paul Mackerras;
>>> Keith Mannthey; Luck, Tony; KAMEZAWA Hiroyuki; Yasunori Goto; Zou, Nanhai;
>>> Khalid Aziz
>>> Subject: Re: 05e0caad3b7bd0d0fbeff980bca22f186241a501 breaks ia64 kdump
>>>
>>> From mel@csn.ul.ie Thu Oct 26 14:10:39 2006
>>> Date: Thu, 26 Oct 2006 14:10:39 +0100 (IST)
>>> From: Mel Gorman <mel@csn.ul.ie>
>>> To: Andy Whitcroft <apw@shadowen.org>
>>> Subject: Re: 05e0caad3b7bd0d0fbeff980bca22f186241a501 breaks ia64 kdump
>>>
>>> On Thu, 26 Oct 2006, Horms wrote:
>>>
>>>> Hi,
>>>>
>>>> After doing a bit of research it seems that ia64 kdump is broken
>>>> by 05e0caad3b7bd0d0fbeff980bca22f186241a501, which appeared between
>>>> 2.6.18 and 2.6.19-rc3. I can be more specific about the version if
>>>> need be, but here is the commit log from Linus' tree.
>>>>
>>> Ok, Andy Whitcroft and I both took a few kicks at this problem to see what
>>> the story was. My current understanding (given to me by Andy) with kdump is
>>> this
>>>
>>> 1. Normal kernel boots and leaves a kdump hole in memory somewhere
>>> 2. In the kdump hole, a crash dump kernel is loaded
>>> 3. Things run happily for a while until something goes wrong. kexec is
>>>     called on the kernel image in the kdump hole
>>> 4. kdump kernel starts and creates an image
>>>
>>> Grand so far.
>>>
>>> Now, with arch-independent zone-sizing, an architecture states where "real"
>>> memory is and memmap is initialised in those ranges.
>>>
>>> The maps of the two kernels look like this
>>>
>>> Normal Kernel
>>>> early_node_map[7] active PFN ranges
>>>>    0:     1025 ->     4096
>>>>    0:     4567 ->    16384
>>>>    0:    32768 ->   125911
>>>>    0:   126514 ->   127540
>>>>    0:   127541 ->   128557
>>>>    0:   128576 ->   130688
>>>>    0:   130984 ->   130998
>>> Crash kernel
>>>> early_node_map[7] active PFN ranges
>>>>    0:    16855 ->    16856
>>>>    0:    16857 ->    32096
>>>>    0:    32752 ->    32753
>>>>    0:    32754 ->    32755
>>>>    0:    32756 ->    32757
>>>>    0:    32758 ->    32761
>>>>    0:    32762 ->    32768
>>> So, there is clearly a hole there between 16384 -> 32768 for the kdump hole
>>> in the normal kernel. I expect the kernel image and __init sections are
>>> located at PFN 16384.
>>>
>>> The problem is that the crash kernel is reporting that memory starts at
>>> 16855, a gap of 471 page frames! memmap will not be initialised here because
>>> it "doesn't exist" even though the memmap will be allocated because of
>>> MAX_ORDER-alignment issues
>>>
>>> The first fault looks like this
>>>
>>>> page:a0007ffffff23598 flags:0x0000000000000000 mapping:0000000000000000
>>>> mapcount:1 count:0
>>> Based on the value of virtual mem_map, that is at PFN 16629 or about 245
>>> page frames into the kernel image. In the stack trace, you see
>>> free_initmem() is being called. i.e. the __init section appears in a memory
>>> hole where memmap was never initialised.
>>>
>>> I haven't looked at how kdump works yet, but you are either supplying a fake
>>> EFI map that omits the kernel image or else you only read a portion of the
>>> EFI when booting a crash kernel and start reading after the kernel image
>>> ends. If the EFI covers the kernel image, you'll see an entry like this in
>>> the early_node_map
>>>
>>> 0: 16384 -> 16855
>>>
>>> and that bad_page() will disappear.
>>>
>>> We'll start kicking at the kdump patches now, but maybe a kdump expert can
>>> tell offhand why the crash kernel's EFI map does not cover the kernel image.
>>>
>> EFI memmap is changed in purgatory code.
>> I mark old EFI memmap entry with attribute EFI_LOADER_DATA as
>> EFI_CONVENTIONAL_MEMORY, then mark the range of crash kernel image as
>> EFI_LOADER_DATA. During this some EFI memmap range may be split, but the entire
>> layout is not changed.
>>
>> I am building 2.6.19-rc3 to see if I can reproduce the issue.
>>
>> Thanks
>> Zou Nan hai
>> -
> 
> 
> Hi Neil,
>  I can't reproduce the issue with 2.6.19-rc3
>  Is there any special config option to reproduce it?

Hi,

Mel and I spent a bit more time thinking about this.  If the efi map is
being modified such that the kernel area becomes loader data that may
well move up the start of conventional memory as far as the running
kernel is concerned.

[Apologies in advance if Zou is not an appropriate name.]

It would be helpful both to have a dump of the efi map and the start
address of the kernel from the affected machine (Horms) and if possible
the efi map and start address of the kernel from your working test
platform (Zou).  Also, if we could get the boot logs from a conventional
kernel and the kexec kernel from the working test platform (Zou).

A logical next step might be to bodge things such that we offer up the
kernel image as an active range and see if that sorts out the alignment
issue we are seeing, this will allow us to be certain it is the kernel
image in this area.  Something like the following inserted into
register_memory() might work:

	add_active_range(0, code_resource.start >> PAGE_SHIFT,
			    data_resource.end >> PAGE_SHIFT);

Not sure this is the right thing as a fix, but would help confirm the
theory.

-apw
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Fri Oct 27 19:16:25 2006

This archive was generated by hypermail 2.1.8 : 2006-10-27 19:16:36 EST