From: Denys Fedoryshchenko <denys.f@collabora.com>
To: "Alan Zanoni Peixinho" <alan.peixinho@profusion.mobi>
Cc: "Sebastian Andrzej Siewior" <bigeasy@linutronix.de>,
"kernelci" <kernelci@lists.linux.dev>,
"kernelci-webdashboard" <kernelci-webdashboard@groups.io>,
"John Ogness" <john.ogness@linutronix.de>
Subject: Re: kernelci test results
Date: Fri, 04 Sep 2026 08:15:12 +0300 [thread overview]
Message-ID: <1a06ad7a5bf.36f8f8422502097.1545856430736765843@collabora.com> (raw)
In-Reply-To: <CAKKBm2t3EoD4cRiBJzLqpE79ehRs+Xs-Ypb5ta3Y7rC=0jjyKA@mail.gmail.com>
Hi Sebastian, Alan
The system currently creates a short log extract only when a build or boot test is marked as failed. This job completed successfully, including the boot and cyclictest, so the log was stored but not automatically analyzed for an extract.
The kernel warning is present in the full log and our analyzer can recognize it, but it was missed because the overall job passed. This is a limitation in the current reporting flow.
We initially chose to create log extracts only for failed builds or boot tests because successful boots often contain harmless or known warnings, such as spurious IRQ messages. Reporting every warning as an issue could create substantial noise that kernel developers may not find actionable.
We could review this policy and maintain an ignore list for known, non-actionable messages. That would let us highlight new or unexpected warnings without creating unnecessary noise for kernel developers.
From: Alan Zanoni Peixinho <alan.peixinho@profusion.mobi>
To: "Sebastian Andrzej Siewior"<bigeasy@linutronix.de>
Cc: <kernelci@lists.linux.dev>, <kernelci-webdashboard@groups.io>, "John Ogness"<john.ogness@linutronix.de>
Date: Thu, 03 Sep 2026 21:37:09 +0300
Subject: Re: kernelci test results
> Hi Sebastian, I work with the dashboard team, so I hope I am able to help you.
>
> First of all, thanks for using the dashboard, and for taking time to
> write this up. Scenarios like this one are exactly what help us find
> the UX gaps for improvement.
>
> The dashboard is mostly organized around tree checkouts first.
> If i understood it properly you might be able to achieve what you are
> looking for via:
> 1. Selecting a tree (ie stable-rt/v6.6-rt).
> 2. Clicking on the filters button on the right. There we can apply
> filters for configs (defconfig+preempt_rt, etc).
> 3. We click on the tests tab (default tab is for builds).
> 4. On the list of tests you can search for test paths (cyclictest,
> rt-tests, etc).
>
> Link for the view:
> https://dashboard.kernelci.org/tree/stable-rt/v6.6-rt/84925bb144f49eb0d5f4c5c29f690b4bbf84903b?df|c|defconfig%2Bpreempt_rt=true&p=t
>
> That list is for that checkout across hardware, so you do not have to
> go board by board. (Unfortunately there is still no search for “this
> test on this device over time” across all trees.)
>
> About the other questions.
>
> All the logs presented are the ones that have been submitted via KCI
> submissions, so there might be some missing information when not
> reported.
>
> On the topic of notifying on log errors, this is a feature on active
> discussion, to automate notification for first for boots and later for
> test failures as well. Today we only notify registered issues.
>
> We are actually looking for some feedback of dashboard users to help
> us steer on the roadmap for new features, and your help would be much
> appreciated.
>
> Att
> Alan Peixinho
> KernelCI Dashboard Team
>
> On Thu, Sep 3, 2026 at 2:36 PM Sebastian Andrzej Siewior
> <bigeasy@linutronix.de> wrote:
> >
> > Hi,
> >
> > I've been poking at the dashboard to see how rt-tests tests are doing.
> > I tried to summarize my doing/ process and added questions while doing
> > so. I might be doing things wrong, not the expected way or simply
> > missing the obvious.
> >
> >
> > 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.
> >
> > 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".
> > Based on the timestamp the results are from today so I wouldn't expect
> > them to be deleted because of age.
> >
> > Going back to "trees" and selecting "stable-rt" and branch v6.6-rt
> > there is more HW. Clicking on bcm2711-rpi-4-b since it has the most
> > results here.
> >
> > Here I clicked on configs "defconfig+preempt_rt" and then one of tree
> > that appeared is "mainline/master" but I did not see this earlier while
> > I did select that tree.
> >
> > I did click on "tests" and then "rt-tests" appeared. Expanding it up, I
> > found cyclictest results for that tree.
> >
> > Clicking on details I found a link to
> > https://lava.collabora.dev/scheduler/job/22810572
> >
> > where the complete log is available of what has been done on that
> > hardware. In the bootlog I noticed
> > | [ 0.000000] WARNING: kernel/trace/trace_events.c:420 at test_double_dereference+0x128/0x130, CPU#0: swapper/0/0
> >
> > which is a warning that appeared during boot. Is this picked up
> > somewhere? Is there a notification sent somewhere that this has been
> > noticed?
> >
> > 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 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?
> > Right now I have no idea how to do this without going device by device.
> >
> > Sebastian
> >
>
>
next prev parent reply other threads:[~2026-09-04 5:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 15:43 kernelci test results Sebastian Andrzej Siewior
2026-09-03 18:37 ` Alan Zanoni Peixinho
2026-09-04 5:15 ` Denys Fedoryshchenko [this message]
2026-09-04 8:44 ` Ben Copeland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1a06ad7a5bf.36f8f8422502097.1545856430736765843@collabora.com \
--to=denys.f@collabora.com \
--cc=alan.peixinho@profusion.mobi \
--cc=bigeasy@linutronix.de \
--cc=john.ogness@linutronix.de \
--cc=kernelci-webdashboard@groups.io \
--cc=kernelci@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox