伪中断

"If no interrupt request is present at step 4 of either sequence
(i.e., the request was too short in duration) the 8259A will
issue an interrupt level 7. Both the vectoring bytes and the CAS
lines will look like an interrupt level 7 was requested."

This explains how some transient disturbances or improperly
functioning adapter cards could trigger a stray interrupt 7
in a system operating in the *level* interrupt mode (such as
a PS/2 with MCA): An interrupt request will disappear as soon
as the interrupt line goes inactive.

That such interrupts may also occur in a system operating in
the *edge* triggered mode (such as an ordinary PC/AT with ISA)
is a little harder to see. Yet it is possible - even without
malfunctioning hardware - because masking an interrupt request
will hide its presence from the 8259A as well:


1. The interrupt flag (IF) of the 80x86 is reset either
directly (e.g., by a "cli" instruction) or because an
interrupt handler is entered. In the latter case the
corresponding in-service (IS) bit of the 8259A is set
(effectively blocking interrupts of lower priority).

2. The 8259A receives an unmasked interrupt request (IRQn),
and, in case an interrupt is being served and has higher
priority than IRQn, the IS bit of the 8259A is reset by
an end of interrupt (EOI) command. (These steps may occur
in either order.) If IRQn has higher priority (e.g. IRQ0),
no EOI is necessary.

3. The 8259A activates the interrupt (INT) line to the 80x86
(which will ignore it - for the moment).

4. The interrupt mask (IM) bit of the 8259A for IRQn is set.
(A little late, though. The sequence has already started.)

5. The interrupt flag (IF) of the 80x86 is set (either
directly, or as a consequence of e.g. an "iret" instruction).

6. The 80x86 will now acknowledge the INT request by activating
the INTA line of the 8259A.

7. The 8259A will not see the masked IRQn and will continue
by issuing a spurious interrupt of level 7 instead.


The original interrupt request (IRQn) will not be lost, however.
It is preserved by the associated edge sense latch of the 8259A,
and will be acted on after the IM bit has been reset again.

The net result is that a single interrupt request will be
delivered *twice* to the 80x86: first as a stray interrupt 7
and later as the proper interrupt. In particular, it is perfectly
safe to ignore the stray interrupt (other than sending an EOI).
It is just the ghost of an aborted interrupt sequence: the system
was not prepared for it yet.

Bill Roman provides this update, which is so technical I can't
even figure out what to cut out or how to repackage it so it
makes sense to people like me.  As an interesting aside, he is
also a Linux user; thereby proving that I'll accept help the FAQ
from everyone:

First of all, Kalevi Suominen's explanation is correct, but
requires just a little more explanation.  Step 4 in the data
book concerns the 8259's detection of INTA (interrupt
acknowledge) asserted by the processor.  This means that the
processor has detected INT (interrupt request) asserted by the
8259, the previous instruction has ended, and the interrupt
enable flag is true.  The processor has begun its interrupt
processing, and the 8259 *must* supply a vector; there is no way
for it to tell the processor "never mind".

INTA causes the 8259 to examine the currently asserted interrupt
requests and return the vector corresponding to the highest
current request.  If there is no longer any interrupt request
asserted, it supplies vector 7 as a default.  (Intel calls this
"DEFAULT IR7" later in the data book.)

There is thus a race condition between deassertion of an interrupt
request and interrupt servicing by the processor.  An interrupt
request which is removed will not always cause DEFAULT IR7 --
only if the request is deasserted after the processor has
detected INT and irrevocably decided to act on it, but before
the 8259 has detected INTA and prioritized its interrupts.

It is easy to see how this could happen when the 8259 is in
level triggered mode, but it is counterintuitive that it should
happen in edge triggered mode.  To understand this, it is
necessary to look at Intel's "Priority Cell--Simplified Logic
Diagram" (figure 9 in a 1991 databook I have at hand).  The edge
sense latch output is gated by the request; if the request is
latched, then deasserted, the 8259 no longer sees it.  There
must be a reason Intel did it this way, but it's sure not
evident to me.

The data book provides a little more information in a later
section titled "Edge and Level Triggered Modes".  The most
important point is that the corresponding bit in the In Service
Register is *not* set when the 8259 generates a DEFAULT IR7.  If
the IRQ 7 interrupt service routine sees this condition (i.e.,
is entered and ISR bit 7 is zero) it should simply execute an
interrupt return instruction without sending an End of
Interrupt (EOI) command to the 8259.  Also, the IRQ 7 interrupt
service routine can be reentered due to this condition.  Intel
recommends that the interrupt service routine keep track of
whether it is currently active so this can be detected.

I don't think that changing the interrupt mask bit can cause the
problem, especially if it is changed while the interrupt flag is
clear.  As I mentioned, the problem occurs only when the actual
interrupt acknowledge process has begun, which can't happen while
IF is clear.

What can generate DEFAULT IR7 is a device driver that doesn't mask
off its device's interrupt (either in the 8259 or in the device
itself) while it is performing operations which can cause the
device to deassert its interrupt request.  For example: imagine
a hypothetical device with an interrupt status register.  This
register latches all the device's status which could cause an
interrupt, and clears this status when it is read.  If the
processor begins executing the instruction which reads this
register just as a status bit is set, the device will assert
and deassert the request within the space of that instruction.
On an x86 architecture processor I have worked with, this did
indeed generate a DEFAULT IR7.  All device drivers should make
sure that the device's interrupt request is disabled while the
device is being serviced.  A well-behaved device will never
deassert its request without explicit software action.

This leaves only the poor folks who have had to buy new computers
to get rid of the problem.  My suspicion in this case is that
crosstalk on the mainboard is causing glitches on interrupt
request lines.  Remember that the f**king wizards at IBM made
the request lines active high instead of active low with a
pull-up (which would have allowed wire-or interrupt sharing).
Some devices (some serial port cards, I believe) use a
tri-state driver to drive the request high, but disable the
driver entirely when the request is deasserted, counting on a
weak pull-down.  This leaves interrupt request lines floating,
although the 8259 has the inputs enabled.  This is all
conjecture, though.