Mail Archives: djgpp/2002/10/11/10:18:15
> > > Ouch. Try removing the enable (and the disable).
> > > The enable would let a
> > > second interrupt hit the wrapper before the first one was clear.
>
> > Bingo! This appears to be the biggest source of our problems. We
> > removed these lines from the handler, and things improved
> > dramatically, although I'm not completely sure I understand why.
> > Doesn't the interrupt controller prevent "simultaneous" interrupts
> > anyway?
>
> This happens after you send the EOI to the controller. There are
> several dozen instructions that need to be executed before you get
> out of your routine (and the wrapper) after the STI happens. If a
> second interrupt is pending then it would immediately trigger.
>
Isn't this the case even if I don't disable/enable? I'm still
sending the EOI to the controller. What keeps it from issuing the next
interrupt in this case? Is this something specific to using the
interrupt wrappers? I've seen many examples of interrupt handlers (not
DJGPP/DPMI) that start with disable() and end with enable(). What's
different here?
As I said in the last e-mail, everything is working great now (the stress
test ran overnight with no problems), but I'd like to understand what's
going on a little more completely.
- Raw text -