[Xenomai-core] xenomai preempting interrupt handler ?

[Xenomai-core] xenomai preempting interrupt handler ?

[Steven Scholz]

Hi all,

using an oscilloscope I found that the AT91RM9200 spends up to 300µs in the
interrupt handler for ethernet controller.

Now I wonder if this interrupt handler will be preempted by Xenomai if there
is a high priority, periodic real time task? Thus will the duration of the
ethernet interrupt handler add the the worst case latency?

Thanks.

-- 
Steven

Re: [Xenomai-core] xenomai preempting interrupt handler ?

[Philippe Gerum]

On Thu, 2007-03-08 at 10:29 +0100, Steven Scholz wrote:
> Hi all,
> 
> using an oscilloscope I found that the AT91RM9200 spends up to 300µs in the
> interrupt handler for ethernet controller.
> 
> Now I wonder if this interrupt handler will be preempted by Xenomai if there
> is a high priority, periodic real time task?

Hw interrupts are forcibly enabled before entering any Linux IRQ
handler, exactely to prevent the issue you described (e.g. fiddling with
an IDE controller in PIO mode also gives funky latency results unless
the latter is true), so the answer is yes.

>  Thus will the duration of the
> ethernet interrupt handler add the the worst case latency?
> 

Not from Linux IRQ handlers; you may want to check this using the
tracer. If hw interrupts are masked there, then it's a blatant bug.

> Thanks.
> 
-- 
Philippe.

Re: [Xenomai-core] xenomai preempting interrupt handler ?

[Steven Scholz]

Philippe,

>> using an oscilloscope I found that the AT91RM9200 spends up to 300µs in the
>> interrupt handler for ethernet controller.
>>
>> Now I wonder if this interrupt handler will be preempted by Xenomai if there
>> is a high priority, periodic real time task?
> 
> Hw interrupts are forcibly enabled before entering any Linux IRQ
> handler, exactely to prevent the issue you described (e.g. fiddling with
> an IDE controller in PIO mode also gives funky latency results unless
> the latter is true), so the answer is yes.
Thanks.

>>  Thus will the duration of the
>> ethernet interrupt handler add the the worst case latency?
> 
> Not from Linux IRQ handlers; you may want to check this using the
> tracer. If hw interrupts are masked there, then it's a blatant bug.

How could I check this using the tracer? Small hint please?

Steven

Re: [Xenomai-core] xenomai preempting interrupt handler ?

[Philippe Gerum]

On Thu, 2007-03-08 at 11:08 +0100, Steven Scholz wrote:
> Philippe,
> 
> >> using an oscilloscope I found that the AT91RM9200 spends up to 300µs in the
> >> interrupt handler for ethernet controller.
> >>
> >> Now I wonder if this interrupt handler will be preempted by Xenomai if there
> >> is a high priority, periodic real time task?
> > 
> > Hw interrupts are forcibly enabled before entering any Linux IRQ
> > handler, exactely to prevent the issue you described (e.g. fiddling with
> > an IDE controller in PIO mode also gives funky latency results unless
> > the latter is true), so the answer is yes.
> Thanks.
> 
> >>  Thus will the duration of the
> >> ethernet interrupt handler add the the worst case latency?
> > 
> > Not from Linux IRQ handlers; you may want to check this using the
> > tracer. If hw interrupts are masked there, then it's a blatant bug.
> 
> How could I check this using the tracer? Small hint please?

http://www.xenomai.org/index.php/I-pipe:Tracer

> 
> Steven
-- 
Philippe.

Re: [Xenomai-core] xenomai preempting interrupt handler ?

[Steven Scholz]

Philippe Gerum wrote:
> On Thu, 2007-03-08 at 11:08 +0100, Steven Scholz wrote:
>> Philippe,
>>
>>>> using an oscilloscope I found that the AT91RM9200 spends up to 300µs in the
>>>> interrupt handler for ethernet controller.
>>>>
>>>> Now I wonder if this interrupt handler will be preempted by Xenomai if there
>>>> is a high priority, periodic real time task?
>>> Hw interrupts are forcibly enabled before entering any Linux IRQ
>>> handler, exactely to prevent the issue you described (e.g. fiddling with
>>> an IDE controller in PIO mode also gives funky latency results unless
>>> the latter is true), so the answer is yes.
>> Thanks.
>>
>>>>  Thus will the duration of the
>>>> ethernet interrupt handler add the the worst case latency?
>>> Not from Linux IRQ handlers; you may want to check this using the
>>> tracer. If hw interrupts are masked there, then it's a blatant bug.
>> How could I check this using the tracer? Small hint please?
> 
> http://www.xenomai.org/index.php/I-pipe:Tracer

I know this. But I was asking how I could use it to check the above problem.

Is "Trace IRQs-off times CONFIG_IPIPE_TRACE_IRQSOFF ... Instrument each
disable and re-enable of hardware IRQs. This allows to identify the longest
path in a system with IRQs disabled." the important stuff?

--
Steven

Re: [Xenomai-core] xenomai preempting interrupt handler ?

[Philippe Gerum]

On Thu, 2007-03-08 at 11:20 +0100, Steven Scholz wrote:
> Philippe Gerum wrote:
> > On Thu, 2007-03-08 at 11:08 +0100, Steven Scholz wrote:
> >> Philippe,
> >>
> >>>> using an oscilloscope I found that the AT91RM9200 spends up to 300µs in the
> >>>> interrupt handler for ethernet controller.
> >>>>
> >>>> Now I wonder if this interrupt handler will be preempted by Xenomai if there
> >>>> is a high priority, periodic real time task?
> >>> Hw interrupts are forcibly enabled before entering any Linux IRQ
> >>> handler, exactely to prevent the issue you described (e.g. fiddling with
> >>> an IDE controller in PIO mode also gives funky latency results unless
> >>> the latter is true), so the answer is yes.
> >> Thanks.
> >>
> >>>>  Thus will the duration of the
> >>>> ethernet interrupt handler add the the worst case latency?
> >>> Not from Linux IRQ handlers; you may want to check this using the
> >>> tracer. If hw interrupts are masked there, then it's a blatant bug.
> >> How could I check this using the tracer? Small hint please?
> > 
> > http://www.xenomai.org/index.php/I-pipe:Tracer
> 
> I know this. But I was asking how I could use it to check the above problem.
> 
> Is "Trace IRQs-off times CONFIG_IPIPE_TRACE_IRQSOFF ... Instrument each
> disable and re-enable of hardware IRQs. This allows to identify the longest
> path in a system with IRQs disabled." the important stuff?

Yes. If the "IRQ off" marker appears when running the Linux ethernet IRQ
handler, then we have a problem.

> 
> --
> Steven
-- 
Philippe.

Re: [Xenomai-core] xenomai preempting interrupt handler ?

[Steven Scholz]

Philippe,

>>>>  Thus will the duration of the
>>>> ethernet interrupt handler add the the worst case latency?
>>> Not from Linux IRQ handlers; you may want to check this using the
>>> tracer. If hw interrupts are masked there, then it's a blatant bug.
>> How could I check this using the tracer? Small hint please?
> 
> http://www.xenomai.org/index.php/I-pipe:Tracer

"Traces can be generated in many ways. One happens automatically when
CONFIG_IPIPE_TRACE_IRQSOFF is enabled."

What exactly does that mean? That one trace is generated during boot?

"Another way is to invoke the testsuite, namely latency or irqbench with the
option -f to trigger a freeze on each new maximum latency."

What exactly does "trigger a freeze" mean?

Steven

Re: [Xenomai-core] xenomai preempting interrupt handler ?

[Philippe Gerum]

On Thu, 2007-03-08 at 12:49 +0100, Steven Scholz wrote:
> Philippe,
> 
> >>>>  Thus will the duration of the
> >>>> ethernet interrupt handler add the the worst case latency?
> >>> Not from Linux IRQ handlers; you may want to check this using the
> >>> tracer. If hw interrupts are masked there, then it's a blatant bug.
> >> How could I check this using the tracer? Small hint please?
> > 
> > http://www.xenomai.org/index.php/I-pipe:Tracer
> 
> "Traces can be generated in many ways. One happens automatically when
> CONFIG_IPIPE_TRACE_IRQSOFF is enabled."
> 
> What exactly does that mean? That one trace is generated during boot?
> 

That means that several sources of trace points exist, one of them being
controlled by the IRQSOFF switch. MCOUNT cause a trace to be emitted
upon each function entry, and so on.

> "Another way is to invoke the testsuite, namely latency or irqbench with the
> option -f to trigger a freeze on each new maximum latency."
> 
> What exactly does "trigger a freeze" mean?
> 

A snapshot of the current trace log, kept from being overwritten in a
separate memory upon freeze, that you can access
through /proc/ipipe/trace/frozen.

> Steven
> 
-- 
Philippe.