[LTP] LTP Release preparations

[Li Wang]

On Thu, Sep 4, 2025 at 1:42 PM Andrea Cervesato <andrea.cervesato@suse.com>
wrote:

> Hi Li,
> On 9/4/25 5:06 AM, Li Wang wrote:
>
>
>
> On Thu, Sep 4, 2025 at 10:39 AM Li Wang <liwang@redhat.com> wrote:
>
>> Hi Cyril, Andrea,
>>
>> On Wed, Sep 3, 2025 at 9:20 PM Cyril Hrubis <chrubis@suse.cz> wrote:
>>
>>> Hi!
>>> > > After an analysis we are now sure that it's not a product bug but a
>>> test
>>> > > issue. There might be a need to fallback the patch if we can't fix
>>> the
>>> > > test before release. @Li WDYT?
>>
>> >
>>> > Try this:
>>> >
>>> > diff --git a/testcases/realtime/func/sched_football/sched_football.c
>>> b/testcases/realtime/func/sched_football/sched_football.c
>>> > index 0617bdb87..0d64210b0 100644
>>> > --- a/testcases/realtime/func/sched_football/sched_football.c
>>> > +++ b/testcases/realtime/func/sched_football/sched_football.c
>>> > @@ -115,8 +115,8 @@ void referee(int game_length)
>>> >         now = start;
>>> >
>>> >         /* Start the game! */
>>> > -       tst_atomic_store(0, &the_ball);
>>> >         pthread_barrier_wait(&start_barrier);
>>> > +       tst_atomic_store(0, &the_ball);
>>> >         atrace_marker_write("sched_football", "Game_started!");
>>> >
>>> >
>>> > We have to be sure that the defense has started before we clear the
>>> > ball. Previously we had the loop that waited for the players to be
>>> ready
>>> > before we called referee() function so all the players were ready when
>>> > we cleared it.
>>>
>>> Uff and we have to get the final ball position before we stop the
>>> threads as well, otherwise there is always chance, that we may end up
>>> moving the ball right after the high priority defence threads has been
>>> stopped:
>>>
>>
>> This makes sense! However, from my extensive testing, I still see
>> occasional fails on KVM/Debug platforms.
>>
>> I suspect the existing barriers ensure all threads are created before
>> the game starts, but small scheduler skews can still allow the attacking
>> thread to run for a few cycles before the defending thread migrates,
>> especially on debug/RT kernels.
>>
>
> Sorry typo, RT --> non-RT kernels.
>
> Since regular kernels use the CFS scheduler, which is more likely to
> have such deviations, I thought it would be better to run this test using
> the RT kernel.
>
> After looking your test job, it appears that 6.16.3-1-default is a stock
> kernel,
> so I'm not surprised by the failure.
>
> --
> Regards,
> Li Wang
>
> I see, are you planning to send a patch to fix the test?
>

Yes, I will send a strengthened patch based on Cyril's method.

-- 
Regards,
Li Wang