Subject: Re: spl priority inversion in NetBSD/arm
To: Toru Nishimura <email@example.com>
From: Jesse Off <joff@embeddedARM.com>
Date: 12/28/2004 22:02:46
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.
> 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