On Thu, 17 Feb 2000, Richard B. Johnson wrote:
> On Tue, 15 Feb 2000, Richard B. Johnson wrote:
>
> > On Tue, 15 Feb 2000, Richard B. Johnson wrote:
> >
> > On Tue, 15 Feb 2000, Maciej W. Rozycki wrote:
> >
> > > On Mon, 14 Feb 2000, Richard B. Johnson wrote:
> > >
> > > > Of course this response has no basis in fact. The problem was traced
> > > > to the printer-port enable being a tri-state enable. The TTL (actually
> > > > PMOS) version of the controller didn't care that its input was left
> > > > floating. However, when substituting the CMOS version, we were left
> > > > with a floating input because there was no pull-up resistor on this
> > > > input. The fix was a resistor.
> > >
> > > > Go read the 8259A datasheet (it's Intel order number 231468). It's about
> > > > the original NMOS version so your CMOS reference is irrelevant. Search
> > > > the doc for the default vector.
> > > >
> >
> > Once programmed, there is no 'default vector'. The upper 5 bits of the
> > vector are set in ICW2. If there are no interrupt requests pending, there
> > are no vectors. Period.
> >
> > > Now tell me what the circuit does when it receives two INTA cycles but no
> > > IRR bit is set because no new interrupts arrived and all previous were
> > > acknowledged? Don't you know? Go fetch an MP-compliant SMP system and
> > > route an ExtINTA IRQ via both a local unit and via an I/O unit. Observe
> > > what an 8259A does when it receives the second pair of INTA cycles. Or
> > > what it does when it receives a pair of INTA cycles while all IRQ sources
> > > are masked out. Of course this description is simplified, but since you
> > > are an experienced interrupt programmer you will easily figure out missing
> > > implementation details.
> >
> > INTA Cycles come from the CPUs, not from the controller. If the
> > CPUs were to generate such an ACK, without a coresponding request,
> > the CPUs are broken. The controllers were of course not designed
> > to control two or more CPUs. For this reason, the board vendors do
> > not feed the INT output to all the CPUs in parallel, they select
> > each one in turn through a ripple-counter. This has the unfortunate
> > consequence of missing interrupts until all the CPUs have been
> > initialized. It also means that a dual-CPU SMP machine that was not
> > properly hardware-reset (i.e. warm-boot), may miss every-other interrupt
> > upon startup.
> >
> > You can simulate the response to an INTA (from the CPU) by setting
> > the D2 bit in OCW3. It sets the highest requesting level in the
> > in-service register and generates the vector that would be put
> > on the address-lines for the vectored interrupt. On the next read
> > the data returned will have the value D0-D2 of the interrupt request.
> > You don't have to send a physical INTA to the device(s), possibly
> > killing your system. If the IR bits are all masked off, you will
> > note that no such vector is generated. This shows that there is
> > no "default vector".
> >
> > All this information is available in a book written by Lewis C.
> > Eggebrecht, "Interfacing to the IBM Personal Computer", Howard W.
> > Sams, Inc. ISBN 0-672-22027-X. He designed the first IBM PCs and
> > the System 23. This is an "Old book, circa 1983" , but so is
> > the 8259A.
> >
> > Reference to these "original works" should help reduce the amount
> > of folklore associated with the devices used in the PC machines.
> >
> > >
> > > Finally, please tell me how do you imagine performing "IRQ latching"
> > > for
> > > level-triggered interrupts. I've no idea how it could be done (and what
> > > for). Of course no real latching is done by an 8259A for either trigger
> > > type interrupts -- if an IRQ is deasserted, it's forgotten -- the
> > > respective IRR bit gets cleared.
> > >
> >
> > ALL IRQ inputs to the 8259A are latched. This is how it is able to
> > remember the inputs so the programmed priority can work.
> >
> > Once an interrupt-request line remains true for the required setup
> > time, that input bit is latched. The physical device can 'buzz', deassert
> > its request or do whatever it wants. The fact that an interrupt request
> > occurred is sufficient for the controller to 'remember' it for all time.
> > It forgets it only when an EOI code is sent to the controller.
> > There are two, 0x20 is non-specific and 0x60|int_no is specific.
> > At this time, if the LTIM bit in the initialization register was not
> > set, the input latch is reset.
> >
> > That's how it works.
> >
> > The original 8259 was not designed for level-triggering, in fact
> > it was designed for use with 8085. It has a bit in ICW4 to select
> > the 8085 or the 8088 mode. The 'A' version and subsequent CMOS versions
> > provided a LTIM bit in the initialization register, ICW1 (bit 3). The
> > function of this bit is to prevent resetting the input latch when an EOI
> > (specific or non-specific) if sent to the device, IF the interrupt request
> > line is still true. This has the effect of allowing a level to be
> > detected. With this, multiple interrupt requests may be ORed into the same
> > IRQ line.
> >
> > > Please learn facts and do not spread myths -- someone less experienced
> > > might actually believe you...
> >
> > You, sir, are one spreading myths.
[Snipped]
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.
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.
Normally it is expected that since interrupt request lines are
fed all over the place, in the VAX they were even looped through
boards on a large noisy backplane, they might be noisy. Normally,
interrupt vectors not in current use are handled by a do-nothing
interrupt service routine and ignored.
Interrupt service routines should (must???) be designed so that
nothing bad happens if an interrupt occurs and the code finds that
there is nothing to do. In fact, this is how one can share interrupts.
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.
Fortunately new motherboards don't use the 8259 when running Linux.
Their interrupts are handled through the APIC code. I certainly
hope it's in better shape.
Very Truly Yours,
Charles Turner
I speak only for myself, which is enough of a problem.
-
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:20 EST