Subject: Re: blocked interrupts (was CVS commit: src/sys/arch/arc)
To: None <email@example.com>
From: Izumi Tsutsui <firstname.lastname@example.org>
Date: 11/18/2005 21:08:53
In article <Pine.BSF.email@example.com>
> 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
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.