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 [EMAIL PROTECTED] 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 _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
