Re: kernelci test results

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-09-04 09:44:31 [+0100], Ben Copeland wrote:
> Hi Sebastian,
Hi Ben,

> >  > > On the dashboard, by clicking hardware, Tree=mainline I see only
> >  > > kubernetes as platform. There I see on the bottom various builds. There
> >  > > is a search bar where I can limit to "preempt_rt" and then builds are
> >  > > limited to "preempt_rt" configuration and it also includes "next".
> >  > >
> >  > > There I can click on the build-log (and later I get the build.log.gz)
> >  > > but it appears not to contain the build log of the kernel. I think there
> >  > > is the "config merging" part and kselftest build but not the actual
> >  > > build of the kernel itself.
> 
> By design. We build with tuxmake, which builds silently unless you
> pass --verbose, so a good kernel build emits little more than echoed
> commands. What is left is warnings and errors, and for a failed build
> that log is what logspec parses. The noise you see is the kselftest
> build, which echoes anyway. There is also a reproducer.sh artefact if
> you want to reproduce the build locally.

Ah okay, then.

> >  > >
> >  > > Clicking on tests, I can also filter for preempt_rt but there is only
> >  > > kselftest. I can't see the results, there is always "No logs available".
> 
> Those aren't LAVA test runs, which is why it looks broken. On the
> kubernetes hardware page you are seeing kselftest *build* results
> hanging off the kbuild node, e.g. path
> 
>   kbuild-gcc-14-arm-preempt_rt-kselftest.build.kselftest.rseq
> 
> Those have no log_url, so the viewer says "No logs available", but the
> log is there: look at the output files section of the test page for
> build_kselftest.log.gz and build_kselftest_stderr.log.gz. Not expiry.

Ah okay. So build logs for the tests are there, I see it. But there are
not run anywhere therefore there is not log output. Understood.

> >  > > Later there is the cyclictest invocation, arguments and the result.
> >  > > There is no max-value set for the test so it passes. Would there be a
> >  > > notification if the test failed and if so, where?
> 
> I cannot find any thresholds set, which isn't ideal.
> parse_rt_tests_results.py prints the literal string "pass" for every
> latency line; only cyclictest's return code decides the overall
> result. So a max-value parameter on our side would change nothing
> until the parser learns about thresholds.

Okay. I have two pulls open to the priority thingy. Let me then look
into this.

> >  > > I noticed that on the lava page, by clicking on the device I can search
> >  > > for "rt-tests-cyclictest" and get the recent results for this device for
> >  > > this test. Is something like this possible on the dashboard? I.e. look
> >  > > for the recent cyclictest results?
> 
> Alan already covered this; however, after a quick dive into some of
> the rt results, I noticed jobs dying with "Unsupported url protocol
> scheme". Seems to be an issue with rt-tests + nfs boot. I will have to
> dig deeper, but there is some improvement to be had here. I also
> noticed that we are missing trixie-rt armhf rootfs, which will be a
> problem for imx6q-sabrelite (and other armhf boards about running rt).
> 
> So bcm2711-rpi-4-b, where you ended up, is one of the few places
> rt-tests actually produces data. I'd need to dig further to see where
> else it is running or failing.

Okay, thanks.

> Thanks
> 
> Ben

Sebastian