[Xenomai-help] Problems with rt_task_wait_period

[Xenomai-help] Problems with rt_task_wait_period

[Steve Kreyer]

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));
    err = rt_task_wait_period(NULL);
    if(err){
        fprintf(stderr, "Cannot wait periodic: %d, %d\n", err, EWOULDBLOCK);

    }
}

int main(){
    char* task1_data = NULL;
    mlockall(MCL_CURRENT|MCL_FUTURE);
    rt_timer_set_mode(TM_ONESHOT);
    rt_task_spawn(&task1, "task1", 0, 99, 0, rt_task1, &task1_data);
    sleep(10);
    rt_task_delete(&task1);
    return 0;
}
-----------------------------------------------------------------------

But rt_task_wait_period gives me always the Error EWOULDBLOCK, which means that I did not set the task periodic
but which in fact I did... The call to rt_task_set_periodic is succesful.
Can anyone help me figure out why? If you need additional infos please let me know...

Thanks in advance!

Steve

______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

Re: [Xenomai-help] Problems with rt_task_wait_period

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

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

>     err = rt_task_wait_period(NULL);
>     if(err){
>         fprintf(stderr, "Cannot wait periodic: %d, %d\n", err, EWOULDBLOCK);
> 
>     }
> }
> 
> int main(){
>     char* task1_data = NULL;
>     mlockall(MCL_CURRENT|MCL_FUTURE);
>     rt_timer_set_mode(TM_ONESHOT);
>     rt_task_spawn(&task1, "task1", 0, 99, 0, rt_task1, &task1_data);
>     sleep(10);
>     rt_task_delete(&task1);
>     return 0;
> }
> -----------------------------------------------------------------------
> 
> But rt_task_wait_period gives me always the Error EWOULDBLOCK, which means that I did not set the task periodic
> but which in fact I did... The call to rt_task_set_periodic is succesful.
> Can anyone help me figure out why? If you need additional infos please let me know...
> 
> Thanks in advance!
> 
> Steve
> 

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Problems with rt_task_wait_period

[Philippe Gerum]

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.

> 
> >     err = rt_task_wait_period(NULL);
> >     if(err){
> >         fprintf(stderr, "Cannot wait periodic: %d, %d\n", err, EWOULDBLOCK);
> > 
> >     }
> > }
> > 
> > int main(){
> >     char* task1_data = NULL;
> >     mlockall(MCL_CURRENT|MCL_FUTURE);
> >     rt_timer_set_mode(TM_ONESHOT);
> >     rt_task_spawn(&task1, "task1", 0, 99, 0, rt_task1, &task1_data);
> >     sleep(10);
> >     rt_task_delete(&task1);
> >     return 0;
> > }
> > -----------------------------------------------------------------------
> > 
> > But rt_task_wait_period gives me always the Error EWOULDBLOCK, which means that I did not set the task periodic
> > but which in fact I did... The call to rt_task_set_periodic is succesful.
> > Can anyone help me figure out why? If you need additional infos please let me know...
> > 
> > Thanks in advance!
> > 
> > Steve
> > 
> 
> Jan
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] Problems with rt_task_wait_period

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

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

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Problems with rt_task_wait_period

[Philippe Gerum]

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.

Re: [Xenomai-help] Problems with rt_task_wait_period

[Philippe Gerum]

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

What I meant is that there is nothing in xnpod_set_thread_periodic()
that actually checks if the settings are valid in the idate ==
XN_INFINITE case, therefore the setup never formally fails.

> 
> Jan
> 
-- 
Philippe.

Re: [Xenomai-help] Problems with rt_task_wait_period

[Steve Kreyer]

Hi,

thanks for your answers that sounds plausible to me :)
But another problem arises:
If I inrease the period from 100 to 1000000 ns in the posted program, I get a system crash :)

Regards,

Steve

-----Ursprüngliche Nachricht-----
Von: rpm@xenomai.org
Gesendet: 07.08.06 16:13:39
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 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.

> 
> >     err = rt_task_wait_period(NULL);
> >     if(err){
> >         fprintf(stderr, "Cannot wait periodic: %d, %d\n", err, EWOULDBLOCK);
> > 
> >     }
> > }
> > 
> > int main(){
> >     char* task1_data = NULL;
> >     mlockall(MCL_CURRENT|MCL_FUTURE);
> >     rt_timer_set_mode(TM_ONESHOT);
> >     rt_task_spawn(&task1, "task1", 0, 99, 0, rt_task1, &task1_data);
> >     sleep(10);
> >     rt_task_delete(&task1);
> >     return 0;
> > }
> > -----------------------------------------------------------------------
> > 
> > But rt_task_wait_period gives me always the Error EWOULDBLOCK, which means that I did not set the task periodic
> > but which in fact I did... The call to rt_task_set_periodic is succesful.
> > Can anyone help me figure out why? If you need additional infos please let me know...
> > 
> > Thanks in advance!
> > 
> > Steve
> > 
> 
> Jan
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.




__________________________________________________________________________
Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!		
Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131

Re: [Xenomai-help] Problems with rt_task_wait_period

[Steve Kreyer]

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.
But what does explain the System crash if the period is around 1000 ns?

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.




__________________________________________________________________________
Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!		
Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131

Re: [Xenomai-help] Problems with rt_task_wait_period

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 667 bytes --]

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.
                                                                     ^^^
I assume you mean 1 *ms* here, don't you?

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

Please use the term "crash" carefully. Preferred terms: crash == kernel
oops, lock-up == doesn't react on inputs anymore. ;)

1 us is still way too fast, even for the latest high-end GHz monster.
Your system entered an endless loop while trying to satisfy this request.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Problems with rt_task_wait_period

[Philippe Gerum]

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.