Re: [Xenomai-help] Problems with rt_task_wait_period

[Philippe Gerum <rpm@xenomai.org>]

On Mon, 2006-08-07 at 16:42 +0200, Steve Kreyer wrote:
> Ok problem fixed,
> 
> the last email was a typo by me :)
> If I increase the period to 1000 ns I get a system crash, when its 1us the task work like expected.

There's likely another typo here.

> But what does explain the System crash if the period is around 1000 ns?
> 

The bottom line is that, if the period is short enough, the timer code
ends up programming timer ticks way too often for the box to be able to
handle any other work than the one managing the timers... So this causes
a lock up (not necessarily a crash since there is no kernel exception
going on, only too much work for too little cpu time).

> Thanks 
> 
> Steve
> -----Ursprüngliche Nachricht-----
> Von: rpm@xenomai.org
> Gesendet: 07.08.06 16:32:17
> An: Jan Kiszka <jan.kiszka@domain.hid>
> CC: xenomai@xenomai.org
> Betreff: Re: [Xenomai-help] Problems with rt_task_wait_period
> 
> 
> On Mon, 2006-08-07 at 16:17 +0200, Jan Kiszka wrote:
> > Philippe Gerum wrote:
> > > On Mon, 2006-08-07 at 15:45 +0200, Jan Kiszka wrote:
> > >> Steve Kreyer wrote:
> > >>> Hi,
> > >>>
> > >>> Iam new to xenomai. 
> > >>> For warming up I try to run this little test program:
> > >>>
> > >>> -----------------------------------------------------------------------
> > >>> #include <native/task.h>
> > >>> #include <stdio.h>
> > >>> #include <sys/mman.h>
> > >>>
> > >>> RT_TASK task1;
> > >>>
> > >>> void rt_task1(void* user_data){
> > >>>     int err = 0;
> > >>>     printf("%d\n", rt_task_set_periodic(NULL, TM_NOW, 100));
> > >> You are running in one-shot mode, thus all time units are in
> > >> *nanoseconds*. 100 ns cycles tend to pass quite quickly, thus the setup
> > >> actually fails (but it doesn't report this - a corner case for
> > >> considering this a bug).
> > > 
> > > The setup does not really fail, but the period is so short that the tick
> > > occurs before the task has a chance to wait for the first release point
> > > in the timeline, so rt_task_wait_period() notices that no timer is
> > > outstanding, but incorrectly concludes that no timer was ever armed.
> > 
> > Mmh, wouldn't the box simply lock up if the setup succeeded? It's a
> > periodic timer... :->
> 
> No it would not, because of the first test in xnpod_wait_thread_period()
> that checks if the timer is still enqueued, and because the application
> properly tests the return value. Actually, using an additional flag to
> state that a timer has indeed been started would be better than
> recycling the enqueuing bit for the purpose of testing the timer
> validity. An elapsed timer is still a valid one.
> 
> > 
> > Jan
> > 
-- 
Philippe.