Re: [Xenomai] issue with cobalt/timer: avoid periodic timer drift

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 07/06/2014 06:37 PM, Matthias Schneider wrote:
> ----- Original Message -----
> 
>> From: Matthias Schneider <ma30002000@yahoo.de>
>> To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>; "xenomai@xenomai.org" <xenomai@xenomai.org>
>> Cc: 
>> Sent: Sunday, July 6, 2014 6:31 PM
>> Subject: Re: [Xenomai] issue with cobalt/timer: avoid periodic timer drift
>>
>>
>>
>>
>>
>>
>> ----- Original Message -----
>>>  From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
>>>  To: Matthias Schneider <ma30002000@yahoo.de>; 
>> "xenomai@xenomai.org" <xenomai@xenomai.org>
>>>  Cc: 
>>>  Sent: Sunday, July 6, 2014 6:09 PM
>>>  Subject: Re: [Xenomai] issue with cobalt/timer: avoid periodic timer drift
>>>
>>>  On 07/06/2014 06:00 PM, Matthias Schneider wrote:
>>>>>   You seem to have created a periodic timer with a null period. 
>> Could you
>>>>>   post a sample code allowing to reproduce this issue?
>>>>>    
>>>>
>>>>
>>>>   This happens in most of my freertos apps (e.g. demo, etc.). However, 
>>>>   I have not put any effort in narrowing the problem down, in the hope
>>>>   the problem would be deductible from the kernel state. Maybe you could
>>>>   give a few hints where a periodic timer could come into play? In the
>>>>   freertos skin there are only tasks, queues and semaphores, so I
>>>>   am not creating any periodic timer explicitly. Are there occasiosn
>>>>   when periodic timers are being created implicitly using the three
>>>>   primitives mentioned above? Or can I configure an intelligent
>>>>   breakpoint to catch the creation of a periodic timer?
>>>
>>>  Maybe you could put a breakpoint to see where xntimer_start is called?
>>
>>
>> I have already had the idea, unfortunately it seems to be called all
>> the time:
>>
>> #0  xntimer_start (timer=0xc06b7628 <nksched+24>, value=405804, 
>> interval=interval@entry=0, mode=mode@entry=XN_RELATIVE) at 
>> kernel/xenomai/timer.c:104
>> #1  0xc00ca504 in program_htick_shot (delay=<optimized out>, 
>> cdev=<optimized out>) at kernel/xenomai/timer.c:572
>> #2  0xc007407c in clockevents_program_event (dev=0xc06a65c0 
>> <clockevent_gpt>, expires=..., force=force@entry=false) at 
>> kernel/time/clockevents.c:269
>> #3  0xc0074a54 in tick_program_event (expires=..., force=force@entry=0) at 
>> kernel/time/tick-oneshot.c:31
>> #4  0xc0050974 in hrtimer_interrupt (dev=<optimized out>) at 
>> kernel/hrtimer.c:1360
>>
>> Any other idea?
> 
> 
> By the way, how can I deduce it was a periodic timer?
> 
> status seems to be 0x1 (XNTIMER_DEQUEUED), but not 0x4(XNTIMER_PERIODIC)
> Also, all the other timer values seem to indicate that
> 
>  if (interval != XN_INFINITE) {
>   timer->interval_ns = interval;
>   timer->interval = xnclock_ns_to_ticks(clock, interval);
>   timer->periodic_ticks = 0;
>   timer->start_date = date;
>   timer->pexpect_ticks = 0;
>   timer->status |= XNTIMER_PERIODIC;
>  }
> 
> was never being used for that timer...

You mean for the timer where you hit the breakpoint, or for the timer
which has the bug?


-- 
                                                                Gilles.