On 09/01/06, Gilles Chanteperdrix <[EMAIL PROTECTED]> wrote:
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.
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:
CPU1
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
CPU2
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
