Re: [Dovetail] x86 test version available (kernel v5.10)

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

On 15.02.21 17:53, Jan Kiszka via Xenomai wrote:
> On 15.02.21 16:11, Jan Kiszka via Xenomai wrote:
>> On 15.02.21 14:28, Jan Kiszka wrote:
>>> Now the next issue is
>>>
>>> /usr/lib/xenomai/testsuite/smokey: test sched_quota failed: Protocol error
>>> sched-quota.c:332, out of quota: 13.7%
>>> (on a real target, an Atom-class box).
>>>
>>
>> Testsuite issue, long pending:
>>
>> https://gitlab.denx.de/Xenomai/xenomai/-/blob/master/testsuite/smokey/sched-quota/sched-quota.c#L204
>>
>> Those pthread_kill() in the loop will kick the caller into non-rt, while
>> it is not yet done with collecting the loop counters from the other
>> workers. Result is pure random, sometimes still within the defined
>> limits, but sometimes reporting false overruns.
>>
>> No idea what those signal submissions supposed to do - test runs and
>> terminates fine without them as well.
>>
> 
> Correction: The pthread_kill stay in primary and do not cause the issue
> (they are still not needed IMHO, though).
> 
> It must be something compiler (setting?) related: smokey built with my
> gcc-7 from SUSE is fine, the one build with Debian's gcc-8 is not,
> causing noteworthy variations on the measured workload. Examining further...
> 

It was gcc-10 in fact on my machine - but the actual difference was
--enable-debug=full here vs. no debug in xenomai-images. Without full
debugging, the loop calibration becomes too instable, likely because the
inner __do_work is reduced to a simple

  417960:       48 8d 47 01             lea    0x1(%rdi),%rax
  417964:       c3                      retq

This can be mitigated by extending the calibration loop (crunch_loops =
100000).

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux