On 09/01/06, Gilles Chanteperdrix <[EMAIL PROTECTED]> wrote:
Dmitry Adamushko wrote:
> Hi everybody,
> I'm presenting it one last time as a draft, so it's a right time to give all
> the remarks concerning design/implementation issues for all interested
> parties.
> Any feedback is wellcome.

Maybe I missed some recent changes in Xenomai HAL or Adeos, in which
case, please forget my remark, but calling xnarch_hook_irq,
i.e. rthal_irq_request when nklock is locked, irq off, may lead to
deadlock on multi-processor machines. The situation is (or used to be)
as follows:

holds the nklock
calls rthal_irq_request, which calls ipipe_critical_enter, which:
   triggers the critical IPI
   spins, waiting for other CPUs to enter __ipipe_do_critical_sync

spins on nklock, irq off
never handles the critical IPI, because irqs are off

So this a generic "problem" here with spinning on _any_ lock when irqs are off. And we can't use just a irq_save/restore -less counterparts (even if we would have those) since there is a need to be synchronized wrt the irq-handler.

Ok, maybe there is another way rather than the nklock (or any other lock) or the lock can be used in a different way to avoid deadlock.


I only skimmed over the discussion about ipipe_virtualize_irq_from. I do
not know if it finally flushes all pending interrupts an all CPUs when
called with a NULL handler. But if it does, the call to
xnintr_shirq_spin seems redundant in xnintr_detach.


                                            Gilles Chanteperdrix.

Best regards,
Dmitry Adamushko

Reply via email to