[LTP] LTP Release preparations

[Andrea Cervesato]

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.
>
> Afterlooking 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?

- Andrea