From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <53B97CE2.5080700@xenomai.org> Date: Sun, 06 Jul 2014 18:44:18 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <1404640109.73994.YahooMailNeo@web171603.mail.ir2.yahoo.com> <53B964DC.1020004@xenomai.org> <1404662453.79446.YahooMailNeo@web171601.mail.ir2.yahoo.com> <53B974A3.5010004@xenomai.org> <1404664284.37181.YahooMailNeo@web171606.mail.ir2.yahoo.com> <1404664634.35911.YahooMailNeo@web171602.mail.ir2.yahoo.com> In-Reply-To: <1404664634.35911.YahooMailNeo@web171602.mail.ir2.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] issue with cobalt/timer: avoid periodic timer drift List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Matthias Schneider , "xenomai@xenomai.org" On 07/06/2014 06:37 PM, Matthias Schneider wrote: > ----- Original Message ----- > >> From: Matthias Schneider >> To: Gilles Chanteperdrix ; "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 >>> To: Matthias Schneider ; >> "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 , value=405804, >> interval=interval@entry=0, mode=mode@entry=XN_RELATIVE) at >> kernel/xenomai/timer.c:104 >> #1 0xc00ca504 in program_htick_shot (delay=, >> cdev=) at kernel/xenomai/timer.c:572 >> #2 0xc007407c in clockevents_program_event (dev=0xc06a65c0 >> , 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=) 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.