Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> unfortunately I'm forced to switch to other bugs, but I found out a bit
>> more about the issue that pthread_getschedparam doesn't return the
>> correct policy&prio under trunk - at least when called from threads
>> created via pthread_create as SCHED_FIFO:
>> Such threads start with SCHED_OTHER, but then the propagation via
>> do_setsched_event and finally xnsched_set_policy only seems to affect
>> thread.cprio, not bprio. Will see if I can continue debugging this
>> later, but maybe /someone/ already knows what goes wrong...
> Yes, pthread_getschedparam returns the priority in the glibc cache. And
__wrap_pthread_getschedparam calls into the kernel.
> this one may not be in sync with the priority known by the kernel(s).
> However, this is supposed to be fixed by calling
> __real_pthread_setschedparam in various key places.
This is already called - on thread creation. I'm not debugging
prio/policy adjustment during thread lifetime, already the initial
values passed to pthread_create are not properly reflected by
pthread_getschedparam because bprio is wrong (BTW, /proc/xenomai/sched
should probably better return both cprio and bprio, not just cprio).
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
Xenomai-core mailing list