On 03/13/2012 12:44 PM, Gilles Chanteperdrix wrote:
> On 03/07/2012 07:13 PM, Roberto Bielli wrote:
>> Hi Gilles,
>> this is the trace and the test.
>> It seems that '__ipipe_dispatch_event' last about ~84 milliseconds with
>> disable interrupts.
> Sorry, I somehow missed this post.
> I am afraid you are mis-reading the trace. The time spent in user-space
> gets accounted to __ipipe_dispatch_event, because this is the last
> instrumented function called before the return to user-space. Interrupts
> are disabled at this point, this is perfectly normal, but they are
> probably re-enabled when returning to user-space.
> What is more problematic, however, is that the timer interrupt did not
> tick at -83749 like it is supposed to. If it had ticked and the
> interrupt had been disabled in user-space, you would have taken the
> interrupt at -35, when __ipipe_syscall_root gets called with interrupts on.
> So, now, you have to understand why the timer interrupt did not tick. I
> suggest, when the problem happens, you look at:
> * the interrupt controller register, to see if the timer interrupt is
> still masked, if it is masked, then try first commenting out the snippet
> in arch/arm/plat-mxc/avic.c which declares mxc_mask_irq as the
> irq_mask_ack callback
> * the timer registers, to see if the timer was programmed correctly, and
> is still ticking when the issue happens.
You may also want, in __ipipe_mach_set_dec, to re-read the comparator
value after writing it. Sometimes, such things are needed for the write
to register to be really taken into account.
Xenomai-core mailing list