Spurious parport interrupts (IRQ 7) / rt benchmarking

[Karim Yaghmour <karim@opersys.com>]

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
-
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/