On 23/03/2019 00:09, Kevin Hilman wrote:

Guillaume,

"kernelci.org bot" bot@kernelci.org writes:

...

next/master boot: 96 boots: 1 failed, 94 passed with 1 untried/unknown (next-20190322)

Full Boot Summary: https://kernelci.org/boot/all/job/next/branch/master/kernel/next-20190322/ Full Build Summary: https://kernelci.org/build/next/branch/master/kernel/next-20190322/

Tree: next Branch: master Git Describe: next-20190322 Git Commit: e382d91f5f806abd770edeebe41851733aef1f93 Git URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Tested: 39 unique boards, 16 SoC families, 14 builds out of 223

Boot Regressions Detected:

arm:

multi_v7_defconfig:
    gcc-7:
      bcm2836-rpi-2-b:
          lab-collabora: failing since 41 days (last pass: next-20190206 - first fail: next-20190208)

Boot Failure Detected:

arm:

multi_v7_defconfig:
    gcc-7:
        bcm2836-rpi-2-b: 1 failed lab

This has been failing for awhile, and a quick look shows it's only failing on multi_v7_defconfig. bcm2835_defconfig is working fine.

It seems to be passing on stable-rc/linux-5.0.y[1]. Any chance you can trigger a bisect for that?

There have been multiple auto bisection that failed to resolve, and I've also investigated this manually. In the end it was just a classic case of having the kernel image overwrite the ramdisk. So I've changed the load address of the ramdisk in the LAVA device settings and it's booting again now (until multi_v7_defconfig gets big enough again to hit the new limit...).

Change submitted upstream:

https://git.lavasoftware.org/lava/lava/merge_requests/514

Guillaume

[1] https://kernelci.org/boot/id/5c9525fc59b5145c4afe6114/