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

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

[Matthias Schneider]

Hi all,

commit 

2014-06-02 c20fceb147e337e2379b29ecd81b943318c7fbc7 
(patch) cobalt/timer: avoid periodic timer drift

seems to cause an endless kernel loop in one of my
freertos demos. The issue does not occur when 
reverting this commit.

Investigating the issue, can see the following:

#0  0xc00ba45c in mach_arm_nodiv_llimd (rhs_integ=<optimized out>, frac=<optimized out>, op=<optimized out>)
    at arch/arm/xenomai/include/asm/xenomai/uapi/arith.h:120
#1  xnclock_core_ns_to_ticks (ns=0) at kernel/xenomai/clock.c:52
#2  0xc00baf34 in xnclock_ns_to_ticks (clock=<optimized out>, ns=<optimized out>)
    at include/xenomai/cobalt/kernel/clock.h:204
#3  xntimer_update_date (timer=0xde706518) at include/xenomai/cobalt/kernel/timer.h:268
#4  xnclock_tick (clock=0xc06b1138 <nkclock>) at kernel/xenomai/clock.c:644
#5  0xc00bcbcc in xnintr_core_clock_handler () at kernel/xenomai/intr.c:121
#6  0xc0095a98 in dispatch_irq_head (irq=<optimized out>) at kernel/ipipe/core.c:1179

This seems to be the endless loop:
642                     do {
643      timer->periodic_ticks += interval_ticks;
644      xntimer_update_date(timer);
645                     } while (xntimerh_date(&timer->aplink) < now + clock->gravity);

gdb) info locals
timerq = 0xdebdae98
now = 4257712977
interval_ticks = 0
timer = 0xde706518
delta = <optimized out>
h = 0xde706518

(gdb) print *timer
$1 = {
  aplink = {
    link = {
      next = 0x100100, 
      prev = 0x200200
    }, 
    key = 0, 
    prio = 999999999
  }, 
  adjlink = {
    next = 0x0 <__vectors_start>, 
    prev = 0x0 <__vectors_start>
  }, 
  status = 1, 
  interval = 0, 
  interval_ns = 0, 
  periodic_ticks = 0, 
  start_date = 0, 
  pexpect_ticks = 0, 
  sched = 0xc06b1610 <nksched>, 
  handler = 0xc00c7dc4 <timeout_handler>, 
  name = "CREATOR", '\000' <repeats 24 times>, 
  handler_name = 0xc05ad429 "timeout_handler", 
  next_stat = {
    next = 0xde706624, 
    prev = 0xde705c24
  }, 
  scheduled = {
    counter = 3
  }, 
  fired = {
    counter = 1
  }
}
(gdb) print *clock
$2 = {
  wallclock_offset = 200209, 
  resolution = 1, 
  gravity = 140, 
  name = 0xc05ac815 "coreclk", 
  timerdata = 0xdebdae98, 
  id = -1, 
  vfile = {
    entry = {
      pde = 0xde1b8700, 
      file = 0x0 <__vectors_start>, 
      lockops = 0xc06b2c20 <xnvfile_nucleus_lock>, 
      refcnt = 0, 
      private = 0xc06b1138 <nkclock>
    }, 
    privsz = 4, 
    datasz = 104, 
    tag = 0xc06b117c <nkclock+68>, 
    ops = 0xc06b1120 <vfile_clock_ops>
  }, 
  revtag = {
    rev = 36
  }, 
  statq = {
    next = 0xc06b18d4 <nksched+708>, 
    prev = 0xde706e24
  }, 
  nrtimers = 24
}

Does anyone see right away what is going on wrong 
or shall I continue investigating the issue?

Regards,
Matthias

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

[Philippe Gerum]

On 07/06/2014 11:48 AM, Matthias Schneider wrote:
> Hi all,
>
> commit
>
> 2014-06-02 c20fceb147e337e2379b29ecd81b943318c7fbc7
> (patch) cobalt/timer: avoid periodic timer drift
>
> seems to cause an endless kernel loop in one of my
> freertos demos. The issue does not occur when
> reverting this commit.
>
> Investigating the issue, can see the following:
>
> #0  0xc00ba45c in mach_arm_nodiv_llimd (rhs_integ=<optimized out>, frac=<optimized out>, op=<optimized out>)
>      at arch/arm/xenomai/include/asm/xenomai/uapi/arith.h:120
> #1  xnclock_core_ns_to_ticks (ns=0) at kernel/xenomai/clock.c:52
> #2  0xc00baf34 in xnclock_ns_to_ticks (clock=<optimized out>, ns=<optimized out>)
>      at include/xenomai/cobalt/kernel/clock.h:204
> #3  xntimer_update_date (timer=0xde706518) at include/xenomai/cobalt/kernel/timer.h:268
> #4  xnclock_tick (clock=0xc06b1138 <nkclock>) at kernel/xenomai/clock.c:644
> #5  0xc00bcbcc in xnintr_core_clock_handler () at kernel/xenomai/intr.c:121
> #6  0xc0095a98 in dispatch_irq_head (irq=<optimized out>) at kernel/ipipe/core.c:1179
>
> This seems to be the endless loop:
> 642                     do {
> 643      timer->periodic_ticks += interval_ticks;
> 644      xntimer_update_date(timer);
> 645                     } while (xntimerh_date(&timer->aplink) < now + clock->gravity);
>
> gdb) info locals
> timerq = 0xdebdae98
> now = 4257712977
> interval_ticks = 0
> timer = 0xde706518
> delta = <optimized out>
> h = 0xde706518
>
> (gdb) print *timer
> $1 = {
>    aplink = {
>      link = {
>        next = 0x100100,
>        prev = 0x200200
>      },
>      key = 0,
>      prio = 999999999
>    },
>    adjlink = {
>      next = 0x0 <__vectors_start>,
>      prev = 0x0 <__vectors_start>
>    },
>    status = 1,
>    interval = 0,
>    interval_ns = 0,
>    periodic_ticks = 0,
>    start_date = 0,
>    pexpect_ticks = 0,
>    sched = 0xc06b1610 <nksched>,
>    handler = 0xc00c7dc4 <timeout_handler>,
>    name = "CREATOR", '\000' <repeats 24 times>,
>    handler_name = 0xc05ad429 "timeout_handler",
>    next_stat = {
>      next = 0xde706624,
>      prev = 0xde705c24
>    },
>    scheduled = {
>      counter = 3
>    },
>    fired = {
>      counter = 1
>    }
> }
> (gdb) print *clock
> $2 = {
>    wallclock_offset = 200209,
>    resolution = 1,
>    gravity = 140,
>    name = 0xc05ac815 "coreclk",
>    timerdata = 0xdebdae98,
>    id = -1,
>    vfile = {
>      entry = {
>        pde = 0xde1b8700,
>        file = 0x0 <__vectors_start>,
>        lockops = 0xc06b2c20 <xnvfile_nucleus_lock>,
>        refcnt = 0,
>        private = 0xc06b1138 <nkclock>
>      },
>      privsz = 4,
>      datasz = 104,
>      tag = 0xc06b117c <nkclock+68>,
>      ops = 0xc06b1120 <vfile_clock_ops>
>    },
>    revtag = {
>      rev = 36
>    },
>    statq = {
>      next = 0xc06b18d4 <nksched+708>,
>      prev = 0xde706e24
>    },
>    nrtimers = 24
> }
>
> Does anyone see right away what is going on wrong
> or shall I continue investigating the issue?
>

Assuming timer->interval_ns can't be null as the timer is deemed 
periodic, there must be something wrong with how the elapsed count of 
periodic ticks is tracked. Gilles will likely have a look at this when 
time allows.

-- 
Philippe.

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

[Gilles Chanteperdrix]

On 07/06/2014 11:48 AM, Matthias Schneider wrote:
> Hi all,
> 
> commit 
> 
> 2014-06-02 c20fceb147e337e2379b29ecd81b943318c7fbc7 
> (patch) cobalt/timer: avoid periodic timer drift
> 
> seems to cause an endless kernel loop in one of my
> freertos demos. The issue does not occur when 
> reverting this commit.
> 
> Investigating the issue, can see the following:
> 
> #0  0xc00ba45c in mach_arm_nodiv_llimd (rhs_integ=<optimized out>, frac=<optimized out>, op=<optimized out>)
>     at arch/arm/xenomai/include/asm/xenomai/uapi/arith.h:120
> #1  xnclock_core_ns_to_ticks (ns=0) at kernel/xenomai/clock.c:52
> #2  0xc00baf34 in xnclock_ns_to_ticks (clock=<optimized out>, ns=<optimized out>)
>     at include/xenomai/cobalt/kernel/clock.h:204
> #3  xntimer_update_date (timer=0xde706518) at include/xenomai/cobalt/kernel/timer.h:268
> #4  xnclock_tick (clock=0xc06b1138 <nkclock>) at kernel/xenomai/clock.c:644
> #5  0xc00bcbcc in xnintr_core_clock_handler () at kernel/xenomai/intr.c:121
> #6  0xc0095a98 in dispatch_irq_head (irq=<optimized out>) at kernel/ipipe/core.c:1179
> 
> This seems to be the endless loop:
> 642                     do {
> 643      timer->periodic_ticks += interval_ticks;
> 644      xntimer_update_date(timer);
> 645                     } while (xntimerh_date(&timer->aplink) < now + clock->gravity);
> 
> gdb) info locals
> timerq = 0xdebdae98
> now = 4257712977
> interval_ticks = 0
> timer = 0xde706518
> delta = <optimized out>
> h = 0xde706518
> 
> (gdb) print *timer
> $1 = {
>   aplink = {
>     link = {
>       next = 0x100100, 
>       prev = 0x200200
>     }, 
>     key = 0, 
>     prio = 999999999
>   }, 
>   adjlink = {
>     next = 0x0 <__vectors_start>, 
>     prev = 0x0 <__vectors_start>
>   }, 
>   status = 1, 
>   interval = 0, 
>   interval_ns = 0, 
>   periodic_ticks = 0, 
>   start_date = 0, 
>   pexpect_ticks = 0, 
>   sched = 0xc06b1610 <nksched>, 
>   handler = 0xc00c7dc4 <timeout_handler>, 
>   name = "CREATOR", '\000' <repeats 24 times>, 
>   handler_name = 0xc05ad429 "timeout_handler", 
>   next_stat = {
>     next = 0xde706624, 
>     prev = 0xde705c24
>   }, 
>   scheduled = {
>     counter = 3
>   }, 
>   fired = {
>     counter = 1
>   }
> }
> (gdb) print *clock
> $2 = {
>   wallclock_offset = 200209, 
>   resolution = 1, 
>   gravity = 140, 
>   name = 0xc05ac815 "coreclk", 
>   timerdata = 0xdebdae98, 
>   id = -1, 
>   vfile = {
>     entry = {
>       pde = 0xde1b8700, 
>       file = 0x0 <__vectors_start>, 
>       lockops = 0xc06b2c20 <xnvfile_nucleus_lock>, 
>       refcnt = 0, 
>       private = 0xc06b1138 <nkclock>
>     }, 
>     privsz = 4, 
>     datasz = 104, 
>     tag = 0xc06b117c <nkclock+68>, 
>     ops = 0xc06b1120 <vfile_clock_ops>
>   }, 
>   revtag = {
>     rev = 36
>   }, 
>   statq = {
>     next = 0xc06b18d4 <nksched+708>, 
>     prev = 0xde706e24
>   }, 
>   nrtimers = 24
> }
> 
> Does anyone see right away what is going on wrong 
> or shall I continue investigating the issue?

You seem to have created a periodic timer with a null period. Could you
post a sample code allowing to reproduce this issue?

-- 
                                                                Gilles.

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

[Matthias Schneider]

----- 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 5:01 PM
> Subject: Re: [Xenomai] issue with cobalt/timer: avoid periodic timer drift
> 
> On 07/06/2014 11:48 AM, Matthias Schneider wrote:
> 
>>  Hi all,
>> 
>>  commit 
>> 
>>  2014-06-02 c20fceb147e337e2379b29ecd81b943318c7fbc7 
>>  (patch) cobalt/timer: avoid periodic timer drift
>> 
>>  seems to cause an endless kernel loop in one of my
>>  freertos demos. The issue does not occur when 
>>  reverting this commit.
>> 
>>  Investigating the issue, can see the following:
>> 
>>  #0  0xc00ba45c in mach_arm_nodiv_llimd (rhs_integ=<optimized out>, 
> frac=<optimized out>, op=<optimized out>)
>>      at arch/arm/xenomai/include/asm/xenomai/uapi/arith.h:120
>>  #1  xnclock_core_ns_to_ticks (ns=0) at kernel/xenomai/clock.c:52
>>  #2  0xc00baf34 in xnclock_ns_to_ticks (clock=<optimized out>, 
> ns=<optimized out>)
>>      at include/xenomai/cobalt/kernel/clock.h:204
>>  #3  xntimer_update_date (timer=0xde706518) at 
> include/xenomai/cobalt/kernel/timer.h:268
>>  #4  xnclock_tick (clock=0xc06b1138 <nkclock>) at 
> kernel/xenomai/clock.c:644
>>  #5  0xc00bcbcc in xnintr_core_clock_handler () at kernel/xenomai/intr.c:121
>>  #6  0xc0095a98 in dispatch_irq_head (irq=<optimized out>) at 
> kernel/ipipe/core.c:1179
>> 
>>  This seems to be the endless loop:
>>  642                     do {
>>  643      timer->periodic_ticks += interval_ticks;
>>  644      xntimer_update_date(timer);
>>  645                     } while (xntimerh_date(&timer->aplink) < 
> now + clock->gravity);
>> 
>>  gdb) info locals
>>  timerq = 0xdebdae98
>>  now = 4257712977
>>  interval_ticks = 0
>>  timer = 0xde706518
>>  delta = <optimized out>
>>  h = 0xde706518
>> 
>>  (gdb) print *timer
>>  $1 = {
>>    aplink = {
>>      link = {
>>        next = 0x100100, 
>>        prev = 0x200200
>>      }, 
>>      key = 0, 
>>      prio = 999999999
>>    }, 
>>    adjlink = {
>>      next = 0x0 <__vectors_start>, 
>>      prev = 0x0 <__vectors_start>
>>    }, 
>>    status = 1, 
>>    interval = 0, 
>>    interval_ns = 0, 
>>    periodic_ticks = 0, 
>>    start_date = 0, 
>>    pexpect_ticks = 0, 
>>    sched = 0xc06b1610 <nksched>, 
>>    handler = 0xc00c7dc4 <timeout_handler>, 
>>    name = "CREATOR", '\000' <repeats 24 times>, 
>>    handler_name = 0xc05ad429 "timeout_handler", 
>>    next_stat = {
>>      next = 0xde706624, 
>>      prev = 0xde705c24
>>    }, 
>>    scheduled = {
>>      counter = 3
>>    }, 
>>    fired = {
>>      counter = 1
>>    }
>>  }
>>  (gdb) print *clock
>>  $2 = {
>>    wallclock_offset = 200209, 
>>    resolution = 1, 
>>    gravity = 140, 
>>    name = 0xc05ac815 "coreclk", 
>>    timerdata = 0xdebdae98, 
>>    id = -1, 
>>    vfile = {
>>      entry = {
>>        pde = 0xde1b8700, 
>>        file = 0x0 <__vectors_start>, 
>>        lockops = 0xc06b2c20 <xnvfile_nucleus_lock>, 
>>        refcnt = 0, 
>>        private = 0xc06b1138 <nkclock>
>>      }, 
>>      privsz = 4, 
>>      datasz = 104, 
>>      tag = 0xc06b117c <nkclock+68>, 
>>      ops = 0xc06b1120 <vfile_clock_ops>
>>    }, 
>>    revtag = {
>>      rev = 36
>>    }, 
>>    statq = {
>>      next = 0xc06b18d4 <nksched+708>, 
>>      prev = 0xde706e24
>>    }, 
>>    nrtimers = 24
>>  }
>> 
>>  Does anyone see right away what is going on wrong 
>>  or shall I continue investigating the issue?
> 
> 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?

Regards,
Matthias

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

[Gilles Chanteperdrix]

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?


-- 
                                                                Gilles.

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

[Matthias Schneider]

----- 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?

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

[Matthias Schneider]

----- 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...

Matthias

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

[Gilles Chanteperdrix]

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.

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

[Matthias Schneider]

----- 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:44 PM
> Subject: Re: [Xenomai] issue with cobalt/timer: avoid periodic timer drift
> 
> 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?


I assumed that if I would have create a periodic timer, status would at least
have been or'ed with 0x4. However, as can be seen in my initial post, the 
status value of the timer causing the problem was 1. Thats why I asked how 
you deduced that it was a periodic timer with a period of 0.

Matthias

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

[Gilles Chanteperdrix]

On 07/06/2014 06:56 PM, Matthias Schneider wrote:
> 
> 
> 
> 
> ----- 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:44 PM
>> Subject: Re: [Xenomai] issue with cobalt/timer: avoid periodic timer drift
>>
>> 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?
> 
> 
> I assumed that if I would have create a periodic timer, status would at least
> have been or'ed with 0x4. However, as can be seen in my initial post, the 
> status value of the timer causing the problem was 1. Thats why I asked how 
> you deduced that it was a periodic timer with a period of 0.

Because normally the loop is made for periodic timers. Are you running
inside gdb?


-- 
                                                                Gilles.

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

[Gilles Chanteperdrix]

On 07/06/2014 11:48 AM, Matthias Schneider wrote:
> Hi all,
> 
> commit 
> 
> 2014-06-02 c20fceb147e337e2379b29ecd81b943318c7fbc7 
> (patch) cobalt/timer: avoid periodic timer drift
> 
> seems to cause an endless kernel loop in one of my
> freertos demos. The issue does not occur when 
> reverting this commit.
> 
> Investigating the issue, can see the following:
> 
> #0  0xc00ba45c in mach_arm_nodiv_llimd (rhs_integ=<optimized out>, frac=<optimized out>, op=<optimized out>)
>     at arch/arm/xenomai/include/asm/xenomai/uapi/arith.h:120
> #1  xnclock_core_ns_to_ticks (ns=0) at kernel/xenomai/clock.c:52
> #2  0xc00baf34 in xnclock_ns_to_ticks (clock=<optimized out>, ns=<optimized out>)
>     at include/xenomai/cobalt/kernel/clock.h:204
> #3  xntimer_update_date (timer=0xde706518) at include/xenomai/cobalt/kernel/timer.h:268
> #4  xnclock_tick (clock=0xc06b1138 <nkclock>) at kernel/xenomai/clock.c:644
> #5  0xc00bcbcc in xnintr_core_clock_handler () at kernel/xenomai/intr.c:121
> #6  0xc0095a98 in dispatch_irq_head (irq=<optimized out>) at kernel/ipipe/core.c:1179
> 
> This seems to be the endless loop:
> 642                     do {
> 643      timer->periodic_ticks += interval_ticks;
> 644      xntimer_update_date(timer);
> 645                     } while (xntimerh_date(&timer->aplink) < now + clock->gravity);


I do not really understand how interval_ticks can be 0, but please try 
the following patch:

diff --git a/kernel/cobalt/clock.c b/kernel/cobalt/clock.c
index a578f89..1107f7a 100644
--- a/kernel/cobalt/clock.c
+++ b/kernel/cobalt/clock.c
@@ -619,10 +619,9 @@ void xnclock_tick(struct xnclock *clock)
 			 * wait for 250 ms for the user to continue
 			 * program execution.
 			 */
-			if (timer->interval_ns > 250000000)
-				goto advance;
-			interval_ticks = 250000000 /
-				(unsigned)timer->interval_ns;
+			xntimerh_date(&timer->aplink) +=
+				xnclock_ns_to_ticks(xntimer_clock(timer),
+						250000000);
 			goto requeue;
 		}
 	fire:
@@ -638,11 +637,11 @@ void xnclock_tick(struct xnclock *clock)
 			continue;
 	advance:
 		interval_ticks = 1;
-	requeue:
 		do {
 			timer->periodic_ticks += interval_ticks;
 			xntimer_update_date(timer);
 		} while (xntimerh_date(&timer->aplink) < now + clock->gravity);
+	requeue:
 #ifdef CONFIG_SMP
 		/*
 		 * Make sure to pick the right percpu queue, in case



-- 
                                                                Gilles.

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

[Matthias Schneider]

----- 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 7:04 PM
> Subject: Re: [Xenomai] issue with cobalt/timer: avoid periodic timer drift
> 
> On 07/06/2014 11:48 AM, Matthias Schneider wrote:
>>  Hi all,
>> 
>>  commit 
>> 
>>  2014-06-02 c20fceb147e337e2379b29ecd81b943318c7fbc7 
>>  (patch) cobalt/timer: avoid periodic timer drift
>> 
>>  seems to cause an endless kernel loop in one of my
>>  freertos demos. The issue does not occur when 
>>  reverting this commit.
>> 
>>  Investigating the issue, can see the following:
>> 
>>  #0  0xc00ba45c in mach_arm_nodiv_llimd (rhs_integ=<optimized out>, 
> frac=<optimized out>, op=<optimized out>)
>>      at arch/arm/xenomai/include/asm/xenomai/uapi/arith.h:120
>>  #1  xnclock_core_ns_to_ticks (ns=0) at kernel/xenomai/clock.c:52
>>  #2  0xc00baf34 in xnclock_ns_to_ticks (clock=<optimized out>, 
> ns=<optimized out>)
>>      at include/xenomai/cobalt/kernel/clock.h:204
>>  #3  xntimer_update_date (timer=0xde706518) at 
> include/xenomai/cobalt/kernel/timer.h:268
>>  #4  xnclock_tick (clock=0xc06b1138 <nkclock>) at 
> kernel/xenomai/clock.c:644
>>  #5  0xc00bcbcc in xnintr_core_clock_handler () at kernel/xenomai/intr.c:121
>>  #6  0xc0095a98 in dispatch_irq_head (irq=<optimized out>) at 
> kernel/ipipe/core.c:1179
>> 
>>  This seems to be the endless loop:
>>  642                     do {
>>  643      timer->periodic_ticks += interval_ticks;
>>  644      xntimer_update_date(timer);
>>  645                     } while (xntimerh_date(&timer->aplink) < 
> now + clock->gravity);
> 
> 
> I do not really understand how interval_ticks can be 0, but please try 
> the following patch:
> 
> diff --git a/kernel/cobalt/clock.c b/kernel/cobalt/clock.c
> index a578f89..1107f7a 100644
> --- a/kernel/cobalt/clock.c
> +++ b/kernel/cobalt/clock.c
> @@ -619,10 +619,9 @@ void xnclock_tick(struct xnclock *clock)
>              * wait for 250 ms for the user to continue
>              * program execution.
>              */
> -            if (timer->interval_ns > 250000000)
> -                goto advance;
> -            interval_ticks = 250000000 /
> -                (unsigned)timer->interval_ns;
> +            xntimerh_date(&timer->aplink) +=
> +                xnclock_ns_to_ticks(xntimer_clock(timer),
> +                        250000000);
>             goto requeue;
>         }
>     fire:
> @@ -638,11 +637,11 @@ void xnclock_tick(struct xnclock *clock)
>             continue;
>     advance:
>         interval_ticks = 1;
> -    requeue:
> 
>         do {
>             timer->periodic_ticks += interval_ticks;
>             xntimer_update_date(timer);
>         } while (xntimerh_date(&timer->aplink) < now + 
> clock->gravity);
> +    requeue:
> #ifdef CONFIG_SMP
>         /*
>          * Make sure to pick the right percpu queue, in case
> 


Hi Gilles,

thanks for the quick fix, it seems to resolve my problem. Yes,
in fact I was used gdb when the issues occured. 

Considering I entered the

if (unlikely(atomic_read(&nkclklk) > 0))
[...]
code path, a series of division by zeroes I had without a sensible backtrace
could also be explained (I was under the impression that it is possible to
get a backtrace of a division by zero exception on arm for some time now,
but it seems not to have worked for me).

Regards,
Matthias