Re: [Xenomai-core] Fwd: RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK

[Philippe Gerum <rpm@xenomai.org>]

On Wed, 2007-10-10 at 11:36 +0200, Gilles Chanteperdrix wrote:
> On 10/10/07, Philippe Gerum <rpm@xenomai.org> wrote:
> > On Wed, 2007-10-10 at 10:54 +0200, Gilles Chanteperdrix wrote:
> > > On 10/10/07, Philippe Gerum <rpm@xenomai.org> wrote:
> > > > On Wed, 2007-10-10 at 08:12 +0200, Jan Kiszka wrote:
> > > > > Gilles Chanteperdrix wrote:
> > > > > > Jan Kiszka wrote:
> > > > > >  > Again, the priority should not be the issue. The issue is likely that a
> > > > > >  > pending or just being handled non-RT IRQ can stall some RT IRQ at
> > > > > >  > hardware level. That must not happen. I-pipe rather has to log,
> > > > > >  > acknowledge, and possibly mask that line quickly so that RT IRQs can be
> > > > > >  > delivered again.
> > > > > >
> > > > > > Thinking a bit more about my ethernet vs timer issue. If, when an
> > > > > > ethernet interrupt is pending, adeos is not aware that there is also a
> > > > > > timer interrupt pending, it will call the ethernet interrupt handler
> > > > > > immediately then unmask the interrupt. So, Adeos will never have a
> > > > > > chance to handle the timer interrupt before another ethernet interrupt
> > > > > > is handled. Ergo, giving the timer interrupt the highest priority is
> > > > > > what must be done.
> > > > >
> > > > > No. Adeos will first start to dispatch the Ethernet IRQ. It will
> > > > > ack&mask it and then re-enable the IRQ delivery before calling into the
> > > > > handler.
> > > >
> > > > Only if the ethernet interrupt is not a real-time event.
> > > >
> > > > >  At this point the hardware can report the timer IRQ, and Adeos
> > > > > will immediately start to deliver that one instead.
> > > > >
> > > > > With IRQ hardware priorities, you only optimise the case when both
> > > > > interrupts are pending in the hardware at the same time. The worst-case
> > > > > remains that the Ethernet IRQ comes first, Adeos starts to handle it,
> > > > > and _then_ the timer IRQ arrives. This is something the hardware can in
> > > > > no way avoid (without looking into the future...).
> > > > >
> > > >
> > > > When the processor has a notion of internal priority level which it does
> > > > inherit from the level of the event it currently processes, the above
> > > > assumption is wrong. In such a case, the next interrupt to be serviced
> > > > would be equivalent to pending_IRQ_mask & CPU_interrupt_mask &
> > > > processor_level, i.e. multiple high priority interrupts would be
> > > > processed before a low priority one is eventually triggered. So in that
> > > > case, Gilles's assertion does make a lot of sense.
> > >
> > > The AT91 interrupts need an EOI, I wonder if we are not simply doing
> > > the EOI too late. That is, the EOI should be done when the interrupt
> > > has been acked, before it is handled, so that other interrupts can be
> > > delivered.
> > >
> >
> > The EOI would lower the priority barrier for interrupts, so this makes
> > sense.
> >
> > Looking at the I-pipe code for AT91RM9200 for instance, I only see the
> > AIC being asked to mask the IRQ source as a result of the fast I-pipe
> > acknowledge being called, nothing more. If the AIC needs explicit EOI to
> > lower the priority level which is not covered by the previous action,
> > then it's indeed missing.
> >
> > The latest fix regarding the fasteoi interrupt flow would not have any
> > impact, since AFAICS, we are solely dealing with level interrupts here.
> 
> The EOI is done by the irq_finish macro, which is called after ipipe_handle_irq.
> 

So you are definitely right. irq_finish must be done before the
interrupt is pipelined, right after it has been masked in the fast ack
handler.

-- 
Philippe.