On Wed, Nov 01, 2006 at 09:38:38AM +0000, Mel Gorman wrote:
> On Wed, 1 Nov 2006, Horms wrote:
>
> >On Tue, 31 Oct 2006, Mel Gorman wrote:
> >>On Tue, 31 Oct 2006, Horms wrote:
> >>
> >>>On ??, 10?? 30, 2006 at 11:49:00???? +0000, Mel Gorman wrote:
> >>>>On Mon, 30 Oct 2006, Horms wrote:
> >>>>
> >>>>>On Mon, Oct 30, 2006 at 06:11:26PM +0900, Horms wrote:
> >>>>>>On Fri, Oct 27, 2006 at 10:15:16AM +0100, Andy Whitcroft wrote:
> >>>>>>
> >>>>>>>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.
> >>>>>>
> >>>>>>I will poke around with that. Though it will probably be tomorrow.
> >>>>>
> >>>>>Hi,
> >>>>>
> >>>>>I did try adding that line to the end of register_memory(),
> >>>>>however it didn't seem to alter the behaviour that I am seeing.
> >>>>>The log is below, including the EFI map, in case it is useful.
> >>>>>
> >>>>
> >>>>Judging from the output of early_node_map[], the range of memory the kdump
> >>>>kernel is in is still not being registered so the memmap is not
> >>>>initialised.
> >>>>In
> >>>>the EFI output, we see
> >>>>
> >>>>mem12: type=2, attr=0xb, range=[0x0000000010000000-0x00000000104b0000)
> >>>>(4MB)
> >>>>mem13: type=2, attr=0xb, range=[0x00000000104b0000-0x00000000104c0000)
> >>>>(0MB)
> >>>>mem14: type=2, attr=0xb, range=[0x00000000104c0000-0x0000000010760000)
> >>>>(2MB)
> >>>>mem15: type=7, attr=0xb, range=[0x0000000010760000-0x000000001ffe4000)
> >>>>(248MB)
> >>>>
> >>>>The first three ranges is where I suspect the kernel is and with "type=2",
> >>>>add_active_range() is not being called when walking the EFI map. If this
> >>>>memory
> >>>>is marked correctly, it will get registered correctly.
> >>>>
> >>>>Try calling add_active_range(0, 16384, 16855) manually after the call to
> >>>>efi_memmap_walk(register_active_ranges, &nid) and see does the kernel boot.
> >>>
> >>>Hi Mel,
> >>>
> >>>I am pleased to report that the above change did indeed allow the
> >>>"crash kernel" to boot without incident.
> >>>
> >>
> >>ok, that confirms then that the "adjusted" memmap is messed up and providing
> >>the wrong information which mucks the initialisation later. Boot a kernel
> >>without kdump in it at all and look at the output of early_node_map[] and
> >>you'll see what the 256MB range at PFN 16384 is meant to look like. Then
> >>apply
> >>the kdump patches and get the EFI map to look the same for that 256MB region
> >>on
> >>kexec.
> >
> >Plan A
> >It sounds like the "adjusted" memmap needs to be fixed then. I'm
> >guessing that these regions should not be marked as "type=2",
> >but rater "type=7". I'll see how that pans out.
> >
>
> You may find that the kernel image is being set to type=2 to avoid the
> kern_memmap being placed over the kernel image in find_memmap_space() (this is
> a guess). If your kernel suddenly disappears after you set the type=7, the
> guess is accurate.
>
> While you are looking at the adjusted memmap, see can you figure out why there
> are a large number of holes in there of 1 page (see the ranges the
> early_node_map[] and you'll see what I mean). It doesn't seem right.
I added some code to kexec's purgatory to merge regions in the
mangled efi map that have the same type and attribute. This resulted
in slightly fewer regions. I'm not sure if its possible to do more
without merging regiouns of different types. But I will examine why
there are so many regions of different types interleaved.
Is
I have to leave my desk now, the patch that I have is below.
It is against the kexec-tools-testing git tree from www.kernel.org
Kernel Start Address: _start=000000070300000b
mem00: type=4, attr=0x9, range=[0x0000000000000000-0x0000000000001000) (0MB)
mem01: type=7, attr=0x9, range=[0x0000000000001000-0x0000000000007000) (0MB)
mem02: type=4, attr=0x9, range=[0x0000000000007000-0x0000000000009000) (0MB)
mem03: type=7, attr=0x9, range=[0x0000000000009000-0x0000000000082000) (0MB)
mem04: type=6, attr=0x8000000000000009, range=[0x0000000000082000-0x0000000000084000) (0MB)
mem05: type=7, attr=0x9, range=[0x0000000000084000-0x0000000000085000) (0MB)
mem06: type=4, attr=0x9, range=[0x0000000000085000-0x00000000000a0000) (0MB)
mem07: type=5, attr=0x8000000000000009, range=[0x00000000000c0000-0x0000000000100000) (0MB)
mem08: type=7, attr=0xb, range=[0x0000000000100000-0x000000000ffc0000) (254MB)
mem09: type=4, attr=0xb, range=[0x000000000ffc0000-0x0000000010000000) (0MB)
mem10: type=2, attr=0xb, range=[0x0000000010000000-0x0000000010740000) (7MB)
mem11: type=7, attr=0xb, range=[0x0000000010740000-0x000000001ffe0000) (248MB)
mem12: type=8, attr=0xb, range=[0x000000001ffe0000-0x000000001ffe1000) (0MB)
mem13: type=7, attr=0xb, range=[0x000000001ffe1000-0x000000007c8d2000) (1480MB)
mem14: type=1, attr=0xb, range=[0x000000007c8d2000-0x000000007c92e000) (0MB)
mem15: type=7, attr=0xb, range=[0x000000007c92e000-0x000000007c938000) (0MB)
mem16: type=1, attr=0xb, range=[0x000000007c938000-0x000000007c97e000) (0MB)
mem17: type=7, attr=0xb, range=[0x000000007c97e000-0x000000007ce16000) (4MB)
mem18: type=4, attr=0xb, range=[0x000000007ce16000-0x000000007ce1c000) (0MB)
mem19: type=7, attr=0xb, range=[0x000000007ce1c000-0x000000007ce20000) (0MB)
mem20: type=4, attr=0xb, range=[0x000000007ce20000-0x000000007ce22000) (0MB)
mem21: type=7, attr=0xb, range=[0x000000007ce22000-0x000000007ce2a000) (0MB)
mem22: type=4, attr=0xb, range=[0x000000007ce2a000-0x000000007d001000) (1MB)
mem23: type=7, attr=0xb, range=[0x000000007d001000-0x000000007d002000) (0MB)
mem24: type=4, attr=0xb, range=[0x000000007d002000-0x000000007d004000) (0MB)
mem25: type=7, attr=0xb, range=[0x000000007d004000-0x000000007d026000) (0MB)
mem26: type=4, attr=0xb, range=[0x000000007d026000-0x000000007d068000) (0MB)
mem27: type=7, attr=0xb, range=[0x000000007d068000-0x000000007d069000) (0MB)
mem28: type=4, attr=0xb, range=[0x000000007d069000-0x000000007d37e000) (3MB)
mem29: type=7, attr=0xb, range=[0x000000007d37e000-0x000000007d700000) (3MB)
mem30: type=3, attr=0xb, range=[0x000000007d700000-0x000000007d77e000) (0MB)
mem31: type=7, attr=0xb, range=[0x000000007d77e000-0x000000007d8b4000) (1MB)
mem32: type=6, attr=0x8000000000000009, range=[0x000000007d8b4000-0x000000007d900000) (0MB)
mem33: type=3, attr=0xb, range=[0x000000007d900000-0x000000007f980000) (32MB)
mem34: type=7, attr=0xb, range=[0x000000007f980000-0x000000007fa00000) (0MB)
mem35: type=5, attr=0x8000000000000009, range=[0x000000007fa00000-0x000000007fe00000) (4MB)
mem36: type=13, attr=0x8000000000000009, range=[0x000000007fe00000-0x000000007fe48000) (0MB)
mem37: type=5, attr=0x8000000000000009, range=[0x000000007fe48000-0x000000007fea0000) (0MB)
mem38: type=7, attr=0xb, range=[0x000000007fea0000-0x000000007feda000) (0MB)
mem39: type=5, attr=0x8000000000000009, range=[0x000000007feda000-0x000000007ff46000) (0MB)
mem40: type=6, attr=0x8000000000000009, range=[0x000000007ff46000-0x0000000080000000) (0MB)
mem41: type=11, attr=0x1, range=[0x00000000fe000000-0x00000000ff000000) (16MB)
mem42: type=6, attr=0x8000000000000001, range=[0x00000000ff000000-0x0000000100000000) (16MB)
mem43: type=11, attr=0x8000000000000001, range=[0x00000ffff8000000-0x00000ffffc000000) (64MB)
mem44: type=12, attr=0x8000000000000001, range=[0x00000ffffc000000-0x0000100000000000) (64MB)
This is with the patch I posted earlier today which
adds the kernel region using add_active_range()
early_node_map[2] active PFN ranges
0: 16384 -> 32095
0: 32751 -> 32768
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
Index: kexec-tools-unstable/purgatory/arch/ia64/purgatory-ia64.c
===================================================================
--- kexec-tools-unstable.orig/purgatory/arch/ia64/purgatory-ia64.c 2006-11-02 16:18:37.000000000 +0900
+++ kexec-tools-unstable/purgatory/arch/ia64/purgatory-ia64.c 2006-11-02 18:20:34.000000000 +0900
@@ -151,6 +151,45 @@
return addr - PAGE_OFFSET;
}
+/* Merge ranges
+ * assumes that mergable ranges are consicutive and ordered */
+void
+merge_efi_memmap(struct kexec_boot_params *params,
+ struct ia64_boot_param *boot_param)
+{
+ efi_memory_desc_t *dst_md, *next_md, *tmp_md;
+
+ dst_md = (efi_memory_desc_t *)params->efi_memmap_base;
+ while(dst_md < (void *)params->efi_memmap_base +
+ boot_param->efi_memmap_size) {
+ next_md = (void *)dst_md + boot_param->efi_memdesc_size;
+
+ if (dst_md->type != next_md->type ||
+ dst_md->attribute != next_md->attribute ||
+ dst_md->phys_addr + (dst_md->num_pages << EFI_PAGE_SHIFT)
+ < next_md->phys_addr) {
+ dst_md = (void *)dst_md + boot_param->efi_memdesc_size;
+ continue;
+ }
+
+ dst_md->num_pages = (next_md->phys_addr +
+ (next_md->num_pages << EFI_PAGE_SHIFT) -
+ dst_md->phys_addr) >> EFI_PAGE_SHIFT;
+
+ /* Do memmove manually */
+ for (tmp_md = next_md; tmp_md <
+ (void *)params->efi_memmap_base +
+ boot_param->efi_memmap_size;
+ tmp_md = (void *)tmp_md + boot_param->efi_memdesc_size) {
+ memcpy(tmp_md, (void *)tmp_md +
+ boot_param->efi_memdesc_size,
+ boot_param->efi_memdesc_size);
+ }
+ boot_param->efi_memmap_size -= boot_param->efi_memdesc_size;
+ }
+
+}
+
void
patch_efi_memmap(struct kexec_boot_params *params,
struct ia64_boot_param *boot_param)
@@ -217,6 +256,7 @@
}
boot_param->efi_memmap_size = dest - (void *)params->efi_memmap_base;
+ merge_efi_memmap(params, boot_param);
}
void
-
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
|