On 10/10/07, Philippe Gerum <[EMAIL PROTECTED]> 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

                                               Gilles Chanteperdrix

Xenomai-core mailing list

Reply via email to