Subject: Re: blocked interrupts (was CVS commit: src/sys/arch/arc)
To: Simon Burge <simonb@wasabisystems.com>
From: Matthew Orgass <darkstar@city-net.com>
List: port-mips
Date: 11/17/2005 20:23:03
On 2005-11-18 simonb@wasabisystems.com wrote:

> I believe algor, evbmips and pmax get this right.  In these ports,
> cpu_intr() calls a machine-specific *_iointr(), and all these
> machine-specific functions all finish with an _splset() to reenable
> any processed interrupts.

  No, pmax doesn't reenable processed interrupts (at least the 3min and
3max I looked at); it is (status & ~cause & MIPS_HARD_INT_MASK), which
reenables the interrupts not processed.  Soft interrupts will then proceed
without further altering the interrupt mask (and if any of the
non-processed interrupts occur the processed interrupts will remain
blocked until the other (potentially lower priority) interrupts complete.

  I see now where the hpcmips interrupt problems came from :/.  I don't
think pmax has the "lower priority interrupts during hardclock" problem
that hpcmips had since pmax only does it after processing the interrupts,
but it can block high priority interrupts during lower priority
interrupts.

  It is also important that the lowest priority pending interrupt not be
reenabled before returning, since that would allow the stack to overflow
with sufficiently high interrupt rate.  IMO, the easiest way to be certain
everything is correct is a strict priority with all higher priority
interrupts enabled just before processing an interrupt (this is what
hpcmips now does).

Matthew Orgass
darkstar@city-net.com