Date: Mon, 6 Jan 1997 13:11:11 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: grog@lemis.de Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org Subject: Re: Ints (fwd) Message-ID: <199701060241.NAA28087@genesis.atrad.adelaide.edu.au> In-Reply-To: <199701031328.OAA14921@freebie.lemis.de> from Greg Lehey at "Jan 3, 97 02:28:06 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Greg Lehey stands accused of saying:
> >
> > Just about every other multi-card bus ever invented uses daisy-chained
> > interrupts or slot interrupts or some other manifestation of a sensible
> > scheme. But not ISA. YOU CANNOT SHARE INTERRUPTS SAFELY ON ISA.
>
> Well, I don't know if I consider daisy-chaining sensible either. But
That depends on whether you like being able to reorder the priority of
interrupts in your system by shuffling cards around. Still, it allows
interrupts to be shared, functionally.
> the biggest problem with interrupt sharing on ISA used to be the
> brain-dead circuitry of the UART board, not the bus nor the UART
> itself. The circuits I have show that the interrupt output of the
> UART goes to the *input* of an LS125 tri-state buffer, which then goes
> via a DIP switch to the IRQ3*/IRQ4* lines. The enable input (active
> low) of the LS125 gate is driven by OUT2*, which is effectively the
> "interrupt enable" bit of the modem control register.
>
> The problem with this is that the gate drives the IRQ line at all
> times, which isn't what tri-state is all about. The correct thing
The IRQ lines were never specified as tri-state; see my other mail with
references to Solari. The use of the 125 and the OUT2* signal mean
that if the UART doesn't have interrupts enabled, another device can
use the IRQ line. This is sensible design, given the context.
> > ... but the inputs to the 8259 are _edge_triggered_. If another
> > device is holding the line asserted, that doesn't count for a new
> > interrupt. It also means that another edge can't occur. So not only
> > is the second interrupt lost, but every interrupt after that is lost
> > as well.
>
> I thought the interrupt was just a pulse. It certainly was on the
> 8251.
It works like this (Bruce, if you can be bothered, please correct me if I
get this wrong) :
1) Device asserts IRQ signal.
2) 8259 detects edge, interrupts CPU
3) CPU performs interrupt acknowledge cycle, 8259 latches interrupt
inputs.
4) CPU reads 8259, determines interrupting device
5) Interrupt handler manipulates peripheral, clears IRQ signal.
The reason for the latching in step 3) is that the time between 2) and 3)
can be arbitrarily large (if the CPU has interrupts off, for example), and
another, higher-priority interrupt may come along in the meantime.
If the input goes away between 2) and 3), you get a spurious interrupt (the
8259 reports it as IRQ 7). If the input never goes away, there's no
way for another edge to occur, so 2) never happens.
> Greg
--
]] Mike Smith, Software Engineer msmith@gsoft.com.au [[
]] Genesis Software genesis@gsoft.com.au [[
]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[
]] realtime instrument control. (ph) +61-8-8267-3493 [[
]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701060241.NAA28087>