Re: [PATCH v2 0/9] Revive alchemy, pSOS and VxWorks tests

[Jan Kiszka <jan.kiszka@siemens.com>]

On 14.04.22 17:13, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Jan Kiszka" <jan.kiszka@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