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

-- 
Philippe.