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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
