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-g27b86a...
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.