Flavio de Castro Alves Filho wrote:
> Hello Gilles,
>
> Unfortunately the patch didn't help... :-(
>
> But ... adding more traces on the code, I can see the irq number when the
> function __ipipe_grab_irq() is called.
>
> When everything works fine, the irq number is 21 (IRQ_DA8XX_TINT12_0).
>
> And, sometime, the irq number starts to be 22 (IRQ_DA8XX_TINT34_0). It is
> the other timer present at the processor. I believe that, somehow, the
> information about the timer (at least, the interrupt location) has been
> changed by some code.
>
> I will investigate more, according to these observations. I accept
> suggestions :-)
Are you sure you recompiled the kernel ? This other timer's irq seems to
be the one for which the handle_edge_irq handler is used, which could
really cause a lockup.
Anyway, the reason why this other timer is used is probably because
clockevent decided it had a better score. But that should not cause a
lockup, unless handle_edge_irq is used.
So, you are probably better off using that timer for xenomai too. If you
do not want that, you will have to give a higher score to the timer you
want Linux to use.
--
Gilles.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
