Messages in this thread | | | Date | Tue, 15 Apr 2008 12:03:05 +0200 | From | Ingo Molnar <> | Subject | Re: [bug] mm/slab.c boot crash in -git, "kernel BUG at mm/slab.c:2103!" |
| |
* Mel Gorman <mel@csn.ul.ie> wrote:
> [ 0.000000] Warning only 4GB will be used. > [ 0.000000] Use a HIGHMEM64G enabled kernel. > [ 0.000000] Entering add_active_range(0, 0, 1048576) 0 entries of 256 used > > It's recognised and only memory below 4GB is registered and it's all > on node 0. However, I do note that it also registers all the holes as > valid memory. The memory should never get freed because it should be > reserved during boot by reserve_bootmem() but it still raises an > eyebrow.
32-bit does memory_present() calls to register all RAM - and those calls are correct (they do not include holes) and the resulting sparse memory section layout looks correct, and all the mem_map[] chunk allocations succeed as well.
furthermore, when freeing memory from bootmem allocator into the buddy allocator we consult the e820 map again via a page_is_ram() call, so we make sure holes do not end up in the memory map and in the free page pool. (all rounded to section boundaries of course)
> [ 0.000000] early_node_map[1] active PFN ranges > [ 0.000000] 0: 0 -> 1048576 > [ 0.000000] On node 0 totalpages: 1048576 > [ 0.000000] DMA zone: 32 pages used for memmap > [ 0.000000] DMA zone: 0 pages reserved > [ 0.000000] DMA zone: 4064 pages, LIFO batch:0 > [ 0.000000] Normal zone: 1760 pages used for memmap > [ 0.000000] Normal zone: 223520 pages, LIFO batch:31 > [ 0.000000] HighMem zone: 6400 pages used for memmap > [ 0.000000] HighMem zone: 812800 pages, LIFO batch:31 > [ 0.000000] Movable zone: 0 pages used for memmap > > And from this, it looks like memmap is getting setup. So far, it looks > like basic initialisation was ok.
yep. I did a few extra printouts to make sure, but came to the same conclusion. The system boots fine with the same config on v2.6.24.
Ingo
| |