Linux boot hangs on arm64 Chromebooks running kernels with kselftest cfg

[hardboprobot]

Multiple arm64 Chromebooks are failing to boot, causing tests to fail. This is noticeable in the simple baseline.login test and it's seen at least in kevin, jacuzzi and asurada.

Examples with kernel v6.5-rc5-387-g4c75bf7e4a0e5:

• https://linux.kernelci.org/test/case/id/64d92a604775b78e6335b1e3/ (https://lava.collabora.dev/scheduler/job/11279618)
• https://linux.kernelci.org/test/case/id/64d6abe546c8844ed635b1da/ (https://lava.collabora.dev/scheduler/job/11267457)

The test result seems to be affected by the kernel configuration used. Specifically, it fails when using the kselftest config fragment but it passes otherwise. For instance, same kernel version on kevin configured with defconfig+arm64-chromebook+videodec: https://linux.kernelci.org/test/case/id/64d6a79d4e3186aded35b230/ (https://lava.collabora.dev/scheduler/job/11267308)

After repeated testing to narrow down the problem, I found that for a fixed kernel version, configuration variant and device, the test may either pass or fail depending on the KernelCI-core version used to build the kernel image. Here are some results on kevin using the same kernel version (v6.2-rc7) and config variant (defconfig+arm64-chromebook+kselftest) in all cases:

Kernel image and modules built with kernelci-core tag kernelci-20230206.0:

• https://lava.collabora.dev/scheduler/job/11282702 (PASS). The kernel config generated is
  kernelci-20230206.0_config.txt

Kernel image and modules built with kernelci-core tag kernelci-20230213.0:

• https://lava.collabora.dev/scheduler/job/11282726 (FAIL). The kernel config generated is
  kernelci-20230213.0_config.txt

The only noticeable difference in the logs is that the one that passes shows this:

<3>[    8.377861] IP-Config: Failed to open gretap0
<3>[    8.383330] IP-Config: Failed to open erspan0

which is missing in the one that fails. My theory is that both runs would fail to configure the network interfaces via DHCP, but in the case that passes the network auto configuration times out faster and the boot keeps going, while in the other case the auto configuration keeps trying for longer and it causes the LAVA job to time out and fail. But the only differences in the kernel config from the version that passes to the one that fails are these:

 DRM_MSM m -> y
 NFS_V3_ACL n -> y
 QCOM_OCMEM m -> y
+NFS_ACL_SUPPORT y

And I don't know how this would make any difference in this case.