Re: chrome-platform/for-kernelci baseline: 98 runs, 5 regressions (v6.1-rc1-5-g27b86a65cd16)

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2695 bytes --]

On Mon, Oct 31, 2022 at 03:21:55PM -0700, Brian Norris wrote:
> On Mon, Oct 31, 2022 at 09:37:28PM +0000, Mark Brown wrote:
> > On Mon, Oct 31, 2022 at 10:40:25AM -0700, Brian Norris wrote:

> > The baseline tests are just making sure that the system comes up to a
> > shell.  The driver loaded tests are checking that particular devices
> > have a driver bound to them.

> For one specific example: I'm looking at rockchip-i2s1-probed, which
> fails here:

> https://storage.kernelci.org/chrome-platform/for-kernelci/v6.1-rc1-5-g27b86a65cd16/arm64/defconfig+arm64-chromebook/gcc-10/lab-collabora/baseline-rk3399-gru-kevin.html

Not the exact same job but a LAVA defintion for that one can be seen at

   https://lava.collabora.dev/scheduler/job/7797321/definition

> I can't find a single mention of "i2s1" or "probed" in the kernelci
> repo, so I must be missing something. Is there some external config
> file in another repo? Or else the test configs are autogenerating cases
> on the fly based on parsing...the device tree?

The KernelCI repo just says what testsuites to invoke and how, it's not
got the actual testsuites.  Those X didn't probe failures come from
bootrr:

   https://github.com/andersson/bootrr

forked to:

   https://github.com/kernelci/bootrr

(which could use some upstreaming...) with the specific errors for
gru-kevin coming from:

   https://github.com/kernelci/bootrr/blob/main/boards/google%2Ckevin

which ends up in our rootfss.

Those failures in particular come from some reorganisation of the DT for
the Rockchip devices a while back which regularly gets bisected by our
bisect bot, I did report it or something very similar as looking like a
false positive but nobody followed up.  I see there's some version
dependent checks for the acclerators which may not be working properly
any more I guess but nothing for the I2S.

> Anyway, I don't know how or why that ever passed, because AFAICT, RK3399
> Chromebooks should only have a single I2S block enabled, and they're
> passing the 'rockchip-i2s0-probed' case. So it feels like I need to be
> disabling some test case.

Yes, that was what I'd determined too - the reorganisation of the DT
looked legit, I can't remember what it was exactly.  I suspect it may
have boiled down to adding some missing default disables, or removing an
erroious enable for the board.

> Somewhat similar story for cros-ec-sensors-accel{0,1}-probed, although I
> believe the sensor driver is still working for me; I also see no
> cros-ec-sensors errors in the KernelCI logs. So I wonder what exactly
> the test is looking for (e.g., maybe the device name changed?).

IIRC there were some of these that were a device name change.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]