On 14.04.22 17:13, Richard Weinberger wrote: > ----- Ursprüngliche Mail ----- >> Von: "Jan Kiszka" <jan.kis...@siemens.com> >>> task5 fails: >>> [9] at task-5.c:79 >>> [1] at task-5.c:23 >>> [10] at task-5.c:87 >>> [3] at task-5.c:40 >>> [11] at task-5.c:95 >>> [4] at task-5.c:45 >>> [5] at task-5.c:50 >>> [6] at task-5.c:55 >>> [2] at task-5.c:28 >>> [7] at task-5.c:60 >>> 0"003.160| BUG in __traceobj_check_abort(): [FGND] wrong return >>> status: >>> task-5.c:63 => EINVAL (want OK) > > > This failure is a little trickier. > > Line 62 is: > ret = rt_task_set_priority(&t_bgnd, info.prio + 1); > ret is EINVAL, that's why the assert in line 63 fails. > It fails because t_bgnd has already terminated. > > This concurs also with the above marker [2]. > [2] is reached when t_bgnd is done. > > The foreground task does: > ret = rt_task_inquire(NULL, &info); > traceobj_assert(&trobj, ret == 0 && info.prio == 21); > > traceobj_mark(&trobj, 6); > > ret = rt_task_set_priority(&t_bgnd, info.prio); > traceobj_check(&trobj, ret, 0); > > traceobj_mark(&trobj, 7); > > ret = rt_task_set_priority(&t_bgnd, info.prio + 1); > traceobj_check(&trobj, ret, 0); > > traceobj_mark(&trobj, 8); > > So it asks for it's own priority, it must be 21, that's okay. > Then it raises the priority of t_bgnd from 20 to 21 > and assumes that no scheduling happens. But this seems to fail. > > Did the nucleus CPU scheduler guarantee that giving another task > the same priority of the calling task will favour the caller? > Now the gifted task seems to win.
Did you configure with --enable-lazy-setsched? If not, set_prio should send the caller to Linux, and that will definitely cause some scheduling change. Jan -- Siemens AG, Technology Competence Center Embedded Linux
