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

[Julian Coleman <jdc%coris.org.uk@localhost>]

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 

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.

Thanks,

J

-- 
   NetBSD: simple; works; documented    /        Sailing at Newbiggin
        http://www.netbsd.org/        /   http://www.newbigginsailingclub.org/