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
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
