All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xenomai-help] Program hangs using "rt_task_sleep" in a particular way
@ 2011-06-27  6:31 Adrien LEMAITRE
  2011-06-27 10:53 ` Gilles Chanteperdrix
  0 siblings, 1 reply; 9+ messages in thread
From: Adrien LEMAITRE @ 2011-06-27  6:31 UTC (permalink / raw)
  To: xenomai


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

Hello,

I raise a problem encountered and always present. Before on this configuration
:

- linux kernel : 2.6.29.6
- adeos patch : adeos-ipipe-2.6.29-arm-1.13-00.patch
- xenomai : 2.4.8
- host linux distribution : ubuntu 10.04 (64 bits)
- compiler : gcc 4.2.1 (buildroot's generated toolchain)

And it is always present with this configuration :

- Linux kernel : 2.6.37
- Adeos patch : adeos-ipipe-2.6.37-x86-2.9-00.patch
- Xenomai : 2.5.6
- Host Linux distribution : Ubuntu 10.04
- Compiler : gcc-4.4.3

Configuration of kernel:

I used the default configuration of Ubunut 10.04 and i change this:
In "Power management and ACPI options" :
- deactivate APM
- deactivate CPU frequency scaling
- deactivate ACPI
- deactivate CPU idle PM support
In "Device drivers/Input device support/Miscelaneous devices":
- deactivate PC Speaker support
In "Processor type and features":
- deactivate HPET_TIMER
- deactivate Enable -fstack-protector buffer overflow detection
(EXPERIMENTAL)


We encounter a problem in a particular situation. In the attached
source, when we change the value passed to rt_task_sleep (line 36), the
program never returns.

This appears only with values greater or equal to 100000 (and maybe some
other values between 10000 and 100000) and only when we use
rt_task_sleep between the two rt_task_spawn calls.

Is there something we've done wrong ? A problem with the kernel
configuration? Or a bug of Xenomai ?


Adrien Lemaître.

[-- Attachment #1.2: Type: text/html, Size: 5803 bytes --]

[-- Attachment #2: projet_vierge.c --]
[-- Type: text/x-csrc, Size: 1102 bytes --]

#include "utils.h"
#include <assert.h>
#include <stdio.h>
#include <native/task.h>
#include <native/queue.h>
#include <sys/mman.h>

int Counter1=0;
int Counter2=0;
volatile int test1=0;
volatile int test2=0;

void WorkingTask1()
{
	while(test1==0)
	{
		Counter1++;
	}
}

void WorkingTask2()
{ 
	while(test2==0)
	{
		Counter2++;
	}
}

void go ()
{
	RT_TASK Rt_Working_task1;
	RT_TASK Rt_Working_task2;

	rt_task_spawn (&Rt_Working_task1, "WorkingTask1", DEFAULT_STACK_SIZE,10, T_FPU|T_JOINABLE, &WorkingTask1, NULL);
  
  rt_task_sleep(100000); // does not work
  //rt_task_sleep(10000);  // works

	rt_task_spawn (&Rt_Working_task2, "WorkingTask2", DEFAULT_STACK_SIZE, 20, T_FPU|T_JOINABLE, &WorkingTask2, NULL);

	test1=1;
	test2=1;
}

int main (void)
{
  RT_TASK Rt_main_task;
  int error;

  error = mlockall( MCL_CURRENT | MCL_FUTURE );
  assert (error == 0);

  error = rt_task_spawn (&Rt_main_task, "go", DEFAULT_STACK_SIZE, 50, T_FPU | T_JOINABLE, &go, NULL);
  assert (error == 0);

  error = rt_task_join(&Rt_main_task);
  assert (error == 0);
  
  printf("End program\r\n");
  
  return 0;
}

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Xenomai-help] Program hangs using "rt_task_sleep" in a particular way
  2011-06-27  6:31 [Xenomai-help] Program hangs using "rt_task_sleep" in a particular way Adrien LEMAITRE
@ 2011-06-27 10:53 ` Gilles Chanteperdrix
       [not found]   ` <BANLkTimCab2u0EOrJ6JtLTVLNAzktbvFQg@domain.hid>
  0 siblings, 1 reply; 9+ messages in thread
From: Gilles Chanteperdrix @ 2011-06-27 10:53 UTC (permalink / raw)
  To: Adrien LEMAITRE; +Cc: xenomai

On 06/27/2011 08:31 AM, Adrien LEMAITRE wrote:
> Hello,
> 
> I raise a problem encountered and always present. Before on this configuration
> :
> 
> - linux kernel : 2.6.29.6
> - adeos patch : adeos-ipipe-2.6.29-arm-1.13-00.patch
> - xenomai : 2.4.8
> - host linux distribution : ubuntu 10.04 (64 bits)
> - compiler : gcc 4.2.1 (buildroot's generated toolchain)
> 
> And it is always present with this configuration :
> 
> - Linux kernel : 2.6.37
> - Adeos patch : adeos-ipipe-2.6.37-x86-2.9-00.patch
> - Xenomai : 2.5.6
> - Host Linux distribution : Ubuntu 10.04
> - Compiler : gcc-4.4.3
> 
> Configuration of kernel:
> 
> I used the default configuration of Ubunut 10.04 and i change this:
> In "Power management and ACPI options" :
> - deactivate ACPI

This is a bad idea. Only ACPI_PROCESSOR is problematic. See:
http://www.xenomai.org/index.php/Configuring_x86_kernels

> - deactivate CPU idle PM support
> In "Device drivers/Input device support/Miscelaneous devices":
> - deactivate PC Speaker support
> In "Processor type and features":

You should only need this if you have mis-configured your kernel. Again,
see the "Processor type" paragraph in the Configuring_x86_kernels page.

> - deactivate HPET_TIMER
> - deactivate Enable -fstack-protector buffer overflow detection
> (EXPERIMENTAL)
> 
> 
> We encounter a problem in a particular situation. In the attached
> source, when we change the value passed to rt_task_sleep (line 36), the
> program never returns.
> 
> This appears only with values greater or equal to 100000 (and maybe some
> other values between 10000 and 100000) and only when we use
> rt_task_sleep between the two rt_task_spawn calls.
> 
> Is there something we've done wrong ? A problem with the kernel
> configuration? Or a bug of Xenomai ?

The real-time task are using 100% cpu time. You can not do that. A
real-time task should suspend from time to time and let non real-time
activities run.

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Xenomai-help] Program hangs using "rt_task_sleep" in a particular way
       [not found]   ` <BANLkTimCab2u0EOrJ6JtLTVLNAzktbvFQg@domain.hid>
@ 2011-06-28 13:08     ` Gilles Chanteperdrix
  2011-06-28 14:02       ` Adrien LEMAITRE
  0 siblings, 1 reply; 9+ messages in thread
From: Gilles Chanteperdrix @ 2011-06-28 13:08 UTC (permalink / raw)
  To: Adrien LEMAITRE; +Cc: Xenomai help

On 06/28/2011 02:20 PM, Adrien LEMAITRE wrote:
> 2011/6/27 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> 
>> On 06/27/2011 08:31 AM, Adrien LEMAITRE wrote:
>>> Hello,
>>>
>>> I raise a problem encountered and always present. Before on this
>> configuration
>>> :
>>>
>>> - linux kernel : 2.6.29.6
>>> - adeos patch : adeos-ipipe-2.6.29-arm-1.13-00.patch
>>> - xenomai : 2.4.8
>>> - host linux distribution : ubuntu 10.04 (64 bits)
>>> - compiler : gcc 4.2.1 (buildroot's generated toolchain)
>>>
>>> And it is always present with this configuration :
>>>
>>> - Linux kernel : 2.6.37
>>> - Adeos patch : adeos-ipipe-2.6.37-x86-2.9-00.patch
>>> - Xenomai : 2.5.6
>>> - Host Linux distribution : Ubuntu 10.04
>>> - Compiler : gcc-4.4.3
>>>
>>> Configuration of kernel:
>>>
>>> I used the default configuration of Ubunut 10.04 and i change this:
>>> In "Power management and ACPI options" :
>>> - deactivate ACPI
>>
>> This is a bad idea. Only ACPI_PROCESSOR is problematic. See:
>> http://www.xenomai.org/index.php/Configuring_x86_kernels
>>
>>> - deactivate CPU idle PM support
>>> In "Device drivers/Input device support/Miscelaneous devices":
>>> - deactivate PC Speaker support
>>> In "Processor type and features":
>>
>> You should only need this if you have mis-configured your kernel. Again,
>> see the "Processor type" paragraph in the Configuring_x86_kernels page.
>>
> 
> I applied these changes. In fact, i used the default configuration kernel
> and i changed only the processor family. But I must desactivate  "Enable
> -fstack-protector buffer overflow detection (EXPERIMENTAL)" otherwise i have
> an error during the compilation.
> But the problem is still here.
> 
> 
>>  > - deactivate HPET_TIMER
>>> - deactivate Enable -fstack-protector buffer overflow detection
>>> (EXPERIMENTAL)
>>>
>>>
>>> We encounter a problem in a particular situation. In the attached
>>> source, when we change the value passed to rt_task_sleep (line 36), the
>>> program never returns.
>>>
>>> This appears only with values greater or equal to 100000 (and maybe some
>>> other values between 10000 and 100000) and only when we use
>>> rt_task_sleep between the two rt_task_spawn calls.
>>>
>>> Is there something we've done wrong ? A problem with the kernel
>>> configuration? Or a bug of Xenomai ?
>>
>> The real-time task are using 100% cpu time. You can not do that. A
>> real-time task should suspend from time to time and let non real-time
>> activities run.
>>
> 
> I am supprised by this answer, we are supposed to think that real-time tasks
> are before others tasks. And we made attention at used only functions in
> real-time. And why this problem is only when value of rt_task_sleep is
> greater or equal to 100000? the master tasker was supposed to take his turn
> after, didn't it? And I don't understand why in a case no problems and in  a
> other case the program never finishes.
> 
> Is it a problem with preemption of kernel?

The problem is that the "rt_task_spawn" service causes its caller to
switch to secondary mode. This means, that the task is no longer real-time.
If you do not have root priority coupling enabled, this means that the
thread just created will have priority as long as it does not suspend.

Normally, root thread priority coupling should allow to avoid that.
Unfortunately, there is a small hole in this functionality which make it
not work in some conditions (and fixing this hole would introduce a
possibility of priority inversion).

As for the influence of the length of the call to rt_task_sleep, a short
rt_task_sleep will cause the "go" task to switch to primary mode and
preempt the task "WorkingTask1" before it is completely started.

Nevertheless, now that I give you the probable explanation, I have some
doubts and will run your test case to confirm this explanation.

Nevertheless(2), xenomai needs linux to run in order to work correctly,
so, the real-time tasks should always suspend to let linux run. I bet if
you put an rt_task_sleep in WorkingTask1 and WorkingTask2 loop, the test
will no longer hang.

Please no private mails.

-- 
					    Gilles.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Xenomai-help] Program hangs using "rt_task_sleep" in a particular way
  2011-06-28 13:08     ` Gilles Chanteperdrix
@ 2011-06-28 14:02       ` Adrien LEMAITRE
  2011-06-28 15:08         ` Gilles Chanteperdrix
  0 siblings, 1 reply; 9+ messages in thread
From: Adrien LEMAITRE @ 2011-06-28 14:02 UTC (permalink / raw)
  To: xenomai

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

Hi,

Thanks for your answer.

2011/6/28 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>

> The problem is that the "rt_task_spawn" service causes its caller to
> switch to secondary mode. This means, that the task is no longer real-time.
>

I wasn't aware of this fact. It could be annoying if we have to create
several RT Tasks...
It's only true for rt_task_spawn or for all Xenomai services ?

A better practice will to first make several rt_task_create and after
activate them by rt_task_start services?



> Normally, root thread priority coupling should allow to avoid that.
> Unfortunately, there is a small hole in this functionality which make it
> not work in some conditions (and fixing this hole would introduce a
> possibility of priority inversion).
>
My advisor (jerome Delatour from ESEO) want to better understand this point,
where could I find explanations on this point ?


> As for the influence of the length of the call to rt_task_sleep, a short
> rt_task_sleep will cause the "go" task to switch to primary mode and
> preempt the task "WorkingTask1" before it is completely started.
>

OK, I will also make some test around this.


> Nevertheless(2), xenomai needs linux to run in order to work correctly,
> so, the real-time tasks should always suspend to let linux run. I bet if
> you put an rt_task_sleep in WorkingTask1 and WorkingTask2 loop, the test
> will no longer hang.
>
Yes, even a rt_task-sleep(0) or rt_task_sleep(1) works, but I thought
because in that case we force a call to the Xenomai scheduler


>
> Please no private mails.
>
I apologize, my gmail didn't work as expected.


Adrien, Engineering student at ESEO

[-- Attachment #2: Type: text/html, Size: 2691 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Xenomai-help] Program hangs using "rt_task_sleep" in a particular way
  2011-06-28 14:02       ` Adrien LEMAITRE
@ 2011-06-28 15:08         ` Gilles Chanteperdrix
  0 siblings, 0 replies; 9+ messages in thread
From: Gilles Chanteperdrix @ 2011-06-28 15:08 UTC (permalink / raw)
  To: Adrien LEMAITRE; +Cc: xenomai

On 06/28/2011 04:02 PM, Adrien LEMAITRE wrote:
> Hi,
> 
> Thanks for your answer.
> 
> 2011/6/28 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> 
>> The problem is that the "rt_task_spawn" service causes its caller to
>> switch to secondary mode. This means, that the task is no longer real-time.
>>
> 
> I wasn't aware of this fact. It could be annoying if we have to create
> several RT Tasks...
> It's only true for rt_task_spawn or for all Xenomai services ?

Which services stay in primary mode, and which services switch to
secondary mode is documented in the API documentation:
http://www.xenomai.org/documentation/xenomai-2.5/html/api/index.html

> 
> A better practice will to first make several rt_task_create and after
> activate them by rt_task_start services?

Probably. But if these tasks use 100% cpu and never let linux run, you
will have other problems later (the first being that the system will no
longer respond to non real-time activities such as the consoles, the
graphic system, etc...).

> 
> 
> 
>> Normally, root thread priority coupling should allow to avoid that.
>> Unfortunately, there is a small hole in this functionality which make it
>> not work in some conditions (and fixing this hole would introduce a
>> possibility of priority inversion).
>>
> My advisor (jerome Delatour from ESEO) want to better understand this point,
> where could I find explanations on this point ?

This is a point discovered recently, see the thread starting here:
https://mail.gna.org/public/xenomai-help/2011-03/msg00165.html

-- 
					    Gilles.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Xenomai-help] Program hangs using "rt_task_sleep" in a particular way
       [not found]   ` <AANLkTinnCqCNrJ-tukjxGd-zdtM9nuG2fw4Zer+iTSiQ@mail.gmail.com>
@ 2011-03-07 14:33     ` Gilles Chanteperdrix
  0 siblings, 0 replies; 9+ messages in thread
From: Gilles Chanteperdrix @ 2011-03-07 14:33 UTC (permalink / raw)
  To: Jonathan ILIAS-PILLET; +Cc: Xenomai help

Jonathan ILIAS-PILLET wrote:
> 2011/3/7 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
>> We do not know anything about your setup (except the platform). See:
>> http://www.xenomai.org/index.php/Request_for_information
> 
> Oh, sorry. Here it is :
> - linux kernel : 2.6.29.6
> - adeos patch : adeos-ipipe-2.6.29-arm-1.13-00.patch
> - xenomai : 2.4.8
> - host linux distribution : ubuntu 10.04 (64 bits)
> - compiler : gcc 4.2.1 (buildroot's generated toolchain)
> 
> For those who knows it, all of this comes from Armadeus distribution
> (vendor package for the board we use) in version 3.3 which is based on
> buildroot (see http://www.armadeus.com/wiki/).

This is very old stuff. Could you try whether you reproduce this issue
with Xenomai latest release (2.5.5.2) ? Also, using 2.4.8 is
preposterous, you should at least upgrade to the latest release from the
same branch, it should be 2.4.9.1.

> 
>> It would also be interesting to know if you have root thread priority
>> coupling enabled.
> 
> Actually, I've never choose any option about this, I thought it was
> activated by default. Perhaps I messed the kernel configuration
> related to this, where this feature can be enabled or disabled ?
> 
> According to http://www.xenomai.org/index.php/Proc/xenomai/sched, I
> guess it is enabled :
> # cat /proc/xenomai/sched
> CPU  PID    PRI      PERIOD     TIMEOUT    TIMEBASE  STAT       NAME
>   0  0       -1      0          0          master    R          ROOT

No, you do not see anything here. You have to check the kernel
configuration.

Relying on someone else's configuration will not fly for long, you have
to know what is in the kernel you compile.

> 
> 
>> In any case, your real-time tasks should never use all the cpu without
>> letting Linux run. The only way to guarantee the stability of the system
>> is by letting Linux run from time to time.
> 
> OK, I understand. Linux kernel is time dependant (at least for the
> scheduler). But is there a specific reason for this or is it a general
> precaution ?
> 
> When you say "time to time", is there any rule to follow to be sure
> that enough time is given to Linux ? Something like CPU cannot spend
> more than 500 ms in one second for primary mode threads ?

No. Something like your application should release the cpu once every
10ms so that Linux receives its ticks when it expects them (so, every
1ms if running at 1000 Hz). In fact, a typical application is blocked
most of the time and only reacts to events (be it the timer interrupt).

-- 
					    Gilles.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Xenomai-help] Program hangs using "rt_task_sleep" in a particular way
  2011-03-07 10:15 ` Gilles Chanteperdrix
@ 2011-03-07 14:29   ` Jonathan ILIAS-PILLET
       [not found]   ` <AANLkTinnCqCNrJ-tukjxGd-zdtM9nuG2fw4Zer+iTSiQ@mail.gmail.com>
  1 sibling, 0 replies; 9+ messages in thread
From: Jonathan ILIAS-PILLET @ 2011-03-07 14:29 UTC (permalink / raw)
  To: xenomai

2011/3/7 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> We do not know anything about your setup (except the platform). See:
> http://www.xenomai.org/index.php/Request_for_information

Oh, sorry. Here it is :
- linux kernel : 2.6.29.6
- adeos patch : adeos-ipipe-2.6.29-arm-1.13-00.patch
- xenomai : 2.4.8
- host linux distribution : ubuntu 10.04 (64 bits)
- compiler : gcc 4.2.1 (buildroot's generated toolchain)

For those who knows it, all of this comes from Armadeus distribution
(vendor package for the board we use) in version 3.3 which is based on
buildroot (see http://www.armadeus.com/wiki/).

> It would also be interesting to know if you have root thread priority
> coupling enabled.

Actually, I've never choose any option about this, I thought it was
activated by default. Perhaps I messed the kernel configuration
related to this, where this feature can be enabled or disabled ?

According to http://www.xenomai.org/index.php/Proc/xenomai/sched, I
guess it is enabled :
# cat /proc/xenomai/sched
CPU  PID    PRI      PERIOD     TIMEOUT    TIMEBASE  STAT       NAME
 0  0       -1      0          0          master    R          ROOT


> In any case, your real-time tasks should never use all the cpu without
> letting Linux run. The only way to guarantee the stability of the system
> is by letting Linux run from time to time.

OK, I understand. Linux kernel is time dependant (at least for the
scheduler). But is there a specific reason for this or is it a general
precaution ?

When you say "time to time", is there any rule to follow to be sure
that enough time is given to Linux ? Something like CPU cannot spend
more than 500 ms in one second for primary mode threads ?

Thanks
-- 
Jonathan ILIAS-PILLET


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Xenomai-help] Program hangs using "rt_task_sleep" in a particular way
  2011-03-07  9:18 Jonathan ILIAS-PILLET
@ 2011-03-07 10:15 ` Gilles Chanteperdrix
  2011-03-07 14:29   ` Jonathan ILIAS-PILLET
       [not found]   ` <AANLkTinnCqCNrJ-tukjxGd-zdtM9nuG2fw4Zer+iTSiQ@mail.gmail.com>
  0 siblings, 2 replies; 9+ messages in thread
From: Gilles Chanteperdrix @ 2011-03-07 10:15 UTC (permalink / raw)
  To: Jonathan ILIAS-PILLET; +Cc: armadeus-forum, xenomai

Jonathan ILIAS-PILLET wrote:
> Hello,
> 
> We encounter a problem in a particular situation. In the attached
> source, when we change the value passed to rt_task_sleep (line 35), the
> program never returns.
> 
> This appears only with values greater or equal to 100000 (and maybe some
> other values between 10000 and 100000) and only when we use
> rt_task_sleep between the two rt_task_spawn calls.
> 
> Is there something we've done wrong ?
> 
> We use and Armadeus APF27 platform. I don't know if this behavior is
> related to this architecture, to Xenomai or both.

We do not know anything about your setup (except the platform). See:
http://www.xenomai.org/index.php/Request_for_information

It would also be interesting to know if you have root thread priority
coupling enabled.

In any case, your real-time tasks should never use all the cpu without
letting Linux run. The only way to guarantee the stability of the system
is by letting Linux run from time to time.

-- 
					    Gilles.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Xenomai-help] Program hangs using "rt_task_sleep" in a particular way
@ 2011-03-07  9:18 Jonathan ILIAS-PILLET
  2011-03-07 10:15 ` Gilles Chanteperdrix
  0 siblings, 1 reply; 9+ messages in thread
From: Jonathan ILIAS-PILLET @ 2011-03-07  9:18 UTC (permalink / raw)
  To: xenomai; +Cc: armadeus-forum

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

Hello,

We encounter a problem in a particular situation. In the attached
source, when we change the value passed to rt_task_sleep (line 35), the
program never returns.

This appears only with values greater or equal to 100000 (and maybe some
other values between 10000 and 100000) and only when we use
rt_task_sleep between the two rt_task_spawn calls.

Is there something we've done wrong ?

We use and Armadeus APF27 platform. I don't know if this behavior is
related to this architecture, to Xenomai or both.

-- 
Jonathan ILIAS-PILLET

[-- Attachment #2: projet_vierge.c --]
[-- Type: text/x-csrc, Size: 1084 bytes --]

#include "utils.h"
#include <assert.h>
#include <stdio.h>
#include <native/task.h>
 
int Compteur1=0;
int Compteur2=0;
volatile int test1=0;
volatile int test2=0;

void WorkingTask1()
{
	while(test1==0)
	{
		Compteur1++;
	}
}

void WorkingTask2()
{ 
	while(test2==0)
	{
		Compteur2++;
	}
}

void go ()
{
	int erreur;
	RT_TASK Rt_Working_task1;
	RT_TASK Rt_Working_task2;

	rt_task_spawn (&Rt_Working_task1, "WorkingTask1", DEFAULT_STACK_SIZE,10, T_FPU|T_JOINABLE, &WorkingTask1, NULL);
  
  rt_task_sleep(100000); // does not work
  //rt_task_sleep(10000);  // works

	rt_task_spawn (&Rt_Working_task2, "WorkingTask2", DEFAULT_STACK_SIZE, 20, T_FPU|T_JOINABLE, &WorkingTask2, NULL);

	test1=1;
	test2=1;
}

int main (void)
{
  RT_TASK Rt_main_task;
  int erreur;

  erreur = mlockall( MCL_CURRENT | MCL_FUTURE );
  assert (erreur == 0);

  erreur = rt_task_spawn (&Rt_main_task, "go", DEFAULT_STACK_SIZE, 50, T_FPU | T_JOINABLE, &go, NULL);
  assert (erreur == 0);

  erreur = rt_task_join(&Rt_main_task);
  assert (erreur == 0);
  
  printf("Fin du programme\r\n");
  
  return 0;
}

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2011-06-28 15:08 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-27  6:31 [Xenomai-help] Program hangs using "rt_task_sleep" in a particular way Adrien LEMAITRE
2011-06-27 10:53 ` Gilles Chanteperdrix
     [not found]   ` <BANLkTimCab2u0EOrJ6JtLTVLNAzktbvFQg@domain.hid>
2011-06-28 13:08     ` Gilles Chanteperdrix
2011-06-28 14:02       ` Adrien LEMAITRE
2011-06-28 15:08         ` Gilles Chanteperdrix
  -- strict thread matches above, loose matches on Subject: below --
2011-03-07  9:18 Jonathan ILIAS-PILLET
2011-03-07 10:15 ` Gilles Chanteperdrix
2011-03-07 14:29   ` Jonathan ILIAS-PILLET
     [not found]   ` <AANLkTinnCqCNrJ-tukjxGd-zdtM9nuG2fw4Zer+iTSiQ@mail.gmail.com>
2011-03-07 14:33     ` Gilles Chanteperdrix

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.