From owner-freebsd-hackers Sun Jan 5 18:41:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA01596 for hackers-outgoing; Sun, 5 Jan 1997 18:41:31 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA01590 for ; Sun, 5 Jan 1997 18:41:28 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id NAA28087; Mon, 6 Jan 1997 13:11:12 +1030 (CST) From: Michael Smith Message-Id: <199701060241.NAA28087@genesis.atrad.adelaide.edu.au> Subject: Re: Ints (fwd) In-Reply-To: <199701031328.OAA14921@freebie.lemis.de> from Greg Lehey at "Jan 3, 97 02:28:06 pm" To: grog@lemis.de Date: Mon, 6 Jan 1997 13:11:11 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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 [[