Re: [OE-core] [PATCH 2/2] oeqa: replace runltp with kirk

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2026-03-27 at 13:30 +0100, David Nyström wrote:
> 
> On Thu, 26 Mar 2026, Daniel Turull via lists.openembedded.org wrote:
> 
> > Just an update.
> > 
> > It is taking a bit more time than expected. My original test only
> > covered the math test suite in ltp to verify the functionality.
> > 
> > Some of the ltp test are failing with OOM, some related to systemd-
> > udev. I'll be disabling them now to have a working ltp. Then look
> > at the underlaying issues.
> > 
> > So far I have found 4 failing test cases. Using the default config
> > without any changes with qemux86-64
> > 
> > min_free_kbytes (mm) (OOM)
> 
> This seems to be a buggy testcase for automation. Disable until its
> fixed. 
> Even if the test own memory consumers sets their own OOM-score
> higher, 
> there are still chances that the OOM-killer kill the wrong things.
> 
> > pty07 (pty) (OOM)
> > ptem02 (pty) (OOM)
> 
> These seem to me to be related to systemd-udevd having unbounded
> message 
> queue sizes to its udev workers. IMO, this is a systemd-udevd issue. 
> Some other udev implementations starts dropping events.
> 
> We should have seen this when using runltp as well ?
> 
> Death spiral: systemd_259.5 
> 1. Test tight loop creating devices floods systemd-udevd's workers 
> unbounded inbox queue(s). 
> - Single core, low mem, and long running udev rules makes the problem
> worse.
> 2. systemd-udevd grows to consume all available RAM
> 3. OOM killer kills everything but systemd-udevd (OOMScoreAdjust=-
> 1000)
> 4. Kernel panic: "no killable processes"

Are the systemd developers aware of this?

You're correct that the ltp testing as currently run does sometimes
seem to have issues and not all tests pass. It is something we've been
wanting to look into and resolve but simply haven't had time.

Finding an issue like the systemd one does hint that there may be value
in some of the testing.

Ideally we'd identify and disable the problematic tests, then we would
know any failures were new and potential issues. The new version of the
patch series from Daniel does move us forward with that, thanks!

Cheers,

Richard