www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2002/10/11/10:18:15

Message-ID: <BDD73AE8AEE3EF438E07420C2600E9F65C9194@qtiexch0.qgraph.com>
From: "Sisco, Michael" <mdsisco AT qtiworld DOT com>
To: "'sandmann AT clio DOT rice DOT edu'" <sandmann AT clio DOT rice DOT edu>
Cc: djgpp AT delorie DOT com
Subject: RE: Int 0x22???
Date: Fri, 11 Oct 2002 09:16:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Reply-To: djgpp AT delorie DOT com

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


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019