Re: [poky] [PATCH v2 2/2] oeqa runtime parselogs: ignore KV260 USB error on genericarm64

Richard Purdie <[email protected]> Sat, 07 Mar 2026 22:23:38 +0000
Newsgroups org.yoctoproject.lists.poky
Message-ID <d1047820faf4180c123c0320c88a7804acfaddb4.camel@linuxfoundation.org>
On Fri, 2026-03-06 at 15:52 +0200, Mikko Rapeli wrote:
> Hi,
>=20
> On Fri, Mar 06, 2026 at 12:17:32PM +0000, Richard Purdie wrote:
> > On Fri, 2026-03-06 at 11:33 +0200, Mikko Rapeli via lists.yoctoproject.=
org wrote:
> > > On AMD KV260 the USB 1-1 driver sometimes throws this new warning at =
boot but
> > > continues and USB stack works so ignore the error:
> > >=20
> > > usb 1-1: device descriptor read/64, error -71
> > > hub 1-1:1.0: USB hub found
> > > hub 1-1:1.0: 5 ports detected
> > > usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
> > > hub 2-1:1.0: USB hub found
> > > hub 2-1:1.0: 4 ports detected
> > >=20
> > > https://lists.yoctoproject.org/g/automated-testing/message/1525
> > >=20
> > > Signed-off-by: Mikko Rapeli <[email protected]>
> >=20
> > I'm sure people will tell me I should just merge these and we move on.
> >=20
> > Before I do that, I want to be really clear that this approach really
> > isn't great. It amounts to "oh, we have errors we don't even understand
> > but we'll just ignore them and hope for the best". Should we even
> > bother with the test if we're just going to ignore anything it shows
> > up?
> >=20
> > I appreciate Mikko can't go and fight the world on issues like this and
> > this isn't directed at him, it is just a general frustration with the
> > "quality" of where software seems to be going.
> >=20
> > Where do we draw the line if we're just going to ignore any error?
>=20
> I think the maintainers needs to decide.
>=20
> I maintain yocto genericarm64 testing on real target HW like the AMD KV26=
0 and thus
> I've decided that I accept these workarounds. These changes do not impact
> other SW or maintainers in meta-yocto git repo so I think applying the co=
mmit
> is safe.
>=20
> The parselogs test is really good, too good infact, in finding issues com=
ing from DUT HW,
> lab setup with DUT, firmware, kernel and rest of the high level yocto
> based OS image. Since my maintenance time is limited I need to
> decide which issues to fix and which to just accept. It is ok to challeng=
e my
> decisions and especially help with fixing the actual root causes. Any HW =
vendors,
> please step in to help!
>=20
> I have been able to fix DUT HW setup issues for example by adding dummy H=
DMI
> adapters so that Xorg startup completes, fix firmware and kernel issues f=
or
> some of the devices like Xorg 16bpp graphics output, and fix higher level
> oddities like systemd udev breakages so I do some analysis and try fix is=
sues
> before adding these workarounds.

That is good to know, I knew you'd fixed some things but I am glad it
it doesn't have a totally bad reputation!

> Another aspect is the reuse of oeqa runtime tests in other environments a=
nd
> genericarm64 showing an example how to do that in the imperfect world. I
> would like to see more of this since they are actually pretty good basis =
for
> doing CI and on target testing. But that testing environment is complex a=
nd
> target HW and firmware by definition unstable since they are under develo=
pment,
> even after vendors ship the HW and provide the BSP SW adaptations. Thus
> these layer specific ignore lists are likely needed in custom
> environments to get basic set of tests working and to stop new issues fro=
m popping
> up, which is actually really important. It is important to get stable tes=
ting results
> and it is important to find bugs and fixes for them. The parselogs findin=
gs are
> sometimes rare oddities but sadly common with real HW, firmware and yocto=
 based OSes.
> That world is never perfect black and white, the gray zone is quite thick=
. That
> is where parselogs ignore lists fit, into the gray zone when someone need=
s make
> something imperfect but usable to produce reliable pass or fail results i=
n testing.

The higher level software tests struggle with many of the same issues.
We're slowly winning there but it has taken a lot to get to where we
are. Definitely worthwhile in the long run though.

Cheers,

Richard