kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!

[Nathan Lynch]

Will Schmidt wrote:
> On Fri, 2006-13-10 at 14:53 -0500, Will Schmidt wrote:
> > On Fri, 2006-13-10 at 12:05 -0700, Christoph Lameter wrote:
> > > On Fri, 13 Oct 2006, Will Schmidt wrote:
> > > 
> > > >     Am seeing a crash on a power5 LPAR when booting the linux-2.6 git
> > > > tree.  It's fairly early during boot, so I've included the whole log
> > > > below.   This partition has 8 procs, (shared, including threads), and
> > > > 512M RAM.  
> > > 
> > > This looks like slab bootstrap. You are bootstrapping while having 
> > > zonelists build with zones that are only going to be populated later? 
> > > This will lead to incorrect NUMA placement of lots of slab structures on 
> > > bootup.
> > 
> > I dont think so..   but it's not an area I'm very familiar with.   one
> > of the other PPC folks might chime in with something here.  
> > 
> > > 
> > > Check if the patch below may cure the oops. Your memory is likely 
> > > still placed on the wrong numa nodes since we have to fallback from 
> > > the intended node.
> > 
> > Nope, no change with this patch.
> > 
> 
> Here is another boot log, with that patch applied, and with a numa=debug
> parm. 
> 
> -----------------------------------------------------
> ppc64_pft_size                = 0x18
> physicalMemorySize            = 0x22000000
> ppc64_caches.dcache_line_size = 0x80
> ppc64_caches.icache_line_size = 0x80
> htab_address                  = 0x0000000000000000
> htab_hash_mask                = 0x1ffff
> -----------------------------------------------------
> Linux version 2.6.19-rc1-gb8a3ad5b-dirty (willschm at airbag2) (gcc version
> 4.1.0 (SUSE Linux)) #60 SMP Fri Oct 13 14:48:20 CDT 2006
> [boot]0012 Setup Arch
> NUMA associativity depth for CPU/Memory: 3
> adding cpu 0 to node 0
> node 0
> NODE_DATA() = c000000015ffee80
> start_paddr = 8000000
> end_paddr = 16000000
> bootmap_paddr = 15ffc000
> reserve_bootmem ffc0000 40000
> reserve_bootmem 15ffc000 2000
> reserve_bootmem 15ffee80 1180
> node 1
> NODE_DATA() = c000000021ff7c80
> start_paddr = 0
> end_paddr = 22000000

Strange, node 0 appears to be in the middle of node 1.