> 
> Have any of you seen this behaviour before? or have a clue as to where to
> find it ? I suspect its in the vidcconsole and/or pmap for i've seen some
> DIAGNOSTIC stuff there that might take this time too.

A profiling kernel might help.  

There are some nasty diagnostics in pmap.c, which should probably be moved 
to DEBUG.

arm32/pmap.c:
#ifdef DIAGNOSTIC
                for (npv = pv; npv; npv = npv->pv_next)
                        if (pmap == npv->pv_pmap && va == npv->pv_va)
                                panic("pmap_enter_pv: already in pv_tab pv 
%p: %
08lx/%p/%p",
                                    pv, pv->pv_va, pv->pv_pmap, pv->
pv_next);
#endif

...

[there seem to be 3 cases like this one, note it uses vm_physseg_find, 
which is horrendously expensive (does a binary search)!]
#ifdef DIAGNOSTIC
        int bank, off;

        if ((bank = vm_physseg_find(atop(pa), &off)) != -1) {
                struct pv_entry *pv;
                
                pv = &vm_physmem[bank].pmseg.pvent[off];
                if (pv->pv_pmap != NULL)
                        panic("pmap_kenter_pa: %08lx multiply mapped\n", 
pa);
        }
#endif

R.