Spurious parport interrupts (IRQ 7) / rt benchmarking

Spurious parport interrupts (IRQ 7) / rt benchmarking

[Karim Yaghmour]

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.

Thanks,

Karim Yaghmour
Kristian Benoit
-- 
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || 1-866-677-4546

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

[Denis Vlasenko]

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.
--
vda

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

[Kristian Benoit]

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.

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

[Maciej W. Rozycki]

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