Re: [poky] [PATCH] parselogs-ignores-genericarm64.txt: ignore more KV260 warnings

Hi,

On Mon, Sep 15, 2025 at 12:09:03PM +0100, Richard Purdie wrote:
> On Tue, 2025-08-26 at 11:16 +0300, Mikko Rapeli via lists.yoctoproject.org wrote:
> > AMD KV260 shows more non-fatal error messages with sato image.
> > Power management, pin control and X11 errors can be ignored in
> > testing.
> > 
> > https://ledge.validation.linaro.org/scheduler/job/118932
> > 
> > Signed-off-by: Mikko Rapeli <[email protected]>
> > ---
> > �.../oeqa/runtime/cases/parselogs-ignores-genericarm64.txt� | 7 +++++++
> > �1 file changed, 7 insertions(+)
> > 
> > diff --git a/meta-yocto-bsp/lib/oeqa/runtime/cases/parselogs-ignores-genericarm64.txt b/meta-yocto-bsp/lib/oeqa/runtime/cases/parselogs-ignores-genericarm64.txt
> > index 1e8b1f4b7d1b..3e96a172da6d 100644
> > --- a/meta-yocto-bsp/lib/oeqa/runtime/cases/parselogs-ignores-genericarm64.txt
> > +++ b/meta-yocto-bsp/lib/oeqa/runtime/cases/parselogs-ignores-genericarm64.txt
> > @@ -1,4 +1,11 @@
> > �# safe to ignore minor firmware issue
> > �zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: failed to set: pin
> > +zynqmp-pinctrl firmware:zynqmp-firmware:pinctrl: set mux failed for pin
> > +request failed for node
> > +error -EACCES: failed to add to PM domain domain
> > +probe with driver sdhci-arasan failed with error
> > +Error applying setting, reverse things back
> > �# safe to ignore initrd warning
> > �Can't lookup blockdev
> > +# X11 fails to start without connected display
> > +modeset(0): failed to set mode: Invalid argument
> 
> The reason this has sat for a while is I really wanted to find time to
> dig into some of these a bit more. It is really easy to hide all this
> and ignore it but in some cases here, I think there probably should be
> some gentle pressure on the kernel or firmware people to clean up the
> "errors" which really aren't errors.
> 
> The trouble is, that kind of work is "hard" and it is much easier just
> to ignore these.
> 
> I suspect we probably need to merge it but I'm not particularly happy
> about doing so as it feels like the wrong fix.

In understand your concern. I've tried to fix these where possible
e.g. by enabling more and correct drivers in kernel but some of
these still remain.

The display related errors are sadly there because we don't have
HDMI displays connected to tested devices and different boards,
firmware and drivers report the failures in different ways.

Cheers,

-Mikko