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

["René van der Meer" <moonchildren%gmail.com@localhost>]

Guys,

 

Thanks for all of your effort but I have given up the version 20080420-UTC  I have tried boots over NFS and no problems there.

But I couldn't disklabel , mkfs, with sysinst, sysinst remain in a sort of hanging state no activity.

 

Created partitions and filesystems by hand and then the sysinst was hanging (no activity) on the extraction of the packages.

Obviously NetBSD on nslu2 isn't ready for me jet.

 

I will come back in a few month's to check this out again because this will serv my needs.

 

Kind Regards to you all and keep up the good work.

 

René

    

 

On 5/8/08, Rafal Boni <rafal%pobox.com@localhost> wrote:

Donald T Hayford wrote:

 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 feel your pain; I'm trying to untangle the whole ARM rototillage to get my Jornada 720 (port-hpcarm) working again, and don't yet have enough clue to what's needed there, never mind for the Slug, which I don't own.

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.

Yeah, that seems very unlikely, and the large number of 'S'es printed (each represents a 1MB VM "section" used for the mapping... that's a lot of MB's there used to mak your < 3MB kernel!) also is definitely a sign that something is wrong.  I think the poster on the list who said "VA mismatch" probably wins the prize..

Mapping kernel
pmap_map_chunk: pa=0x10200000 va=0x80200000 size=0x4022f000 resid=0x4022f000 prot=0x3 cache=1
SSSSSSSSSSSSSSSSSS[...] panic: pmap_map_chunk: no L2 table for VA
0xc0400000

Can you do a 'readelf -e' on the two kernels (working vs. non-working) to see if we're on the right track?  If you don't have a 'readelf' on your build host (or it behaves differently than the NetBSD one), you can always run objdump out of your tooldir like so:

       $TOOLDIR/arm--netbsdelf/bin/objdump -f -p -h netbsd

Thanks!
--rafal