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

["Maciej W. Rozycki" <macro@linux-mips.org>]

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.

  Maciej
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/