Re: Early crash on SB2000 (panic: init: no memory

On Tue, 30 Oct 2012, Julian Coleman wrote:

> Hi,
> 
> > I assume you dumped this before booting?
> 
> Yes.
> 
> > Could you boot with -d and when you get to DDB drop to the PROM and dump 
> > the /memory available property when booting both from disk and from the 
> > network?  And if it's possible to do the same from ofwboot just before it 
> > jumps into the kernel that would also be helpful.
> 
> > I'm guessing that the ofwboot logic that makes sure the kernel is aligned 
> > to a 4MB page has a math problem that's corrupting OBP's free list.
> 
> Booting to ddb across the network gives:
> 
> available                00000001 ffe8c000 00000000 00014000 
>                          00000001 ffe70000 00000000 0000a000 
>                          00000001 ffdb0000 00000000 000a0000 
>                          00000001 ffc00000 00000000 001a0000 
>                          00000001 fec00000 00000000 003fe000 
>                          00000001 fe008000 00000000 007f8000 
>                          00000000 00000000 00000001 fe000000 
> 
> I managed to stop it just after the line:
>   Loading netbsd: 9168736+550632+326656 [606696+406275]=0xdce098
> and it showed:
> available                00000001 ffe8c000 00000000 0001e000 
>                          00000001 ffdb0000 00000000 000c0000 
>                          00000001 ffc00000 00000000 001a0000 
>                          00000001 fec00000 00000000 003fe000 
>                          00000001 fe008000 00000000 007f8000 
>                          00000000 00000000 00000001 fe000000 
> 
> Strangely, when I continued, it booted OK and showed:
> available                00000001 ffe8c000 00000000 00004000 
>                          00000001 ffdb0000 00000000 000a0000 
>                          00000001 ffc00000 00000000 001a0000 
>                          00000001 fec00000 00000000 003fe000 
>                          00000001 fe008000 00000000 007f8000 
>                          00000000 00000000 00000001 fe000000 
> 
> When it fails to boot from disk:
> 
> available                00000001 ffe8c000 00000000 00004000 
>                          00000001 ffdb0000 00000000 000a0000 
>                          00000001 ffc00000 00000000 001a0000 
>                          00000001 fec00000 00000000 003fe000 
>                          00000001 fe008000 00000000 007f8000 
>                          00000000 00000000 00000001 fe000000 

Is this after the failed pmap_read_memlist() call?

> 
> However, it looks like the large block of memory is there in all cases.
> 
> Looking at the debug output in this last case, I see:
> 
>   prom_memlist_size = 96
>   pcnt = 6
>   Available physical memory:
>   kdata_alloc(): Allocated 96@0x1ed05f0, 1243568 free.
>   memlist start 1ffea0000 size 2000
>   memlist start 1ffe8c000 size 4000
>   memlist start 1ffdb0000 size a0000
>   memlist start 1ffc00000 size 1a0000
>   memlist start 1fec00000 size 3fe000
>   memlist start 1fe008000 size 7f8000
>   End of available physical memory
> 
> It looks like we expect 6 ranges, as there are in the memory dump above,
> but there is an extra range inserted at the start, so we have lost the
> main block of memory at the end.  I'll add some debugging to
> pmap_read_memlist() and see what I can see.

I've been reviewing the code and the only way I can see this happening is 
if somehow the 1ffea0000,2000 entry is added to the property between the 
OF_getproplen() call and the OF_getprop() call.  That shouldn't happen.

I suppose you could change the OF_getproplen() routine to do a "getprop" 
call with a zero buflen parameter.  The return from "getprop" should be 
the size of the property.

Or change pmap_read_memlist() to compare the return value from the 
OF_getproplen() with the requested size and if the return is larger free 
up the memory and try again with a larger size.

Eduardo