Re: [PATCH xenomai-images] ci: do not skip tests on vm that have been relaxed

Tobias Schaffner <[email protected]> writes:

> Hi Philippe,
>
> On 7/7/26 13:21, Jan Kiszka wrote:
>> On 03.07.26 16:00, Tobias Schaffner wrote:
>>>
>>>
>>> On 7/3/26 14:07, Jan Kiszka wrote:
>>>> On 03.07.26 13:54, Tobias Schaffner wrote:
>>>>> Hi all,
>>>>>
>>>>> in some of my test runs the sched-tp-overrun test was failing with:
>>>>> 2026-06-23T17:25:44 ../tests/sched-tp-overrun.c:119: FAILED:
>>>>> evl_read_observable(tfd, &nf, 1) (=Resource temporarily unavailable)
>>>>> 2026-06-23T17:25:44 ** sched-tp-overrun: BROKEN
>>>>>
>>>>> I only see this on virtual targets.
>>>>> e.g.: https://code.siemens.com/ebsy/debian/xenomai-images/-/
>>>>> jobs/393605372
>>>>> Mostly on arm but also saw this on qemu-amd64 in one of my recent runs.
>>>>>
>>>>
>>>> Maybe improper/missing synchronization during test startup? Or when is
>>>> this hit?
>>>
>>>
>>> Does not look like a synchronization problem to me.
>>> The key part of the test failure is this combination:
>>>
>>> /*
>>> * Trigger an overrun condition by staying busy for longer
>>> * than the duration of our allotted time window.
>>> */
>>> for (;;) {
>>>      evl_read_clock(EVL_CLOCK_MONOTONIC, &now);
>>>      if (timespec_sub_ns(&now, &start) > OVERRUN_TIME)
>>>          break;
>>> }
>>>
>>> /*
>>> * Now check whether we received the overrun event as
>>> * expected. Since non-blocking input is enabled, a lack of
>>> * notification would amount to an error (EAGAIN).
>>> */
>>> __Tcall_assert(ret, evl_read_observable(tfd, &nf, 1));
>>>
>>>
>>> The OVERRUN_TIME of 200us seems to be not enough to trigger the overrun
>>> or in some cases or at least the message was not send in time.
>>>
>>> I suspected the issue to be time stealing but saw the fixup parts of the
>>> tp scheduler trying to handle missed time frames. I think we just have
>>> to increase the overrun time but not sure how much to still keep the
>>> fixup parts tested. I guess these code paths are only exercised on
>>> virtual targets.
>>>
>> So, do you want to drop tp-overrun from this patch for now, or how
>> to
>> proceed?
>
>
> @Philippe:
> What is your opinion on this? Do we want to also relax the overrun
> time here?
>

The whole test requires a certain degree of timeliness from the platform
it runs on, typically the TP schedule which is being tested might be off
only because of dramatic slowdowns, which would be considered as
pathological on real hardware although understandable in a vm. So I
would simply disable the test in a virtualized environment, because
relaxing the thresholds would end up making the test pointless.

-- 
Philippe.