On (18/12/07 13:03), Thomas Bogendoerfer didst pronounce: > When using FLAT_MEMORY and ARCH_PFN_OFFSET is not 0, the kernel > crashes in memmap_init_zone(). This bug got introduced by > commit c713216deebd95d2b0ab38fef8bb2361c0180c2d >
That commit is over a year old and it initially distressed me that it would take this long to show up on a boot test. However, you said this was to fix MIPS in a follow-on mail and I never made it use arch-independent zone-sizing which is where CONFIG_ARCH_POPULATES_NODE_MAP comes from. Support for arch-independent zone-sizing was added for MIPS on Nov 3rd 2007 by commit cce335ae47e231398269fb05fa48e0e9cbf289e0 (relevant cc added) which is a much more reasonable timeframe for catching this sort of problem. I believe the real bug might be in there. Can you post a full dmesg log with loglevel=8 so I can see what the layout looks like? My aim is to find out why the start of your mem_map is not at the start of node 0's mem_map which is what I generally expected with the FLATMEM model. Thanks. > Signed-off-by: Thomas Bogendoerfer <[EMAIL PROTECTED]> > --- > > mm/page_alloc.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index b5a58d4..496f7f3 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -3427,7 +3427,7 @@ static void __init_refok alloc_node_mem_map(struct > pglist_data *pgdat) > mem_map = NODE_DATA(0)->node_mem_map; > #ifdef CONFIG_ARCH_POPULATES_NODE_MAP > if (page_to_pfn(mem_map) != pgdat->node_start_pfn) > - mem_map -= pgdat->node_start_pfn; > + mem_map -= (pgdat->node_start_pfn - ARCH_PFN_OFFSET); > #endif /* CONFIG_ARCH_POPULATES_NODE_MAP */ > } > #endif > -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
