On Feb 26, 2006, at 6:22 AM, Cherry George Mathew wrote:
I'm not sure if you're familiar with NetBSD's uvm, but I'm trying to get some quick tips about this one ( kernel dmesg below ).
I'm not familiar with NetBSD's UVM, so I may need some clueing in.
Kernel is Page Faulting with "Not Present". I suspect this is too early for anything really complicated, so either: - pmap_enter_vhpt() didn't do its job.
pmap_enter_vhpt() is a bit weird in that it really doesn't put the translation in the TC. It just adds the translation to the VHPT and takes a second trap to put it in the TC. This is really bogus as it just adds overhead. It's simpler though. In any case: pmap_enter_vhpt() may have done its job, but the second trap may not have found the translation in the VHPT. I don't know if exception.S has been taken verbatim...
- UVM is trying to fault in a kernel page ???!!!! Isn't this what pmap_growkernel is for ?
pmap_growkernel() is called by UVM if more kernel VM is needed, yes. I presume that there's some initial amount of kernel VM and that there's a pool of PTEs for it from which to draw. This doesn't look like a problem because you get a "Page Not Present", not some VM related error that it has ran out of kernel VM.
- pmap_kenter_pa() screwed up with pte's
Dunno. Doesn't look like it.
Also: This might be a really dumb question, but can you tell me why we need a Region 5 vhpt mapped region, when we already have a direct mapped Region 7 region ? Its not immediately obvious to me.
Region 5 is the region for "normal" kernel virtual memory, in the same way that regions 0-4 are for user space virtual memory. Regions 6 & 7 are direct mapped and are mostly used to 1) provide non-cached virtual memory references to bus space (i.e. region 6) or cached virtual memory references to critical data-structures, such as the VHPT itself (i.e. region 7). Put differently region 5 is where VM managed memory comes from, while region 6 and 7 are used by the machine dependent implementation to support the MI functionality.
http://cherry.zyx.in/downloads/netbsd-anvil/pmap-debug/260206.pmap.c
Looking at pmap.c, I can't see any obvious clues. The first thing to do is figure out if the trap is normal or not. If it is, then the problem is in handling the trap and not in having the trap itself. Unfortunately, I can't determine that from the backtrace or pmap.c
trap vector = 0x14 (Page Not Present)
cr.iip = 0xe00000000414d900
cr.ipsr = 0x1010080a2010 (mfl,ic,dt,dfh,rt,cpl=0,it,ri=0,bn)
cr.isr = 0x200000000 (code=0,vector=0,w,ei=0)
cr.ifa = 0xa0000000000040b4
curlwp = 0xe000000004207a00
pid = 0, comm =
The IFA looks normal enough though. I presume the page size is 8KB? The advantage of using SKI is that you can set breakpoints and step though the execution. The thing to do is, is to find out what the memory address represents (i.e. what data structure), and how it got put there. I need to dig into the code more before I can be more helpful, I fear. HTH, BTW: I'm actually thinking that a 16KB page is slightly better, simply because ia64 has a relatively big dataset set on average. I think Linux also uses 16KB pages by default. Unfortunately, switching the page size to 16KB on FreeBSD is not that easy WRT backward compatibility. You're in a perfect position right now to switch to 16KB pages. Just a thought. -- Marcel Moolenaar USPA: A-39004 marcel%xcllnt.net@localhost
Attachment:
smime.p7s
Description: S/MIME cryptographic signature