Date: Mon, 06 Jan 1997 03:28:09 -0600 From: Tony Overfield <tony@dell.com> To: Bruce Evans <bde@zeta.org.au>, grog@lemis.de, msmith@atrad.adelaide.edu.au Cc: hackers@FreeBSD.ORG Subject: Re: Ints (fwd) Message-ID: <3.0.1.32.19970106032347.0067e4ac@bugs.us.dell.com>
next in thread | raw e-mail | index | archive | help
>One interesting side effect is that when the last device >disconnects from an IRQ line, the line usually floats high, and the >edge for this causes an interrupt. Thus "disabling" interrupts using >the tri-state control usually causes an interrupt. True, though on a "PC compatible" system, the IRQ _always_ goes high when not driven because there is always a pull-up resistor. >>> I thought the interrupt was just a pulse. It certainly was on the >>> 8251. > >Not for an 8250, or any device suitable for driving sensible (level >triggered) interrupts directly. There is a scheme for sharing ISA edge-triggered interrupts that involves pulsing. It works by declaring that the IRQ will remain high (by pull-up, not driven) until a device wants interrupt service. At that time the device pulses the IRQ low for 100-200 ns and then releases it again to cause the rising edge. Eventually, the interrupt occurs, and the interrupt service routine(s) must then check all the registered devices to see which one(s) caused the interrupt. Because the IRQ is pulled high by the pull-up resistor, spurious interrupts won't be generated. This may seem peculiar, but I've seen it in operation. >> 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. >> >>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. > >No, the spurious interrupt is only generated if the interrupt goes away >during the interrupt ack cycle. Right, the CPU must recognize the CPU INTR signal and begin processing the interrupt before it can become spurious. A spurious interrupt results if an int-ack cycle occurs but the 8259 does not find an unmasked IRQ that is at a high level. Removing an IRQ before the 8259 sees its level during the int-ack usually causes an IRQ 7 (or always does, if the bouncing IRQ was a small one). But, as you may already know, you can also get a spurious IRQ 15 by removing an upper IRQ at just the right time (guess: during the 8259 IRQ scan, after the primary 8259 sees the cascade, but before the secondary 8259 sees the upper IRQ.) But the spurious interrupt is still usually IRQ 7, since the susceptible timing window is a little larger. It's larger because the IRQ could go away any time after the CPU recognizes the interrupt (before the int-ack even begins), but before the 8259 later scans for the (now missing) IRQ. Also, for whatever reasons, if the CPU were to wrongly see an asserted CPU INTR signal when the 8259 wasn't requesting it, a spurious IRQ 7 would result. Tony
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.1.32.19970106032347.0067e4ac>