Re: panic: pmap_map_chunk: no L2 table for VA 0xc0400000

[Donald T Hayford <don%donhayford.com@localhost>]

Rafal Boni wrote:
> Steve Woodford wrote:
> > On Sunday 04 May 2008 05:51:48 Donald T Hayford wrote:
> > > moonchildren wrote:
> >
> > > > But after a days work which I enjoyed  I got nothing but  a error
> > > > about L2  ?
> >
> > This error is the result of the install kernel image being too large 
> > for the number of statically allocated (at boot time) L2 entries.
> >
> > It was always my intention to make this runtime-configurable 
> > according to the kernel size, but I ran out of round tuits.
> >
> > The fix is a simple source modification, but I don't have the details 
> > offhand. I'll try to recall what it is and get back to you.
>
> See e.g. 
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/hpcarm/hpcarm/hpc_machdep.c.diff?r1=1.83&r2=1.84&f=h 
>
>
> For the NSLU2 all you should need to do is bump KERNEL_PT_KERNEL_NUM 
> in sys/arch/evbarm/nslu2/nslu2_machdep.c (make it 6, for example).  
> The nicer fix is to steal the auto-tuning code from (IIRC) the evbarm 
> generic init_arm() code [common_init_arm?], so you don't have to keep 
> doing this, but the 1st fix is definitely effective.
>
> Wasn't the fact that it spat out that many 'S'es worrisome?  It's a 
> section supposed to map a whole 1MB chunk?  Maybe that's a red herring 
> though.
>
> --rafal
From what I can see, there were a lot of changes in the arch/arm/arm32 
source tree in the time between when the slug would boot properly and 
when it stopped.  While I'm happy to try to work through these to see if 
I can find which particular change is causing the problem (assuming 
there is only one), I can tell you that will take some time.  So, if 
somebody has some particular suggestions (relatively detailed, but I can 
more or less figure them out), I'll be happy to give them a shot.

I can tell you that the file size of the image that works is 2,796,648 
bytes long and the size of the image that doesn't work is 2,797,016, a 
difference of 368 bytes.  So, while it might be that the new kernel is 
too large, it seems unlikely.  Changing KERNEL_PT_KERNEL_NUM to 6 
resulted in the following error message during bootup - roughly the same 
as before, though the stack address are larger, presumably because of 
the increase in L2 size.

NetBSD/evbarm (Linksys NSLU2) booting ...
kernsize=0x402e0164
physmemory: 8192 pages at 0x10000000 -> 0x11ffffff
Allocating page tables
physical_start = 0x10000000, physical_end = 0x12000000
IRQ stack: p0x10011000 v0x80011000
ABT stack: p0x10012000 v0x80012000
UND stack: p0x10013000 v0x80013000
SVC stack: p0x10014000 v0x80014000
Creating L1 page table at 0x10000000
Mapping kernel
pmap_map_chunk: pa=0x10200000 va=0x80200000 size=0x4022f000 
resid=0x4022f000 prot=0x3 cache=1
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSpanic: pmap_map_chunk: no L2 table for VA 
0xc0400000

Thanks, Don