Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Hi, >> >> 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). Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux _______________________________________________ Xenomai-core mailing list [email protected] https://mail.gna.org/listinfo/xenomai-core
