> -----Original Message----- > From: linux-ia64-owner@xxxxxxxxxxxxxxx > [mailto:linux-ia64-owner@xxxxxxxxxxxxxxx] On Behalf Of Zou, Nanhai > Sent: 2006年10月27日 9:41 > To: Mel Gorman; Horms > Cc: linux-ia64@xxxxxxxxxxxxxxx; 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@xxxxxxxxx] > > Sent: 2006年10月26日 21:27 > > To: Horms > > Cc: linux-ia64@xxxxxxxxxxxxxxx; 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@xxxxxxxxx Thu Oct 26 14:10:39 2006 > > Date: Thu, 26 Oct 2006 14:10:39 +0100 (IST) > > From: Mel Gorman <mel@xxxxxxxxx> > > To: Andy Whitcroft <apw@xxxxxxxxxxxx> > > 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? Thanks Zou Nan hai - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
![]() |