Re: Spurious parport interrupts (IRQ 7) / rt benchmarking

From: Maciej W. Rozycki
Date: Thu Jun 16 2005 - 10:48:27 EST

On Thu, 16 Jun 2005, Denis Vlasenko wrote:

> IIRC specs of old AT PIC say that if input interrupt pins
> are no longer asserted by the time when CPU asserts IRQ and tries

An x86 CPU issues an INTA special cycle actually.

> to read IRQ# from PIC, PIC returns 7. Thus you get IRQ7 or IRQ15
> depending on where that happened, on primary or secondary PIC.

Well, for a spurious IRQ from a slave the timing is really tight -- you
normally just receive IRQ 7 from the master. Though I haven't thought of
what would happen in this case if there was a slave on the IR7 input of
the master... ;-)

> Presumably there can be 'bad' devices which momentarily flash
> their IRQ, confusing PIC.

It can be noise due to a cross-talk.

> However, I am a bit surprized how often these IRQ7s happen.
> Maybe APIC's PIC emulation just reuses this convention to
> indicate APIC errors in PIC emulation mode. I am not familiar
> with APIC, tho... I did not yet read APIC docs.

APICs edge-triggered inputs are "sticky", that is the chip remembers a
rising edge has happened and do not clear the latch on a falling edge (or
IOW it implements the mode correctly). Therefore any noise from a PIC
that's connected to an APIC that's makes an input to the APIC to be
asserted for long enough for the chip to record it as an edge will trigger
an interrupt.

For a PIC routed straight to an x86 CPU the timing is rather tight -- the
CPU has to issue an INTA cycle at about the time of the interrupt source
going away. For example in older PC/AT machines (based on an i386 or an
80286) about the only way to trigger it was the keyboard interrupt (IRQ
1), driven by an 8042 microcontroller. The uc was slow enough in
deasserting its outgoing IRQ line, that if you read its keyboard data port
at i/o address 0x60 (which acted as an IRQ ack) with the keyboard
interrupt enabled in the PIC, you'd almost always receive a spurious
interrupt immediately after the i/o read instruction.

Of course the same conditions apply to the polled mode of operation.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at