jobs-chromeos.yaml: Prevent deferred probe timeout errors

[nfraprado]

Jobs submitted from LAVA always pass an ip= parameter to the kernel (eg on depthcharge see [1]).

Chromebooks wired to the network using a servo board rely on the RTL8152 driver in order to have a working network interface.

Since the RTL8152 is currently enabled as a module, it is only available once the ramdisk loads the modules. However, due to the ip= parameter, the kernel tries to do IP auto configuration before the ramdisk has loaded, but since there are no network interfaces available, it waits for 12 seconds, in order to wait for some potential slow interfaces to get up [2], before carrying on with the boot process. Meanwhile, when 10 seconds elapse between the registering of two consecutive drivers, the deferred probe timer times out, which can result on some drivers probing with unmet dependencies and cause all sort of malfunctions of devices.

The end result is that not only are all arm64 chromebooks wasting 12 seconds on every boot, but the MediaTek-based Chromebooks are also booting to a broken state with "deferred probe pending" error messages being printed and causing tests to fail sometimes, introducing noise in the test results.

With the ChromeOS config, this issue doesn't happen since CONFIG_IP_PNP is disabled so the ip= parameter is ignored.

Enable the USB_RTL8152 driver as builtin to prevent the aforementioned issues.

[1] https://github.com/Linaro/lava/blob/e6db819ca9ff477885caac3b1603a2037a2a2331/etc/dispatcher-config/device-types/base-depthcharge.jinja2#L42 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=964ad81cbd933e5fa310faeec1e923c14651284b

[nfraprado]

@a-wai oops, sorry, I meant to add it on top of the others, so

      fragments:
        - arm64-chromebook
        - CONFIG_MODULE_COMPRESS=n
        - CONFIG_USB_RTL8152=y # Allows kernel ip-config. Prevents deferred probe timeout errors.

Would that be ok? I feel like there are too many configs in the arm64-chromebook already, and I'd like the option of running jobs without all of them applied on the platforms where it's possible...

[a-wai]

That would also work, yes (maybe without the inline comment, I'm not sure it would be properly parsed that way, having it right above the entry is fine though).

[a-wai]

However having it built-in would help speed up a (tiny) bit jobs running on arm64 chromebooks (we already have it set in the x86-board fragment FWIW)

[nfraprado]

@a-wai what do you mean by "having it built-in"? That's what we're doing here. And yes, I know it's already set on the x86-board fragment, which is why x86 chromebooks aren't experiencing these boot delays.

I don't have strong preferences on how to do it, just want to get the config in ASAP :).

[a-wai]

@a-wai what do you mean by "having it built-in"?

I kinda forgot the "always" word in this sentence ;)

And yes, I know it's already set on the x86-board fragment, which is why x86 chromebooks aren't experiencing these boot delays.

My point was more like "we have it in the fragment for x86 chromebooks, we don't consider it harmful, so having it in the fragment for arm64 chromebooks shouldn't be an issue".

All in all, I'd really prefer to have it part of the arm64-chromebook fragment so we don't have to bother about it anymore.

[nfraprado]

@a-wai Done in https://github.com/kernelci/kernelci-core/pull/2518 . (I've kept the comment inline because I see other occurences of it in that file, so should be fine, and having it inline prevents the comment from being separated from the config by other commits adding more configs)