Gilles Chanteperdrix wrote: > Jan Kiszka wrote: > > ... > > I found this while trying Thomas Gleixner's cyclic test over the POSIX > > skin (http://www.tglx.de/projects/misc/cyclictest). After fixing a > > rather ugly bug in his code (missing mlockall) I ran into a yet unknown > > issue with the POSIX skin: the code just hangs when wrapped to Xenomai. > > > > Compilation: > > gcc -o cyclictest cyclictest.c <posix-cflags> <posix-ldflags> > > > > Invocation: > > cyclictest -n -p 99 > > > > Maybe its just real-time starvation (but the watchdog doesn't trigger, > > and I do not see why it should starve), maybe its a crash (will try to > > attach a serial console later). Anyway, it's an easy test case (and also > > a nice tool), so you may want to have a look as well. > > A second, better guess: the created thread is not a Xenomai realtime > thread, so never suspends (Xenomai calls return EPERM when not called > from a real-time thread) and hangs. Replacing sched_setscheduler with > pthread_setschedparam should solve this issue.
Haven't tried this yet, but I'm quite sure that this is the reason. Then this must have been a classic Linux SCHED_FIFO lock-up. > > I would not be surprised if, with NPTL, sched_setscheduler had an effect > on the whole process, i.e. set the priority of all the threads in the > process. > From reading the POSIX spec, I would say the calling sched_setscheduler multiple times in individual threads indicates a wrong usage, doesn't it? And what NPTL does with it, specifically in the presence of multiple threads, is a good questions... Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list [email protected] https://mail.gna.org/listinfo/xenomai-core
