On Thu, 17 Feb 2000, Charles Turner, Ph.D. wrote:
> Johnson is correct. The 8259A IRQ inputs are all latched. This is
> essential for interrupt priority. There is a D-type flip/flop at
> each input. This is reset only when an end-of-interrupt comand is
> sent to the device. Whether or not the EOI resets the current
> flip/flop depends upon the kind of EOI sent to the device. If it
> is the specific-end-of-interrupt, the particular latch (called the
> in-service latch) for the specific IRQ is reset. It you send it
> the non-specific-eoi, the highest priority pending interrupt's
> in-service latch is reset.
There are actually two D-latches between the input and the priority
resolver. You are clearly writing of the ISR latch which is really reset
by EOI. But the reason of spurious interrupts is the IRR D-latch which is
located earlier in the path from IR<x> pin to the priority resolver. The
IRR latch normally reflects the IR<x> input but it gets frozen at the
start of the first INTA cycle (it also gets reset by ICW1 but this doesn't
matter here). But the CPU probes for INT at the late stage of execution
of an instruction. There is a small window between the INT probe and the
start of the first INTA cycle. If the IR<x> line gets deasserted during
this window and no other IR<x> line is active at the moment you get a
spurious interrupt -- an 8259A issues a default vector which is that of
IR7. Providing a spurious interrupt vector is surely better than floating
the bus which would result in garbage being sent to CPU which in turn
would treat it as a valid interrupt vector. Note that bit 7 of the ISR is
not being set when this default vector is sent to the CPU.
> Sombody said that the 8259 was made for the 8080. This cannot be.
> The 8080 was not capable of vectored interrupts. It had one interrupt
> which was always executed from a particular code-location. A ISR
> had to poll each possible device to see which one, if any, was
> requesting service. Of the early Intel CPUs, the first capable of
> vectored interrupts was the 8085. It was used in the DEC monitor
> for VAX machines of which I am very familiar.
You must confuse something again. I know it was common practise to
simplify 8080 microprocessor systems and not using an IRQ controller at
all. It was possible to wire the bus controller (I can't remember its
number at the moment) in such a way that 0xff was driven at the data bus
in response to an INTA cycle (I think one had to pull-up the INTA output
of the bus controller to +12V; not sure though). 0xff was a valid 8080
opcode and it was "rst7" -- a one-byte shorthand for "call 0x0038". Then
polling of devices could be performed to find out which one requested
service.
In a more advanced system, one could use an 8259 or 8259A and this chip
is capable of providing a "call" opcode as I described in the other mail.
See the datasheet, for how would you inform 8259 what bits has to be
driven as the MSB and high-order bits of LSB of the argument of "call".
> I am not a kernel hacker. However I can read C code. It looks
> as though somebody tried to make an issue about every unimportant
> hardware glitch that made it through the controllers. There seems
> to be some kind of cult or witchcraft associated with this code.
I believe it's normal to count spurious interrupts to make statistics
which could indicate hardware deterioration. It's just the 8259 which is
so simplified that the spurious interrupt vector is shared with the one of
IR7 (so in order to distinguish it from a real one you have check bit 7 of
the ISR).
> Fortunately new motherboards don't use the 8259 when running Linux.
Unfortunately, only SMP ones. Uniprocessor boards are mostly 8259A
based, supposedly because of an extra cost of putting an I/O APIC on the
board. This usually means you have to put an extra 82093AA chip as very
few chipsets incorporate a core of an I/O APIC. The notable exception is
the 82379AB (aka SIO.A) but this one is ancient -- PCI 2.0 only, IIRC, and
no ATA, USB, etc. -- just a plain PCI-ISA bridge. I think some newest P6
uniprocessor chipsets do incorporate an I/O APIC which might change the
current situation, but at the moment the vast majority of motherboards
used still has only a pair of 8259As.
> Their interrupts are handled through the APIC code. I certainly
> hope it's in better shape.
At least it has a separate vector for spurious interrupts (which are
defined in a slightly different manner). And edge-triggered interrupts
are never lost, i.e. no matter whether a device keeps its interrupt line
asserted or not, once an I/O APIC (or a local one to be complete)
registers an edge-triggered IRQ, it will be delivered based on configured
rules. Level triggered interrupts are treated as usually.
I hope this description clarifies any doubts.
Maciej
-- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:22 EST