2.6.15 failure on power4 iSeries

[Michael Ellerman]

On Fri, 20 Jan 2006 10:56, you wrote:
> 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.

That's curious. :)

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

Yeah that's normal, people are reserving memory as we go and so the reserved 
stuff changes. You shouldn't see the memory.* stuff changing though.

> 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

So it thinks you've got just under 1G of RAM, is that about right?

The reserved region will be the kernel text I think.

> 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

That last reserved region looks bogus (obviously). It'd be _really_ 
interesting to know who's adding that. You might be able to hack something 
with DBG to print __builtin_return_address() or whatever it is, to get the 
caller of lmb_reserve.

> 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.

Yep, it's pretty new. We could hack up iSeries early debug for older kernels 
if we wanted, what's the latest kernel that worked?

> 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? )

Yeah that looks weird doesn't it. I'm internet caf'ing it at the moment, so 
will have a look tonight and get back to you.

cheers

-- 
Michael Ellerman
IBM OzLabs

email: michael:ellerman.id.au
inmsg: mpe:jabber.org
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20060121/4f3cd0c2/attachment.pgp