2.6.15 failure on power4 iSeries

will schmidt will_schmidt at vnet.ibm.com
Fri Jan 20 08:56:14 EST 2006


Michael Ellerman wrote:
> On Thu, 19 Jan 2006 09:07, will schmidt wrote:
> 
>>>looks like setup_arch() calls into do_init_bootmem() which loops around a
>>>reserve_bootmem() call.   the last call into reserve_bootmem isnt
>>>returning.
> 
> 
>>>-> reserve_bootmem ( 3c800000 0 4
> 
> 
> It shoud hit BUG_ON(!size) (in reserve_bootmem_core()), perhaps it is but
> we're just not seeing it?

Yeah, i followed code to that BUG call.. i'm not seeing any bug or panic message.

> 
> 
>>the code making the last call into lmb_alloc looks like:
>>       DBG("-> do_init_bootmem %d\n",__LINE__);
>>         bootmap_pages = bootmem_bootmap_pages(total_pages);
>>
>>         DBG("-> do_init_bootmem %d\n",__LINE__);
>>         start = lmb_alloc(bootmap_pages << PAGE_SHIFT, PAGE_SIZE);   /*
>>wms */ BUG_ON(!start);
>>
>>         boot_mapsize = init_bootmem(start >> PAGE_SHIFT, total_pages);
>>
>>
>>I think we call direct into lmb_alloc_base most of the time,..  so the
>>difference with this call is the LMB_ALLOC_ANYWHERE parm..
>>
>>unsigned long __init lmb_alloc(unsigned long size, unsigned long align)
>>{
>>         return lmb_alloc_base(size, align, LMB_ALLOC_ANYWHERE);
>>}
>>
>>LMB_ALLOC_ANYWHERE looks to have a value of 0. 
>>"include/asm-powerpc/lmb.h:#define LMB_ALLOC_ANYWHERE    0"
>>
>>I am not very familiar with this code..  dont know if the '0' here is
>>mistakenly mapped to a size, or if this 0 is a red herring.
> 
> 
> I think that's fine. LMB_ALLOC_ANYWHERE just constrains where the alloc comes
> from. For example if you need an alloc within the RMO.
> 
> Try this patch to dump the lmbs. Might be good to compare the output of this to
> the same from a known good kernel.
> 
> cheers
> 

turning on the lmb_dump_all func returns different values depending on how far we've gotten.

Initially it returns this: just after entry to early_setup()
lmb_dump_all:
     memory.cnt            = 0x1
     memory.size           = 0x3c800000
     memory.region[0x0].base       = 0x0
                       .size     = 0x3c800000

     reserved.cnt          = 0x1
     reserved.size         = 0x0
     reserved.region[0x0].base       = 0x0
                       .size     = 0x500e80

just before we call into do_init_bootmem, looks more like this:
lmb_dump_all:
     memory.cnt            = 0x1
     memory.size           = 0x3c800000
     memory.region[0x0].base       = 0x0
                       .size     = 0x3c800000

     reserved.cnt          = 0x4
     reserved.size         = 0x0
     reserved.region[0x0].base       = 0x0
                       .size     = 0x500e80
     reserved.region[0x1].base       = 0xffe5000
                       .size     = 0x1b000
     reserved.region[0x2].base       = 0x3c7ff668
                       .size     = 0x994
     reserved.region[0x3].base       = 0x3c800000
                       .size     = 0x0



Tried adding this debug to an earlier working kernel, but wasnt able to get output.
I think i'm at a point before the CONFIG_PPC_EARLY_DEBUG_ISERIES config option existed.

notice that the partition memory size happens to be the same as the .base of our last region.  (memory.size , and physicalMemorySize value)
(is there a bad assumption somewhere and we're squishing the size with lmb_enforce_memory_limit()?, or the overlaps_region? )

-----------------------------------------------------
ppc64_pft_size                = 0x19
ppc64_interrupt_controller    = 0x4
platform                      = 0x201
physicalMemorySize            = 0x3c800000     <---
ppc64_caches.dcache_line_size = 0x80
ppc64_caches.icache_line_size = 0x80
htab_address                  = 0x0000000000000000
htab_hash_mask                = 0x3ffff
-----------------------------------------------------

-Will



More information about the Linuxppc64-dev mailing list