Subject: Re: blocked interrupts (was CVS commit: src/sys/arch/arc)
To: None <darkstar@city-net.com>
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
List: port-mips
Date: 11/18/2005 21:08:53
In article <Pine.BSF.4.51.0511171937070.71369@vegeta.city-net.com>
darkstar@city-net.com wrote:

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

That what the item in arc/TODO said.

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

Also noted in arc/TODO:
>	-   MIPS3_CLKF_BASEPRI() doesn't work correctly,
>	    when MIPS_INT_MASK_5 (== MIPS_INT_MASK_CLOCK) is disabled.
>		-> micro optimization on hardclock() doesn't work.
>		   but currently this may make hardclock() latency better
>		   due to above SR_INT_IE problem.
>	    s/MIPS_INT_MASK/MIPS3_INT_MASK/ makes this work, although tricky.
if the port doesn't have options MIPS3_ENABLE_CLOCK_INTR,
spllowerclock() never happens in hardclock(9)  because CLKF_BASEPRI()
is defined as
        ((~(framep)->sr & (MIPS_INT_MASK | MIPS_SR_INT_IE)) == 0)
in <mips/cpu.h> and MIPS_INT_MASK_5 is not set in those ports.
---
Izumi Tsutsui