Re: [bug] mm/slab.c boot crash in -git, "kernel BUG at mm/slab.c:2103!"

[Ingo Molnar <mingo@elte.hu>]

* 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