I found a plain obvious evidence that spl inversion can really
happen.   Due to the unknown reason some interrupt(s) is left
blocked forever, in particular, softintr() is not re-activated.  I start
suspecting that serial->soft_serial or net->soft_net controlling
path can go wild and wreck intr_enabled variable badly.  There
are two distinct softintr() implementations in NetBSD/arm.   One
is to use software initiated interrupt with the help of hardware.
Another is genuine software construct to imiate hardware interrupt
contexts.   My case is the former and resulted in intr_enabled
variable blocks softintr bit forever.  So, People who are responsible
any of evbarm ports, PLS take a look at your *intr.[ch] code.  I know
considerable amount of care has been done to make sure IRQ/IPL do
the right things but it works wrong, sometimes.  It would explain the
case of Jesse Off experiences too.

Toru Nishimura/ALKYL Technology