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

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

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

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]