In fact, The problem is not really related to the other timer, I believe.
Before the timer with irq 22 is called, another irq is called by __ipipe_grab_irq(): the irq number 12 (IRQ_DA8XX_CCERRINT). Now I'm looking for the place there this irq number is passed. And thank you for this important information about the timers. Flavio de Castro Alves Filho Phi Innovations - Embedded Software Services www.phiinnovations.com Phone: +55 11 84 94 56 76 Skype: flavio.de.castro.alves.filho 2010/1/8 Gilles Chanteperdrix <[email protected]> > 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
