[LTP] LTP Release preparations

[Li Wang]

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