Re: [Xenomai-help] Problems with rt_task_wait_period

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.

[Xenomai-help] Timer problems?

[Steve Kreyer]

Hi,

Ive got a problem using periodic tasks, or timers in generally.
First of all the relevant piece of source:

-----------------------------------------------------------------------------------------------------
#define SLEEP_TIME 100000000

...

static void xmit(void* user_data){
    int err = 0;
    unsigned long timeout;
    err = rt_task_set_periodic(NULL, TM_NOW, SLEEP_TIME);
    if(err < 0){
        fprintf(stderr, "Error: Cannot set rt task 'xmit' periodic! 
errcode=%d\n", err);
        return;
    }
    err = rt_task_wait_period(&timeout);
    if(err < 0)
        fprintf(stderr, "Warning: Cannot wait for task period! 
errcode=%d timeout=%ld\n", err, timeout);
}
...
int main(){
    int err = 0;
    mlockall(MCL_CURRENT | MCL_FUTURE);
    signal(SIGINT, cleanup);
    err = rt_timer_set_mode(TM_ONESHOT);
    if(err < 0){
        fprintf(stderr, "Error: Cannot set rt timer mode to TM_ONESHOT! 
errcode=%d\n", err);
        return 1;
    }
    err = rt_task_spawn(&xmit_task, xmit_task_name, 0, XMIT_TASK_PRIO, 
T_FPU, xmit, NULL);
...
}
-------------------------------------------------------------------------------------------------------------

The task did not wait for the period to which it is set.
I get always an ETIMEDOUT error, and a timer overrun of 16 times when I 
try to call rt_task_wait_period...
Also another problem is, everytime I try to call rt_task_sleep or the 
standard linux library functions pause,sleep or usleep,
my system does not react on inputs anymore and I have to restart the 
machine...
Can anyone tell me whats going on there?
If you need additional informations, please let me know :)

Thanks in advance,
Steve

Re: [Xenomai-help] Timer problems?

[Jan Kiszka]

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

Steve Kreyer wrote:
> Hi,
> 
> Ive got a problem using periodic tasks, or timers in generally.
> First of all the relevant piece of source:
> 
> -----------------------------------------------------------------------------------------------------
> 
> #define SLEEP_TIME 100000000
> 
> ...
> 
> static void xmit(void* user_data){
>    int err = 0;
>    unsigned long timeout;
>    err = rt_task_set_periodic(NULL, TM_NOW, SLEEP_TIME);
>    if(err < 0){
>        fprintf(stderr, "Error: Cannot set rt task 'xmit' periodic!
> errcode=%d\n", err);
>        return;
>    }
>    err = rt_task_wait_period(&timeout);
>    if(err < 0)
>        fprintf(stderr, "Warning: Cannot wait for task period! errcode=%d
> timeout=%ld\n", err, timeout);
> }
> ...
> int main(){
>    int err = 0;
>    mlockall(MCL_CURRENT | MCL_FUTURE);
>    signal(SIGINT, cleanup);
>    err = rt_timer_set_mode(TM_ONESHOT);
>    if(err < 0){
>        fprintf(stderr, "Error: Cannot set rt timer mode to TM_ONESHOT!
> errcode=%d\n", err);
>        return 1;
>    }
>    err = rt_task_spawn(&xmit_task, xmit_task_name, 0, XMIT_TASK_PRIO,
> T_FPU, xmit, NULL);
> ...
> }
> -------------------------------------------------------------------------------------------------------------
> 
> 
> The task did not wait for the period to which it is set.
> I get always an ETIMEDOUT error, and a timer overrun of 16 times when I
> try to call rt_task_wait_period...
> Also another problem is, everytime I try to call rt_task_sleep or the
> standard linux library functions pause,sleep or usleep,
> my system does not react on inputs anymore and I have to restart the
> machine...
> Can anyone tell me whats going on there?
> If you need additional informations, please let me know :)
> 

Your example (with slight modifications) works fine, and the other
effect you listed here clearly indicates some fundamental problem of
your box. Does the kernel log contain any suspicious messages,
specifically after that input lock-up? If not, please provide a precise
setup description: Xenomai version, kernel version + ipipe revision,
hardware description (e.g. the architecture), and the .config of your
system (zipped please).

Jan


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

[Xenomai-help] Re: Timer problems?

[Bernhard Walle]

Hello,

first of all: you replied to a previous mail which results in a broken
thread three in the mail client ... Pleaes create new mail for new
requests.

* Steve Kreyer <steve.kreyer@domain.hid> [2006-08-25 17:31]:
> #define SLEEP_TIME 100000000
...
> The task did not wait for the period to which it is set.
> I get always an ETIMEDOUT error, and a timer overrun of 16 times when I 
> try to call rt_task_wait_period...

The example you've provided exits immediately here because you don't
wait in the main() function.

I modified your example to work:
http://pastie.caboo.se/10259

> Also another problem is, everytime I try to call rt_task_sleep or the 
> standard linux library functions pause,sleep or usleep,
> my system does not react on inputs anymore and I have to restart the 
> machine...
> Can anyone tell me whats going on there?
> If you need additional informations, please let me know :)

No problem here, for example I call sleep(2) in the RT thread and it
work. Calling Linux functions in RT code should work in Xenomai,
although it's not hard realtime safe any more because the thread gets
switched to the Linux scheduler.

Just for comparison:
I'm running Xenomai 2.1 with Kernel 2.6.15.7 on Debian 3.1.


Regards,
  Bernhard

Re: [Xenomai-help] Timer problems?

[Steve Kreyer]

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

Hi Jan,

first of all thanks for your answer.
Jan Kiszka wrote:
> Your example (with slight modifications) works fine, and the other
> effect you listed here clearly indicates some fundamental problem of
> your box. Does the kernel log contain any suspicious messages,
>   
> specifically after that input lock-up? 
No the kernel log says nothing on this lock...
> If not, please provide a precise
> setup description: Xenomai version,
cat /proc/xenomai/version
2.2
I have also attached the config.log of the xenomai configuration to this 
email, if this
could be meaningful to figure out the problem...
>  kernel version + ipipe revision,
>   
cat /proc/ipipe/version
1.3-07

uname -a
Linux euklid 2.6.152.6.15 #6 SMP PREEMPT Sun Aug 6 17:02:34 CEST 2006 
i686 GNU/Linux

> hardware description (e.g. the architecture), 
It is a x86 system, Pentium 4 (~ 3 years old)
cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 1
model name      : Intel(R) Pentium(R) 4 CPU 1.60GHz
stepping        : 2
cpu MHz         : 1600.244
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips        : 3207.69

> and the .config of your
> system (zipped please).
>   
Ok, it is attached...
> Jan
>
>   

Regards,
Steve

[-- Attachment #2: kernel-config.gz --]
[-- Type: application/gzip, Size: 8101 bytes --]

[-- Attachment #3: xenomai-config.log.gz --]
[-- Type: application/gzip, Size: 9066 bytes --]

Re: [Xenomai-help] Re: Timer problems?

[Steve Kreyer]

Hi Bernhard, :)
Bernhard Walle wrote:
> Hello,
>
> first of all: you replied to a previous mail which results in a broken
> thread three in the mail client ... Pleaes create new mail for new
> requests.
> The example you've provided exits immediately here because you don't
> wait in the main() function.
>   
Yes, Iam aware of this, but in fact the waiting via pause or sleep in 
the Linux process (main function)
failed and results in a system lock up.
> I modified your example to work:
> http://pastie.caboo.se/10259
>   
The trick of calling rt_task_join instead of doing a pause is a nice 
idea, but it doesn't solve my problem fully(see below*).
>
> No problem here, for example I call sleep(2) in the RT thread and it
> work. 
It is not my concern to call a standard linux function in the RT task.
> Calling Linux functions in RT code should work in Xenomai,
> although it's not hard realtime safe any more because the thread gets
> switched to the Linux scheduler.
>   
*The reason of my request was to figure out why any of the standard 
linux functions
(e.g. pause, sleep,..., whether called from the linux or RT task) 
results in a system lock up and why the  functions rt_task_wait and
rt_task_sleep, for example, produce the error behaviour described in the 
first mail.

So I think of an timer issue, or a wrong xenomai configuration or 
something like this, but can't really
figure out the problem...
> Just for comparison:
> I'm running Xenomai 2.1 with Kernel 2.6.15.7 on Debian 3.1.
>   
Iam running Xenomai version 2.2 and Kernel 2.6.15 on a kanotix system.
>
> Regards,
>   Bernhard
>
>
>
>   
Thanks for your help and time.

Regards,
Steve

Re: [Xenomai-help] Re: Timer problems?

[Bernhard Walle]

[-- Attachment #1.1: Type: text/plain, Size: 2342 bytes --]

Hi Steve,

* Steve Kreyer <steve.kreyer@domain.hid> [2006-08-26 23:23]:
> Bernhard Walle wrote:
> >
> >first of all: you replied to a previous mail which results in a broken
> >thread three in the mail client ... Pleaes create new mail for new
> >requests.
> >The example you've provided exits immediately here because you don't
> >wait in the main() function.
>
> Yes, Iam aware of this, but in fact the waiting via pause or sleep
> in the Linux process (main function) failed and results in a system
> lock up.

Ah, now I understand. :)

> >I modified your example to work:
> >http://pastie.caboo.se/10259
> [...]
> >No problem here, for example I call sleep(2) in the RT thread and it
> >work. 
> [...]
> >Calling Linux functions in RT code should work in Xenomai,
> >although it's not hard realtime safe any more because the thread gets
> >switched to the Linux scheduler.
>
> *The reason of my request was to figure out why any of the standard
> linux functions (e.g. pause, sleep,..., whether called from the
> linux or RT task) results in a system lock up and why the  functions
> rt_task_wait and rt_task_sleep, for example, produce the error
> behaviour described in the first mail.
> 
> So I think of an timer issue, or a wrong xenomai configuration or
> something like this, but can't really figure out the problem...

Well, this is something I also don't know. But I'm sure that Jan or
Philippe can help -- they're the experts here. :)

The only thing I could offer is my kernel .config which is attached.

> >Just for comparison:
> >I'm running Xenomai 2.1 with Kernel 2.6.15.7 on Debian 3.1.
>
> Iam running Xenomai version 2.2 and Kernel 2.6.15 on a kanotix system.

Maybe try 2.1 with my kernel configuration to figure out if it's a
strange hardware "bug" or something in the configuration or a bad
combination of kernel/patch/Xenomai.

I had some similar problem with RTAI, but less problematic, the system
was only frozen when issuing a rt_printk() from LXRT (userspace). The
solution was to update the kernel.

I use a 500 MHz P III, don't know how old, it's from my employer. :)


Regards,
  Bernhard
-- 
Die Freiheit des Menschen liegt nicht darin, dass er tun kann, was er will, 
sondern dass er nicht tun muss, was er nicht will.
	-- Jean-Jacques Rousseau

[-- Attachment #1.2: config-2.6.15.7-xenomainodebug.gz --]
[-- Type: application/x-gzip, Size: 6377 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]

Re: [Xenomai-help] Re: Timer problems?

[Philippe Gerum]

On Sat, 2006-08-26 at 23:23 +0200, Steve Kreyer wrote:
> Hi Bernhard, :)
> Bernhard Walle wrote:
> > Hello,
> >
> > first of all: you replied to a previous mail which results in a broken
> > thread three in the mail client ... Pleaes create new mail for new
> > requests.
> > The example you've provided exits immediately here because you don't
> > wait in the main() function.
> >   
> Yes, Iam aware of this, but in fact the waiting via pause or sleep in 
> the Linux process (main function)
> failed and results in a system lock up.

The latency test issues a number of native API calls mixed with standard
glibc calls. Does it run on your box?

Btw, your .config shows that PM is enabled, which is a known source of
latency problems; you should disable it. Additionally, make sure to read
the TROUBLESHOOTING file thoroughly: a number of configuration caveats
for x86 are explained, including the PM one.

Last point: the kernel shipped by Kanotix might have been patched up
beyond all recognition. Did the Adeos patch apply cleanly against it?

-- 
Philippe.

Re: [Xenomai-help] Re: Timer problems?

[Steve Kreyer]

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

Hi Philippe,

disabling PM in Kernel was a good tip!

Now I can call standard linux library functions without resulting in a 
system lock up :)
But the ETIMEDOUT error when calling e.g. rt_task_wait_period or 
rt_task_sleep still persists.
The latency test gives me the following output:

-------------------------------------------------------------------------------------------------------------------
== Test mode: periodic user-mode task
== All results in microseconds
latency: failed to set periodic, code -110
warming up...
---|------------|------------|------------|--------|-------------------------
RTS| -208983.489|       0.000|  208983.489|       0|    00:00:26/00:00:26
-------------------------------------------------------------------------------------------------------------------

Also the attached application produces the below output:
-------------------------------------------------------------------------------------------------------------------
working!
working!
Warning: Cannot wait for task period! errcode=-110 110 timeout=1
working!
Warning: Cannot wait for task period! errcode=-110 110 timeout=1
-------------------------------------------------------------------------------------------------------------------

The output string "working!" and the warning messages printed at once 
and not as expected every second (see attachment)...
The TROUBLESHOOTING file has no answer to this behaviour...

Do you have any hints on this?

Regards,
Steve

Philippe Gerum wrote:
> On Sat, 2006-08-26 at 23:23 +0200, Steve Kreyer wrote:
>   
>> Hi Bernhard, :)
>> Bernhard Walle wrote:
>>     
>>> Hello,
>>>
>>> first of all: you replied to a previous mail which results in a broken
>>> thread three in the mail client ... Pleaes create new mail for new
>>> requests.
>>> The example you've provided exits immediately here because you don't
>>> wait in the main() function.
>>>   
>>>       
>> Yes, Iam aware of this, but in fact the waiting via pause or sleep in 
>> the Linux process (main function)
>> failed and results in a system lock up.
>>     
>
> The latency test issues a number of native API calls mixed with standard
> glibc calls. Does it run on your box?
>
> Btw, your .config shows that PM is enabled, which is a known source of
> latency problems; you should disable it. Additionally, make sure to read
> the TROUBLESHOOTING file thoroughly: a number of configuration caveats
> for x86 are explained, including the PM one.
>
> Last point: the kernel shipped by Kanotix might have been patched up
> beyond all recognition. Did the Adeos patch apply cleanly against it?
>
>   


[-- Attachment #2: example.c.gz --]
[-- Type: application/gzip, Size: 611 bytes --]

Re: [Xenomai-help] Re: Timer problems?

[Steve Kreyer]

P.S. I have overlook your last question:
Philippe Gerum wrote:
> Last point: the kernel shipped by Kanotix might have been patched up
> beyond all recognition. Did the Adeos patch apply cleanly against it?
>
>   
Yes it does, at least there are no error or warning messages while patching
the kernel...
I have also installed xenomai on another machine running  kanotix, and 
this works fine...

Regards,
Steve

Re: [Xenomai-help] Re: Timer problems?

[Philippe Gerum]

On Sun, 2006-08-27 at 11:21 +0200, Steve Kreyer wrote:
> Hi Philippe,
> 
> disabling PM in Kernel was a good tip!
> 
> Now I can call standard linux library functions without resulting in a 
> system lock up :)
> But the ETIMEDOUT error when calling e.g. rt_task_wait_period or 
> rt_task_sleep still persists.
> The latency test gives me the following output:
> 
> -------------------------------------------------------------------------------------------------------------------
> == Test mode: periodic user-mode task
> == All results in microseconds
> latency: failed to set periodic, code -110
> warming up...
> ---|------------|------------|------------|--------|-------------------------
> RTS| -208983.489|       0.000|  208983.489|       0|    00:00:26/00:00:26
> -------------------------------------------------------------------------------------------------------------------
> 
> Also the attached application produces the below output:
> -------------------------------------------------------------------------------------------------------------------
> working!
> working!
> Warning: Cannot wait for task period! errcode=-110 110 timeout=1
> working!
> Warning: Cannot wait for task period! errcode=-110 110 timeout=1
> -------------------------------------------------------------------------------------------------------------------
> 
> The output string "working!" and the warning messages printed at once 
> and not as expected every second (see attachment)...
> The TROUBLESHOOTING file has no answer to this behaviour...
> 
> Do you have any hints on this?
> 

Try disabling ACPI completely, just to see if it is somehow involved.

-- 
Philippe.

Re: [Xenomai-help] Re: Timer problems?

[Gilles Chanteperdrix]

Steve Kreyer wrote:
 > Hi Philippe,
 > 
 > disabling PM in Kernel was a good tip!
 > 
 > Now I can call standard linux library functions without resulting in a 
 > system lock up :)
 > But the ETIMEDOUT error when calling e.g. rt_task_wait_period or 
 > rt_task_sleep still persists.

Could you try enabling the SMI workaround ?

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] Timer problems?

[Jan Kiszka]

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

Steve Kreyer wrote:
> Hi Jan,
> 
> first of all thanks for your answer.
> Jan Kiszka wrote:
>> Your example (with slight modifications) works fine, and the other
>> effect you listed here clearly indicates some fundamental problem of
>> your box. Does the kernel log contain any suspicious messages,
>>   specifically after that input lock-up? 
> No the kernel log says nothing on this lock...
>> If not, please provide a precise
>> setup description: Xenomai version,
> cat /proc/xenomai/version
> 2.2
> I have also attached the config.log of the xenomai configuration to this
> email, if this
> could be meaningful to figure out the problem...
>>  kernel version + ipipe revision,
>>   
> cat /proc/ipipe/version
> 1.3-07
> 
> uname -a
> Linux euklid 2.6.152.6.15 #6 SMP PREEMPT Sun Aug 6 17:02:34 CEST 2006
> i686 GNU/Linux

Any particular reason to use 2.6.15? Though this should not be the
problem here, it's generally better to use a patch that comes with the
particular Xenomai version - it gained a better test coverage.

> 
>> hardware description (e.g. the architecture), 
> It is a x86 system, Pentium 4 (~ 3 years old)

...but you have configured your processor to be from the pre-Pentium era
(CONFIG_M586). Suboptimal because TSC support is disabled, TSC emulation
is enabled.

Moreover, and that's likely another reason for troubles here, you have
CONFIG_VT on. This normally unproblematic features collides with the TSC
emulation of Xenomai. SVN head warns you about this conflict, 2.2 not
yet. Solution: pick a more appropriate processor type.

> cat /proc/cpuinfo
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 15
> model           : 1
> model name      : Intel(R) Pentium(R) 4 CPU 1.60GHz
> stepping        : 2
> cpu MHz         : 1600.244
> cache size      : 256 KB
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 2
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
> bogomips        : 3207.69
> 
>> and the .config of your
>> system (zipped please).
>>   
> Ok, it is attached...
>> Jan
>>
>>   
> 
> Regards,
> Steve

There are a two more suboptimal (but unproblematic settings):

 o CONFIG_SMP: unless your system can be enhanced with more CPUs, switch
   it off
 o CONFIG_XENO_OPT_TIMING_PERIODIC: this is only required, if you
   actually need periodic timer mode (instead of one-shot mode)

And, again, I would take the chance when recompiling anyway to upgrade
the kernel version.

HTH,
Jan


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

Re: [Xenomai-help] Timer problems?

[Philippe Gerum]

> Moreover, and that's likely another reason for troubles here, you have
> CONFIG_VT on. This normally unproblematic features collides with the TSC
> emulation of Xenomai.

I'll jump on this, since this likely deserves some detailed
explanations:

The general problem with CONFIG_VT, is the tone generator it uses to
send bell events to the user, issued by the keyboard management code. On
x86, the related kernel code fiddles with the legacy programmable
interrupt timer (PIT) to create an audible tone, specifically this
chip's channels #0 and #2.

And the problem starts here: when there is no TSC available to the
kernel, whether because there is none provided by the CPU, or its
support has been disabled in the kernel configuration (i.e.
CONFIG_X86_TSC unset), then Xenomai uses the PIT to emulate a kind of
poor man's TSC, so that it can eventually get a monotonic clock. To this
end, Xenomai will also use the PIT's channel #2, as a free running
counter. Hence the conflict with CONFIG_VT.

But there is more: On x86, Xenomai also uses the PIT's channels #0 and
#1 when undergoing the oneshot timing mode, exclusively for kernel
configurations which do not provide APIC support (i.e.
CONFIG_X86_LOCAL_APIC unset, because none of CONFIG_X86_UP_APIC and
CONFIG_SMP are set). In such a case, the PC speaker management code
generating the tone will badly conflict with the Xenomai system timer
too, causing all sorts of erratic behaviours, since both step on each
other's toes when programming the PIT's channel #0.

With Linux 2.4, the sound generator is reached through a callback
pointer, so Xenomai just routes the latter to a dummy routine, and we
are done. With Linux 2.6, the callback has disappeared from the vanilla
kernel, and sound event requests are sent to the input sub-system for
processing, where we have currently no hack to void them. This is the
reason why disabling CONFIG_VT entirely is recommended when there is a
risk of conflict (which is rather drastic, I agree).

To sum up:
- The CONFIG_VT issue is in fact a conflict between the regular PC
speaker code and Xenomai.
- It is strictly a x86 issue.
- It is automatically solved by Xenomai over Linux 2.4, and should be
solved by disabling CONFIG_VT entirely over Linux 2.6 for configurations
which do not provide APIC or even TSC support, at least until Adeos
eventually silences this code, on demand, to help us.

Since you have a P4, you do have a local APIC on your chip, so you
should enable it for a uni-processor configuration (CONFIG_X86_UP_APIC),
since it has far better performances latency-wise than the legacy
programmable interrupt controller. You also have a TSC, and the kernel
should use it automatically, provided the P4 CPU is properly selected in
your kernel configuration, as Jan pointed out.
With this configuration, you should not have to care about CONFIG_VT
anymore.

-- 
Philippe.

Re: [Xenomai-help] Timer problems?

[Bernhard Walle]

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

Hello Philippe,

* Philippe Gerum <rpm@xenomai.org> [2006-08-27 14:08]:
> With Linux 2.4, the sound generator is reached through a callback
> pointer, so Xenomai just routes the latter to a dummy routine, and we
> are done. With Linux 2.6, the callback has disappeared from the vanilla
> kernel, and sound event requests are sent to the input sub-system for
> processing, where we have currently no hack to void them. This is the
> reason why disabling CONFIG_VT entirely is recommended when there is a
> risk of conflict (which is rather drastic, I agree).

Why not patching the kernel at this point? Xenomai requires a kernel
patch anyway.


Regards, 
  Bernhard

[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]

Re: [Xenomai-help] Timer problems?

[Gilles Chanteperdrix]

Philippe Gerum wrote:
 > - It is automatically solved by Xenomai over Linux 2.4, and should be
 > solved by disabling CONFIG_VT entirely over Linux 2.6 for configurations

Disabling PC speaker is not enough to avoid the conflict on 2.6 ?

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] Timer problems?

[Steve Kreyer]

Hi,

Jan Kiszka wrote:
>> ...but you have configured your processor to be from the pre-Pentium era
>> (CONFIG_M586). Suboptimal because TSC support is disabled, TSC emulation
>> is enabled.
>>
>> Moreover, and that's likely another reason for troubles here, you have
>> CONFIG_VT on. This normally unproblematic features collides with the TSC
>> emulation of Xenomai. SVN head warns you about this conflict, 2.2 not
>> yet. Solution: pick a more appropriate processor type.
>>   
this was the point... I have now recompiled the kernel with an updated 
version and set the processor type option to "pentium 4",
and now the tsc work like expected...

You guys helped me to get out from big trouble :) Thank you!

Regards,
Steve

Re: [Xenomai-help] Timer problems?

[Philippe Gerum]

On Sun, 2006-08-27 at 14:34 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>  > - It is automatically solved by Xenomai over Linux 2.4, and should be
>  > solved by disabling CONFIG_VT entirely over Linux 2.6 for configurations
> 
> Disabling PC speaker is not enough to avoid the conflict on 2.6 ?
> 

CONFIG_INPUT_PCSPKR? Yes, it should actually be even better, since I
don't see any dependency of CONFIG_VT on CONFIG_INPUT_PCSPKR. Only the
input sub-system infrastructure is required.

-- 
Philippe.

Re: [Xenomai-help] Timer problems?

[Steve Kreyer]

Philippe Gerum wrote:
>> Moreover, and that's likely another reason for troubles here, you have
>> CONFIG_VT on. This normally unproblematic features collides with the TSC
>> emulation of Xenomai.
>>     
>
> I'll jump on this, since this likely deserves some detailed
> explanations:
>
> The general problem with CONFIG_VT, is the tone generator it uses to
> send bell events to the user, issued by the keyboard management code. On
> x86, the related kernel code fiddles with the legacy programmable
> interrupt timer (PIT) to create an audible tone, specifically this
> chip's channels #0 and #2.
>
> And the problem starts here: when there is no TSC available to the
> kernel, whether because there is none provided by the CPU, or its
> support has been disabled in the kernel configuration (i.e.
> CONFIG_X86_TSC unset), then Xenomai uses the PIT to emulate a kind of
> poor man's TSC, so that it can eventually get a monotonic clock. To this
> end, Xenomai will also use the PIT's channel #2, as a free running
> counter. Hence the conflict with CONFIG_VT.
>
> But there is more: On x86, Xenomai also uses the PIT's channels #0 and
> #1 when undergoing the oneshot timing mode, exclusively for kernel
> configurations which do not provide APIC support (i.e.
> CONFIG_X86_LOCAL_APIC unset, because none of CONFIG_X86_UP_APIC and
> CONFIG_SMP are set). In such a case, the PC speaker management code
> generating the tone will badly conflict with the Xenomai system timer
> too, causing all sorts of erratic behaviours, since both step on each
> other's toes when programming the PIT's channel #0.
>
> With Linux 2.4, the sound generator is reached through a callback
> pointer, so Xenomai just routes the latter to a dummy routine, and we
> are done. With Linux 2.6, the callback has disappeared from the vanilla
> kernel, and sound event requests are sent to the input sub-system for
> processing, where we have currently no hack to void them. This is the
> reason why disabling CONFIG_VT entirely is recommended when there is a
> risk of conflict (which is rather drastic, I agree).
>
> To sum up:
> - The CONFIG_VT issue is in fact a conflict between the regular PC
> speaker code and Xenomai.
> - It is strictly a x86 issue.
> - It is automatically solved by Xenomai over Linux 2.4, and should be
> solved by disabling CONFIG_VT entirely over Linux 2.6 for configurations
> which do not provide APIC or even TSC support, at least until Adeos
> eventually silences this code, on demand, to help us.
>
> Since you have a P4, you do have a local APIC on your chip, so you
> should enable it for a uni-processor configuration (CONFIG_X86_UP_APIC),
> since it has far better performances latency-wise than the legacy
> programmable interrupt controller. You also have a TSC, and the kernel
> should use it automatically, provided the P4 CPU is properly selected in
> your kernel configuration, as Jan pointed out.
> With this configuration, you should not have to care about CONFIG_VT
> anymore.
>
>   
Ok I try to sum up the points to see if I understand your explanation right:
On an x86 architecture xenomai uses the PIT to emulate a tsc, but the
PIT is also used by the VT to generate the speaker tone. And if I don't
disable CONFIG_VT, or the Linux speaker code, things get messed up.
But If I had an pentium architecture where tsc is provided, xenomai can
take care of this and directly uses the tsc supported by the pentium 
chip, assumed that the kernel
is configured to a pentium.
Am I right, could you ack this?

Regards,
Steve

Re: [Xenomai-help] Timer problems?

[Jan Kiszka]

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

Philippe Gerum wrote:
> On Sun, 2006-08-27 at 14:34 +0200, Gilles Chanteperdrix wrote:
>> Philippe Gerum wrote:
>>  > - It is automatically solved by Xenomai over Linux 2.4, and should be
>>  > solved by disabling CONFIG_VT entirely over Linux 2.6 for configurations
>>
>> Disabling PC speaker is not enough to avoid the conflict on 2.6 ?
>>
> 
> CONFIG_INPUT_PCSPKR? Yes, it should actually be even better, since I
> don't see any dependency of CONFIG_VT on CONFIG_INPUT_PCSPKR. Only the
> input sub-system infrastructure is required.
>

For sure, it's CONFIG_INPUT_PCSPKR (that's also what we are now testing
for in 2.3-devel). My bad, I confused some options.

Jan


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

Re: [Xenomai-help] Timer problems?

[Philippe Gerum]

On Sun, 2006-08-27 at 15:47 +0200, Steve Kreyer wrote:
> Philippe Gerum wrote:
> >> Moreover, and that's likely another reason for troubles here, you have
> >> CONFIG_VT on. This normally unproblematic features collides with the TSC
> >> emulation of Xenomai.
> >>     
> >
> > I'll jump on this, since this likely deserves some detailed
> > explanations:
> >
> > The general problem with CONFIG_VT, is the tone generator it uses to
> > send bell events to the user, issued by the keyboard management code. On
> > x86, the related kernel code fiddles with the legacy programmable
> > interrupt timer (PIT) to create an audible tone, specifically this
> > chip's channels #0 and #2.
> >
> > And the problem starts here: when there is no TSC available to the
> > kernel, whether because there is none provided by the CPU, or its
> > support has been disabled in the kernel configuration (i.e.
> > CONFIG_X86_TSC unset), then Xenomai uses the PIT to emulate a kind of
> > poor man's TSC, so that it can eventually get a monotonic clock. To this
> > end, Xenomai will also use the PIT's channel #2, as a free running
> > counter. Hence the conflict with CONFIG_VT.
> >
> > But there is more: On x86, Xenomai also uses the PIT's channels #0 and
> > #1 when undergoing the oneshot timing mode, exclusively for kernel
> > configurations which do not provide APIC support (i.e.
> > CONFIG_X86_LOCAL_APIC unset, because none of CONFIG_X86_UP_APIC and
> > CONFIG_SMP are set). In such a case, the PC speaker management code
> > generating the tone will badly conflict with the Xenomai system timer
> > too, causing all sorts of erratic behaviours, since both step on each
> > other's toes when programming the PIT's channel #0.
> >
> > With Linux 2.4, the sound generator is reached through a callback
> > pointer, so Xenomai just routes the latter to a dummy routine, and we
> > are done. With Linux 2.6, the callback has disappeared from the vanilla
> > kernel, and sound event requests are sent to the input sub-system for
> > processing, where we have currently no hack to void them. This is the
> > reason why disabling CONFIG_VT entirely is recommended when there is a
> > risk of conflict (which is rather drastic, I agree).
> >
> > To sum up:
> > - The CONFIG_VT issue is in fact a conflict between the regular PC
> > speaker code and Xenomai.
> > - It is strictly a x86 issue.
> > - It is automatically solved by Xenomai over Linux 2.4, and should be
> > solved by disabling CONFIG_VT entirely over Linux 2.6 for configurations
> > which do not provide APIC or even TSC support, at least until Adeos
> > eventually silences this code, on demand, to help us.
> >
> > Since you have a P4, you do have a local APIC on your chip, so you
> > should enable it for a uni-processor configuration (CONFIG_X86_UP_APIC),
> > since it has far better performances latency-wise than the legacy
> > programmable interrupt controller. You also have a TSC, and the kernel
> > should use it automatically, provided the P4 CPU is properly selected in
> > your kernel configuration, as Jan pointed out.
> > With this configuration, you should not have to care about CONFIG_VT
> > anymore.
> >
> >   
> Ok I try to sum up the points to see if I understand your explanation right:
> On an x86 architecture xenomai uses the PIT to emulate a tsc,

and provide oneshot timing support,

>  but the
> PIT is also used by the VT to generate the speaker tone. And if I don't
> disable CONFIG_VT, or the Linux speaker code, things get messed up.
> But If I had an pentium architecture where tsc is provided, xenomai can
> take care of this and directly uses the tsc supported by the pentium 
> chip, assumed that the kernel
> is configured to a pentium.
> Am I right, could you ack this?
> 

Ack.

> Regards,
> Steve
> 
-- 
Philippe.

Re: [Xenomai-help] Timer problems?

[Philippe Gerum]

On Sun, 2006-08-27 at 16:22 +0200, Philippe Gerum wrote:
> On Sun, 2006-08-27 at 15:47 +0200, Steve Kreyer wrote:
> > Philippe Gerum wrote:
> > >> Moreover, and that's likely another reason for troubles here, you have
> > >> CONFIG_VT on. This normally unproblematic features collides with the TSC
> > >> emulation of Xenomai.
> > >>     
> > >
> > > I'll jump on this, since this likely deserves some detailed
> > > explanations:
> > >
> > > The general problem with CONFIG_VT, is the tone generator it uses to
> > > send bell events to the user, issued by the keyboard management code. On
> > > x86, the related kernel code fiddles with the legacy programmable
> > > interrupt timer (PIT) to create an audible tone, specifically this
> > > chip's channels #0 and #2.
> > >
> > > And the problem starts here: when there is no TSC available to the
> > > kernel, whether because there is none provided by the CPU, or its
> > > support has been disabled in the kernel configuration (i.e.
> > > CONFIG_X86_TSC unset), then Xenomai uses the PIT to emulate a kind of
> > > poor man's TSC, so that it can eventually get a monotonic clock. To this
> > > end, Xenomai will also use the PIT's channel #2, as a free running
> > > counter. Hence the conflict with CONFIG_VT.
> > >
> > > But there is more: On x86, Xenomai also uses the PIT's channels #0 and
> > > #1 when undergoing the oneshot timing mode, exclusively for kernel
> > > configurations which do not provide APIC support (i.e.
> > > CONFIG_X86_LOCAL_APIC unset, because none of CONFIG_X86_UP_APIC and
> > > CONFIG_SMP are set). In such a case, the PC speaker management code
> > > generating the tone will badly conflict with the Xenomai system timer
> > > too, causing all sorts of erratic behaviours, since both step on each
> > > other's toes when programming the PIT's channel #0.
> > >
> > > With Linux 2.4, the sound generator is reached through a callback
> > > pointer, so Xenomai just routes the latter to a dummy routine, and we
> > > are done. With Linux 2.6, the callback has disappeared from the vanilla
> > > kernel, and sound event requests are sent to the input sub-system for
> > > processing, where we have currently no hack to void them. This is the
> > > reason why disabling CONFIG_VT entirely is recommended when there is a
> > > risk of conflict (which is rather drastic, I agree).
> > >
> > > To sum up:
> > > - The CONFIG_VT issue is in fact a conflict between the regular PC
> > > speaker code and Xenomai.
> > > - It is strictly a x86 issue.
> > > - It is automatically solved by Xenomai over Linux 2.4, and should be
> > > solved by disabling CONFIG_VT entirely over Linux 2.6 for configurations
> > > which do not provide APIC or even TSC support, at least until Adeos
> > > eventually silences this code, on demand, to help us.
> > >
> > > Since you have a P4, you do have a local APIC on your chip, so you
> > > should enable it for a uni-processor configuration (CONFIG_X86_UP_APIC),
> > > since it has far better performances latency-wise than the legacy
> > > programmable interrupt controller. You also have a TSC, and the kernel
> > > should use it automatically, provided the P4 CPU is properly selected in
> > > your kernel configuration, as Jan pointed out.
> > > With this configuration, you should not have to care about CONFIG_VT
> > > anymore.
> > >
> > >   
> > Ok I try to sum up the points to see if I understand your explanation right:
> > On an x86 architecture xenomai uses the PIT to emulate a tsc,
> 
> and provide oneshot timing support,
> 
> >  but the
> > PIT is also used by the VT to generate the speaker tone. And if I don't
> > disable CONFIG_VT, or the Linux speaker code, things get messed up.
> > But If I had an pentium architecture where tsc is provided, xenomai can
> > take care of this and directly uses the tsc supported by the pentium 
> > chip, assumed that the kernel
> > is configured to a pentium.
> > Am I right, could you ack this?
> > 
> 
> Ack.

... provided you also enable CONFIG_X86_LOCAL_APIC for solving the
oneshot timing issue.

> 
> > Regards,
> > Steve
> > 
-- 
Philippe.

Re: [Xenomai-help] Timer problems?

[Steve Kreyer]

Philippe Gerum wrote:
> On Sun, 2006-08-27 at 16:22 +0200, Philippe Gerum wrote:
>   
>> On Sun, 2006-08-27 at 15:47 +0200, Steve Kreyer wrote:
>>     
>>> Philippe Gerum wrote:
>>>       
>>>>> Moreover, and that's likely another reason for troubles here, you have
>>>>> CONFIG_VT on. This normally unproblematic features collides with the TSC
>>>>> emulation of Xenomai.
>>>>>     
>>>>>           
>>>> I'll jump on this, since this likely deserves some detailed
>>>> explanations:
>>>>
>>>> The general problem with CONFIG_VT, is the tone generator it uses to
>>>> send bell events to the user, issued by the keyboard management code. On
>>>> x86, the related kernel code fiddles with the legacy programmable
>>>> interrupt timer (PIT) to create an audible tone, specifically this
>>>> chip's channels #0 and #2.
>>>>
>>>> And the problem starts here: when there is no TSC available to the
>>>> kernel, whether because there is none provided by the CPU, or its
>>>> support has been disabled in the kernel configuration (i.e.
>>>> CONFIG_X86_TSC unset), then Xenomai uses the PIT to emulate a kind of
>>>> poor man's TSC, so that it can eventually get a monotonic clock. To this
>>>> end, Xenomai will also use the PIT's channel #2, as a free running
>>>> counter. Hence the conflict with CONFIG_VT.
>>>>
>>>> But there is more: On x86, Xenomai also uses the PIT's channels #0 and
>>>> #1 when undergoing the oneshot timing mode, exclusively for kernel
>>>> configurations which do not provide APIC support (i.e.
>>>> CONFIG_X86_LOCAL_APIC unset, because none of CONFIG_X86_UP_APIC and
>>>> CONFIG_SMP are set). In such a case, the PC speaker management code
>>>> generating the tone will badly conflict with the Xenomai system timer
>>>> too, causing all sorts of erratic behaviours, since both step on each
>>>> other's toes when programming the PIT's channel #0.
>>>>
>>>> With Linux 2.4, the sound generator is reached through a callback
>>>> pointer, so Xenomai just routes the latter to a dummy routine, and we
>>>> are done. With Linux 2.6, the callback has disappeared from the vanilla
>>>> kernel, and sound event requests are sent to the input sub-system for
>>>> processing, where we have currently no hack to void them. This is the
>>>> reason why disabling CONFIG_VT entirely is recommended when there is a
>>>> risk of conflict (which is rather drastic, I agree).
>>>>
>>>> To sum up:
>>>> - The CONFIG_VT issue is in fact a conflict between the regular PC
>>>> speaker code and Xenomai.
>>>> - It is strictly a x86 issue.
>>>> - It is automatically solved by Xenomai over Linux 2.4, and should be
>>>> solved by disabling CONFIG_VT entirely over Linux 2.6 for configurations
>>>> which do not provide APIC or even TSC support, at least until Adeos
>>>> eventually silences this code, on demand, to help us.
>>>>
>>>> Since you have a P4, you do have a local APIC on your chip, so you
>>>> should enable it for a uni-processor configuration (CONFIG_X86_UP_APIC),
>>>> since it has far better performances latency-wise than the legacy
>>>> programmable interrupt controller. You also have a TSC, and the kernel
>>>> should use it automatically, provided the P4 CPU is properly selected in
>>>> your kernel configuration, as Jan pointed out.
>>>> With this configuration, you should not have to care about CONFIG_VT
>>>> anymore.
>>>>
>>>>   
>>>>         
>>> Ok I try to sum up the points to see if I understand your explanation right:
>>> On an x86 architecture xenomai uses the PIT to emulate a tsc,
>>>       
>> and provide oneshot timing support,
>>
>>     
>>>  but the
>>> PIT is also used by the VT to generate the speaker tone. And if I don't
>>> disable CONFIG_VT, or the Linux speaker code, things get messed up.
>>> But If I had an pentium architecture where tsc is provided, xenomai can
>>> take care of this and directly uses the tsc supported by the pentium 
>>> chip, assumed that the kernel
>>> is configured to a pentium.
>>> Am I right, could you ack this?
>>>
>>>       
>> Ack.
>>     
>
> ... provided you also enable CONFIG_X86_LOCAL_APIC for solving the
> oneshot timing issue.
>
>   
>>> Regards,
>>> Steve
>>>
>>>       
Ah ok.

Thanks again for the fine explanation on this issue.

Regards,
Steve

Re: [Xenomai-help] Timer problems?

[Philippe Gerum]

On Sun, 2006-08-27 at 14:24 +0200, Bernhard Walle wrote:
> Hello Philippe,
> 
> * Philippe Gerum <rpm@xenomai.org> [2006-08-27 14:08]:
> > With Linux 2.4, the sound generator is reached through a callback
> > pointer, so Xenomai just routes the latter to a dummy routine, and we
> > are done. With Linux 2.6, the callback has disappeared from the vanilla
> > kernel, and sound event requests are sent to the input sub-system for
> > processing, where we have currently no hack to void them. This is the
> > reason why disabling CONFIG_VT entirely is recommended when there is a
> > risk of conflict (which is rather drastic, I agree).
> 
> Why not patching the kernel at this point? Xenomai requires a kernel
> patch anyway.

This is why I did refer to Adeos as a mean to silence the speaker code,
as a last resort action (we need to keep this layer away from the
kitchen-sink disease). However, switching off CONFIG_PCSPKR would solve
the issue in a much more acceptable way.

> 
> 
> Regards, 
>   Bernhard
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.