high priority interrupts disabled - problem found

Steve Rossi srossi at labs.mot.com
Thu Dec 13 10:09:40 EST 2001

Here's another update for anyone interested:

Steve Rossi wrote:

> ...Is there a mechanism by which
> all lower priority interrupts are disabled when a higher priority one is running?

This is exactly the problem. I was able to run with data show-cycles enabled so
I could trace exactly what was happening with the SIVEC, SIMASK & SIPEND. Here's the
situation that causes the problem I described in earlier posts:
The hard disk interrupt (IRQ6) does data transfer in the ISR itself - as a result
the ISRs are very long, and furthermore, the interrupt signal is asserted again
before the service routine is exited and IRQ6 is unmasked - so as a result, as soon
as its unmasked, it causes a new interrupt to the core and IRQ6 is entered again.

Take the situation where IRQ2 becomes active between the time when IRQ6 is unmasked,
but before the next pending IRQ6 is entered. SIVEC is read, and indicates IRQ2, IRQ2
is masked & acked, then since IRQ2 is NOT flagged with SA_INTERRUPT, the interrupts
to the core are enabled. Immediately, the core recognizes that IRQ6 is pending and
unmasked so it begins to service it. Essentially IRQ6 pre-empted IRQ2, IRQ2 is
masked out. IRQ6 will run, unmask, interrupt again, mask, run, unmask, interrupt
again ... etc until the complete transfer to the disk is done. Only when there is no
longer any other interrupts pending will the IRQ2 which was preempted earlier finish
running - many milliseconds after IRQ2 was triggered.

So the problem is that mask & ack only masks the pending interrupts when I believe
it should mask the pending interrupts and all interrupts that are lower priority
than it. Conversely unmask should unmask the given interrupt and all interrupts of
lower priority that were previously unmasked when mask&ack was called. Is that right
or am I missing something here?


Steven K. Rossi                     srossi at labs.mot.com
Staff Engineer
Multimedia Communications Research Laboratory
Motorola Labs

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

More information about the Linuxppc-embedded mailing list