* [Xenomai-help] Re: Re: What happens if task entry function returns?
@ 2006-11-17 12:14 M. Koehrer
2006-11-17 13:58 ` [Xenomai-help] " Jan Kiszka
0 siblings, 1 reply; 9+ messages in thread
From: M. Koehrer @ 2006-11-17 12:14 UTC (permalink / raw)
To: jan.kiszka, mathias_koehrer; +Cc: xenomai
Hi Jan,
I found out, that is issue seems to be related to the NPTL (native posix thread library).
The pthread library in use was
/lib/tls/i686/cmov/libpthread.so.0
which is part of the Debian (testing) package libc6-i686.
(see http://packages.debian.org/testing/libs/libc6-i686)
When renaming the lib/tls to lib/tls.disabled the pthread library in use is
/lib/libpthread.so.0
and then it is working perfectly!
It seems that the i686 optimized libc is not fully compatible with Xenomai.
I read about this library at Romain Lenglet's web page:
http://www.csg.is.titech.ac.jp/~lenglet/howtos/realtimelinuxhowto/index.html
I think this library uses the NPTL (Native Posix Thread Lib).
The i686 optimized library shows the value
NPTL 2.3.6
at
getconf GNU_LIBPTHREAD_VERSION
The "old" pthread lib shows the value:
linuxthreads-0.10
Now, I tried to reconfigure Xenomai with --enable-x86-sep to use
the NPTL but this did not help either.
When I rename now /lib/tls to /lib/tls.disabled, the application complains
about the missing NPTL support in the library.
Well, I have now a solution that works:
I can use the standard pthread lib and not the i686 optimized NPTL.
However, as NPTL seems to be a performance benefit, I think it could be
worth to get this combination up and running.
Is there anybody out there that uses a Debian based system with the i686
optimized libc that works perfectly?
BTW: I am using xenomai 2.2.4 from end of October.
Thanks for any feedback on this
Mathias
> > I am just playing around with Xenomai to understand it.
> > And I have one question concerning the entry function that will be called
> from
> > rt_task_start (Native API).
> > What happens if this entry function reaches its end or a return within the
> function is
> > called?
> >
> > I have made a simple example that lead to strange effects.
> > In my example (see complete C Code in attachement) I create to tasks
> > that do the same.
> > The entry functions look like:
> >
> > void taska(void *cookie)
> > {
> > RTIME delay;
> > int i;
> > printf("Hi, I am task A %s\n", (char*)cookie);
> > delay = 100000;
> >
> > for (i=0; i<200; i++)
> > {
> > rt_task_sleep(delay);
> > }
> >
> > printf("This is the end of A\n");
> > // rt_task_delete(0);
> > }
> > When I do not place the rt_task_delete(0) at the end of the function
> > my second task will never reach the end with the second printf.
> > Whenever I use rt_task_delete(0) at the end of the function it works
> perfectly.
>
> Quite inconsistent, sounds like a bug. Does the second rt_task_join just
> rush through and main terminates?
>
> >
> > My question is now: What happens if the task's entry function returns?
>
> pthread_exit() is invoked implicitly, which implies rt_task_delete(NULL).
>
> >
> > Thanks for any feedback on that question.
>
> Is this issue SMP-related? What happens if you force all your tasks to
> the same CPU? Or if you run on a !CONFIG_SMP box?
>
> Jan
>
--
Mathias Koehrer
mathias_koehrer@domain.hid
Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur 44,85 inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2
^ permalink raw reply [flat|nested] 9+ messages in thread* [Xenomai-help] Re: What happens if task entry function returns?
2006-11-17 12:14 [Xenomai-help] Re: Re: What happens if task entry function returns? M. Koehrer
@ 2006-11-17 13:58 ` Jan Kiszka
2006-11-17 14:17 ` [Xenomai-help] " M. Koehrer
0 siblings, 1 reply; 9+ messages in thread
From: Jan Kiszka @ 2006-11-17 13:58 UTC (permalink / raw)
To: M. Koehrer; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]
M. Koehrer wrote:
> Hi Jan,
>
> I found out, that is issue seems to be related to the NPTL (native posix thread library).
> The pthread library in use was
> /lib/tls/i686/cmov/libpthread.so.0
> which is part of the Debian (testing) package libc6-i686.
> (see http://packages.debian.org/testing/libs/libc6-i686)
>
> When renaming the lib/tls to lib/tls.disabled the pthread library in use is
> /lib/libpthread.so.0
> and then it is working perfectly!
...which does not yet explain WHY the other scenario fails.
>
> It seems that the i686 optimized libc is not fully compatible with Xenomai.
That's not true in such a common form. We are using NTPL libs for i586
and i686 (SuSE builds) without /general/ issues. Still, specific
problems like this may sleep somewhere.
> I read about this library at Romain Lenglet's web page:
> http://www.csg.is.titech.ac.jp/~lenglet/howtos/realtimelinuxhowto/index.html
> I think this library uses the NPTL (Native Posix Thread Lib).
> The i686 optimized library shows the value
> NPTL 2.3.6
> at
> getconf GNU_LIBPTHREAD_VERSION
> The "old" pthread lib shows the value:
> linuxthreads-0.10
>
> Now, I tried to reconfigure Xenomai with --enable-x86-sep to use
> the NPTL but this did not help either.
That only influences the way syscalls are passed down into the kernel.
> When I rename now /lib/tls to /lib/tls.disabled, the application complains
> about the missing NPTL support in the library.
> Well, I have now a solution that works:
> I can use the standard pthread lib and not the i686 optimized NPTL.
> However, as NPTL seems to be a performance benefit, I think it could be
> worth to get this combination up and running.
>
> Is there anybody out there that uses a Debian based system with the i686
> optimized libc that works perfectly?
>
> BTW: I am using xenomai 2.2.4 from end of October.
>
Again my question: is the issue SMP related?
Reproducing your problem over a qemu box (with or without SMP) failed so
far for me. But I'm not on your glibc.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Xenomai-help] Re: Re: What happens if task entry function returns?
2006-11-17 13:58 ` [Xenomai-help] " Jan Kiszka
@ 2006-11-17 14:17 ` M. Koehrer
2006-11-17 15:00 ` Jan Kiszka
2006-11-18 15:52 ` Philippe Gerum
0 siblings, 2 replies; 9+ messages in thread
From: M. Koehrer @ 2006-11-17 14:17 UTC (permalink / raw)
To: jan.kiszka, mathias_koehrer; +Cc: xenomai
Hi Jan,
First, I give you some more information about the error.
The output is the following:
Hi, I am task A Hello
Hi, I am task B World
Main waits for A
This is the end of A
Main waits for B
Then the system hangs.
I have done two tests to verify if there is an SMP issue.
First, I have set all CPUs in use with the application to CPU 0.
There was no change. However, I am able to stop the application with CTRL-C
and everything is cleaned up fine.
Then, I have modified the BIOS settings of the PC to disable Hyperthreading.
Again, no change. The same effect as with the test before.
The strange thing here is, when I use the original test (main on CPU 0, rt tasks on CPU 1)
on a SMP machine, I am not able to terminate the application with CTRL-C.
I have to reboot the PC.
That means, there seems to be a relation to SMP...
Another thing I have detected:
When I modify the program to replace the final rt_task_delete by
a sleep(1) call everything runs perfectly again.
Mathias
> > I found out, that is issue seems to be related to the NPTL (native posix
> thread library).
> > The pthread library in use was
> > /lib/tls/i686/cmov/libpthread.so.0
> > which is part of the Debian (testing) package libc6-i686.
> > (see http://packages.debian.org/testing/libs/libc6-i686)
> >
> > When renaming the lib/tls to lib/tls.disabled the pthread library in use
> is
> > /lib/libpthread.so.0
> > and then it is working perfectly!
>
> ...which does not yet explain WHY the other scenario fails.
>
> >
> > It seems that the i686 optimized libc is not fully compatible with
> Xenomai.
>
> That's not true in such a common form. We are using NTPL libs for i586
> and i686 (SuSE builds) without /general/ issues. Still, specific
> problems like this may sleep somewhere.
>
> > I read about this library at Romain Lenglet's web page:
> >
> http://www.csg.is.titech.ac.jp/~lenglet/howtos/realtimelinuxhowto/index.html
>
> > I think this library uses the NPTL (Native Posix Thread Lib).
> > The i686 optimized library shows the value
> > NPTL 2.3.6
> > at
> > getconf GNU_LIBPTHREAD_VERSION
> > The "old" pthread lib shows the value:
> > linuxthreads-0.10
> >
> > Now, I tried to reconfigure Xenomai with --enable-x86-sep to use
> > the NPTL but this did not help either.
>
> That only influences the way syscalls are passed down into the kernel.
>
> > When I rename now /lib/tls to /lib/tls.disabled, the application
> complains
> > about the missing NPTL support in the library.
> > Well, I have now a solution that works:
> > I can use the standard pthread lib and not the i686 optimized NPTL.
> > However, as NPTL seems to be a performance benefit, I think it could be
> > worth to get this combination up and running.
> >
> > Is there anybody out there that uses a Debian based system with the i686
> > optimized libc that works perfectly?
> >
> > BTW: I am using xenomai 2.2.4 from end of October.
> >
>
> Again my question: is the issue SMP related?
>
> Reproducing your problem over a qemu box (with or without SMP) failed so
> far for me. But I'm not on your glibc.
>
> Jan
--
Mathias Koehrer
mathias_koehrer@domain.hid
Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur 44,85 inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Xenomai-help] Re: Re: What happens if task entry function returns?
2006-11-17 14:17 ` [Xenomai-help] " M. Koehrer
@ 2006-11-17 15:00 ` Jan Kiszka
2006-11-17 15:28 ` M. Koehrer
2006-11-18 15:52 ` Philippe Gerum
1 sibling, 1 reply; 9+ messages in thread
From: Jan Kiszka @ 2006-11-17 15:00 UTC (permalink / raw)
To: M. Koehrer; +Cc: xenomai
M. Koehrer wrote:
> Hi Jan,
>
> First, I give you some more information about the error.
> The output is the following:
> Hi, I am task A Hello
> Hi, I am task B World
> Main waits for A
> This is the end of A
> Main waits for B
>
> Then the system hangs.
You mean completely? Or just that application? Please enable the Xenomai
watchdog to see if we have a run-away RT thread in that case.
>
> I have done two tests to verify if there is an SMP issue.
> First, I have set all CPUs in use with the application to CPU 0.
> There was no change. However, I am able to stop the application with CTRL-C
> and everything is cleaned up fine.
>
> Then, I have modified the BIOS settings of the PC to disable Hyperthreading.
[Which is recommended anyway to keep latencies bounded - HT is evil for RT!]
> Again, no change. The same effect as with the test before.
>
> The strange thing here is, when I use the original test (main on CPU 0, rt tasks on CPU 1)
> on a SMP machine, I am not able to terminate the application with CTRL-C.
> I have to reboot the PC.
>
> That means, there seems to be a relation to SMP...
Probably in so far that the symptom changes. But !SMP doesn't make it go
away.
>
> Another thing I have detected:
> When I modify the program to replace the final rt_task_delete by
> a sleep(1) call everything runs perfectly again.
Ok, could you try on a non-hanging setup to grab what is happening via
strace?
Thanks,
Jan
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Re: [Xenomai-help] Re: Re: What happens if task entry function returns?
2006-11-17 15:00 ` Jan Kiszka
@ 2006-11-17 15:28 ` M. Koehrer
2006-11-17 15:38 ` Jan Kiszka
0 siblings, 1 reply; 9+ messages in thread
From: M. Koehrer @ 2006-11-17 15:28 UTC (permalink / raw)
To: jan.kiszka, mathias_koehrer; +Cc: xenomai
[-- Attachment #1.1: Type: text/plain, Size: 2374 bytes --]
Hi Jan!
I have modified my test to use a sleep(1) at the end of the task functions.
I have enclosed the strace logs to this mail.
The file strace.tls is the one that uses the /lib/tls/... libraries.
The file strace is the one that uses the /lib/... libraries.
I hope that helps...
BTW: I have updated to the latest SVN version of Xenomai (kernel is 2.6.17.7) - the same effect here.
Thanks for the feedback!
Regards
Mathias
> > First, I give you some more information about the error.
> > The output is the following:
> > Hi, I am task A Hello
> > Hi, I am task B World
> > Main waits for A
> > This is the end of A
> > Main waits for B
> >
> > Then the system hangs.
>
> You mean completely? Or just that application? Please enable the Xenomai
> watchdog to see if we have a run-away RT thread in that case.
Only the application hangs!
>
> >
> > I have done two tests to verify if there is an SMP issue.
> > First, I have set all CPUs in use with the application to CPU 0.
> > There was no change. However, I am able to stop the application with
> CTRL-C
> > and everything is cleaned up fine.
> >
> > Then, I have modified the BIOS settings of the PC to disable
> Hyperthreading.
>
> [Which is recommended anyway to keep latencies bounded - HT is evil for
> RT!]
>
> > Again, no change. The same effect as with the test before.
> >
> > The strange thing here is, when I use the original test (main on CPU 0, rt
> tasks on CPU 1)
> > on a SMP machine, I am not able to terminate the application with CTRL-C.
> > I have to reboot the PC.
> >
> > That means, there seems to be a relation to SMP...
>
> Probably in so far that the symptom changes. But !SMP doesn't make it go
> away.
>
> >
> > Another thing I have detected:
> > When I modify the program to replace the final rt_task_delete by
> > a sleep(1) call everything runs perfectly again.
>
> Ok, could you try on a non-hanging setup to grab what is happening via
> strace?
--
Mathias Koehrer
mathias_koehrer@domain.hid
Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur 44,85 inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2
[-- Attachment #2: strace.tgz --]
[-- Type: application/octet-stream, Size: 2102 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Xenomai-help] Re: Re: What happens if task entry function returns?
2006-11-17 14:17 ` [Xenomai-help] " M. Koehrer
2006-11-17 15:00 ` Jan Kiszka
@ 2006-11-18 15:52 ` Philippe Gerum
2006-11-20 7:52 ` Re: [Xenomai-help] Re: Re: What happens if task entry function M. Koehrer
1 sibling, 1 reply; 9+ messages in thread
From: Philippe Gerum @ 2006-11-18 15:52 UTC (permalink / raw)
To: M. Koehrer; +Cc: xenomai, jan.kiszka
On Fri, 2006-11-17 at 15:17 +0100, M. Koehrer wrote:
> Hi Jan,
>
> First, I give you some more information about the error.
> The output is the following:
> Hi, I am task A Hello
> Hi, I am task B World
> Main waits for A
> This is the end of A
> Main waits for B
>
> Then the system hangs.
>
Confirmed here on a two-way PIII. Well, _this_ was a nice one.
Basically, the softlock was due to a missing rescheduling call after
task A has exited, leaving task B in ready state, somewhere in the
Twilight Zone. The patch below fixes it on my setup:
--- ksrc/nucleus/shadow.c (revision 1854)
+++ ksrc/nucleus/shadow.c (working copy)
@@ -1631,7 +1631,8 @@
static inline void do_taskexit_event(struct task_struct *p)
{
- xnthread_t *thread = xnshadow_thread(p); /* p == current */
+ xnthread_t *thread = xnshadow_thread(p); /* p == current */
+ spl_t s;
if (!thread)
return;
@@ -1639,12 +1640,15 @@
if (xnpod_shadow_p())
xnshadow_relax(0);
- /* So that we won't attempt to further wakeup the exiting task in
- xnshadow_unmap(). */
-
+ xnlock_get_irqsave(&nklock, s);
+ /* Prevent wakeup call from xnshadow_unmap(). */
xnshadow_thrptd(p) = NULL;
xnthread_archtcb(thread)->user_task = NULL;
- xnpod_delete_thread(thread); /* Should indirectly call xnshadow_unmap(). */
+ /* xnpod_delete_thread() -> hook -> xnshadow_unmap(). */
+ xnpod_delete_thread(thread);
+ xnsched_set_resched(thread->sched);
+ xnpod_schedule();
+ xnlock_put_irqrestore(&nklock, s);
xnltt_log_event(xeno_ev_shadowexit, thread->name);
}
--
Philippe.
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Re: [Xenomai-help] Re: Re: What happens if task entry function
2006-11-18 15:52 ` Philippe Gerum
@ 2006-11-20 7:52 ` M. Koehrer
0 siblings, 0 replies; 9+ messages in thread
From: M. Koehrer @ 2006-11-20 7:52 UTC (permalink / raw)
To: rpm, mathias_koehrer; +Cc: xenomai, jan.kiszka
Hi Philppe,
thanks for the patch. Using this patch, my test application is working now!
I have also update to the latest SVN version (1882) of Xenomai.
Using this version, the application works perfectly, too.
Regards
Mathias
> > First, I give you some more information about the error.
> > The output is the following:
> > Hi, I am task A Hello
> > Hi, I am task B World
> > Main waits for A
> > This is the end of A
> > Main waits for B
> >
> > Then the system hangs.
> >
>
> Confirmed here on a two-way PIII. Well, _this_ was a nice one.
> Basically, the softlock was due to a missing rescheduling call after
> task A has exited, leaving task B in ready state, somewhere in the
> Twilight Zone. The patch below fixes it on my setup:
>
> --- ksrc/nucleus/shadow.c (revision 1854)
> +++ ksrc/nucleus/shadow.c (working copy)
> @@ -1631,7 +1631,8 @@
>
> static inline void do_taskexit_event(struct task_struct *p)
> {
> - xnthread_t *thread = xnshadow_thread(p); /* p == current */
> + xnthread_t *thread = xnshadow_thread(p); /* p == current */
> + spl_t s;
>
> if (!thread)
> return;
> @@ -1639,12 +1640,15 @@
> if (xnpod_shadow_p())
> xnshadow_relax(0);
>
> - /* So that we won't attempt to further wakeup the exiting task in
> - xnshadow_unmap(). */
> -
> + xnlock_get_irqsave(&nklock, s);
> + /* Prevent wakeup call from xnshadow_unmap(). */
> xnshadow_thrptd(p) = NULL;
> xnthread_archtcb(thread)->user_task = NULL;
> - xnpod_delete_thread(thread); /* Should indirectly call xnshadow_unmap().
> */
> + /* xnpod_delete_thread() -> hook -> xnshadow_unmap(). */
> + xnpod_delete_thread(thread);
> + xnsched_set_resched(thread->sched);
> + xnpod_schedule();
> + xnlock_put_irqrestore(&nklock, s);
>
> xnltt_log_event(xeno_ev_shadowexit, thread->name);
> }
>
> --
> Philippe.
>
>
>
--
Mathias Koehrer
mathias_koehrer@domain.hid
Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur 44,85 inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Xenomai-help] What happens if task entry function returns?
@ 2006-11-17 10:17 M. Koehrer
2006-11-17 10:59 ` [Xenomai-help] " Jan Kiszka
0 siblings, 1 reply; 9+ messages in thread
From: M. Koehrer @ 2006-11-17 10:17 UTC (permalink / raw)
To: xenomai
[-- Attachment #1.1: Type: text/plain, Size: 1450 bytes --]
Hi!
I am just playing around with Xenomai to understand it.
And I have one question concerning the entry function that will be called from
rt_task_start (Native API).
What happens if this entry function reaches its end or a return within the function is
called?
I have made a simple example that lead to strange effects.
In my example (see complete C Code in attachement) I create to tasks
that do the same.
The entry functions look like:
void taska(void *cookie)
{
RTIME delay;
int i;
printf("Hi, I am task A %s\n", (char*)cookie);
delay = 100000;
for (i=0; i<200; i++)
{
rt_task_sleep(delay);
}
printf("This is the end of A\n");
// rt_task_delete(0);
}
When I do not place the rt_task_delete(0) at the end of the function
my second task will never reach the end with the second printf.
Whenever I use rt_task_delete(0) at the end of the function it works perfectly.
My question is now: What happens if the task's entry function returns?
Thanks for any feedback on that question.
Regards
Mathias
--
Mathias Koehrer
mathias_koehrer@domain.hid
Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur 44,85 inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2
[-- Attachment #2: multitasks.c.gz --]
[-- Type: application/postscript, Size: 562 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread* [Xenomai-help] Re: What happens if task entry function returns?
2006-11-17 10:17 [Xenomai-help] What happens if task entry function returns? M. Koehrer
@ 2006-11-17 10:59 ` Jan Kiszka
0 siblings, 0 replies; 9+ messages in thread
From: Jan Kiszka @ 2006-11-17 10:59 UTC (permalink / raw)
To: M. Koehrer; +Cc: Xenomai
M. Koehrer wrote:
> Hi!
>
> I am just playing around with Xenomai to understand it.
> And I have one question concerning the entry function that will be called from
> rt_task_start (Native API).
> What happens if this entry function reaches its end or a return within the function is
> called?
>
> I have made a simple example that lead to strange effects.
> In my example (see complete C Code in attachement) I create to tasks
> that do the same.
> The entry functions look like:
>
> void taska(void *cookie)
> {
> RTIME delay;
> int i;
> printf("Hi, I am task A %s\n", (char*)cookie);
> delay = 100000;
>
> for (i=0; i<200; i++)
> {
> rt_task_sleep(delay);
> }
>
> printf("This is the end of A\n");
> // rt_task_delete(0);
> }
> When I do not place the rt_task_delete(0) at the end of the function
> my second task will never reach the end with the second printf.
> Whenever I use rt_task_delete(0) at the end of the function it works perfectly.
Quite inconsistent, sounds like a bug. Does the second rt_task_join just
rush through and main terminates?
>
> My question is now: What happens if the task's entry function returns?
pthread_exit() is invoked implicitly, which implies rt_task_delete(NULL).
>
> Thanks for any feedback on that question.
Is this issue SMP-related? What happens if you force all your tasks to
the same CPU? Or if you run on a !CONFIG_SMP box?
Jan
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2006-11-20 7:52 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-11-17 12:14 [Xenomai-help] Re: Re: What happens if task entry function returns? M. Koehrer
2006-11-17 13:58 ` [Xenomai-help] " Jan Kiszka
2006-11-17 14:17 ` [Xenomai-help] " M. Koehrer
2006-11-17 15:00 ` Jan Kiszka
2006-11-17 15:28 ` M. Koehrer
2006-11-17 15:38 ` Jan Kiszka
2006-11-18 15:52 ` Philippe Gerum
2006-11-20 7:52 ` Re: [Xenomai-help] Re: Re: What happens if task entry function M. Koehrer
-- strict thread matches above, loose matches on Subject: below --
2006-11-17 10:17 [Xenomai-help] What happens if task entry function returns? M. Koehrer
2006-11-17 10:59 ` [Xenomai-help] " Jan Kiszka
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.