I found my problem (I think).. not sure if its the same one you're seeing.
 I had a potential interrupt handler recursion that could happen in a ~10
insn window in the interrupt dispatch routine.  Interrupts are re-enabled
momentarily before handling soft interrupts right before returning from
the intr_dispatch().  My condition is unique in that I happen to have an
interrupt handler that doesn't seem to always succeed in completely
handling and therefore de-asserting the interrupt (resulting in going
right back into the IRQ vector the moment interrupts are re-enabled). 
Conceivably, this could also happen with high-rate interrupt source, so I
bet the code I derived the ep93xx_intr.c from has this issue as well, even
though it probably would be difficult to coax into a stack overflow.

//Jesse Off

> 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
>
>