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

[Kristian Benoit <kbenoit@opersys.com>]

On Thu, 2005-06-16 at 09:48 +0300, Denis Vlasenko wrote:
> On Thursday 16 June 2005 00:25, Karim Yaghmour wrote:
> > 
> > This is related to our continued benchmarking of the rt stuff.
> > 
> > Using the same setup we described earlier, we're now getting
> > some really odd behavior on rc6. Basically, our target system
> > is getting more interrupts than our logger is sending to it.
> > 
> > [ recap: our target and logger are rigged via the parallel
> > port. The logger toggles an output pin on the parallel pin
> > which, in turn, generates an interrupt on the target. Our
> > driver on the target catches the interrupt and then toggles
> > an output pin on the target's parallel port. This, in turn,
> > generates an interrupt on the logger. The difference between
> > the time the interrupt was sent by the logger and the time
> > the interrupt is received from the target on the logger is
> > what we measure as the interrupt response time. ]
> > 
> > Under ping flood conditions with vanilla Linux, and in that
> > case only, rc6 gets more interrupts than the logger sends
> > to it. We've double checked this by not sending any ints
> > from the logger whatsoever, and ping flooding the rc6 on
> > the target, and the moment we do that our driver on the
> > target starts responding to phantom interrupts.
> > 
> > It must be noted that when we did these tests on rc4 we didn't
> > have such spurious interrupts. Also, we don't get these when
> > PREEMPT_RT is applied to rc6 (all of which under ping flood
> > conditions.)
> > 
> > We've tried to find a pattern in the spuriousness, but there
> > really isn't any.
> > 
> > We've spent quite some time tracking this down, hence the
> > delayed publication of new numbers.
> > 
> > Any insight anyone may have on this issue would be greatly
> > appreciated.
> 
> 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
> to read IRQ# from PIC, PIC returns 7. Thus you get IRQ7 or IRQ15
> depending on where that happened, on primary or secondary PIC.
> 
> Presumably there can be 'bad' devices which momentarily flash
> their IRQ, confusing PIC.
> 
> 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.

Thanks, the problem is related to CONFIG_X86_UP_APIC and
CONFIG_X86_UP_IOAPIC beiing disabled. Enabling them fixed the spurious
interrupt.