re: evbarm hang

[matthew green <mrg%eterna.com.au@localhost>]

> So here's our deadlock: cpu 0 holds the kernel lock and wants the pool spin
> mutex; cpu 1 holds the spin mutex and wants the kenrel lock.

AFAICT, cpu 1 is at fault here.  this locking order is
backwards.

not sure why arm32 pmap operations on the kernel map are
with the kernel lock instead of another lock.  the arm64
version of this code doesn't take any lock.


.mrg.