+ Sjoerd @ Collabora Shuah Khan <shuahkh@xxxxxxxxxxxxxxx> writes: > On 07/19/2017 10:29 AM, kernelci.org bot wrote: >> stable-rc/linux-4.12.y boot: 166 boots: 5 failed, 161 passed (v4.12.2-85-g908a8d27d1c5) >> >> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.12.y/kernel/v4.12.2-85-g908a8d27d1c5/ >> Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.12.y/kernel/v4.12.2-85-g908a8d27d1c5/ >> >> Tree: stable-rc >> Branch: linux-4.12.y >> Git Describe: v4.12.2-85-g908a8d27d1c5 >> Git Commit: 908a8d27d1c52aaafab80d7267e8e61f9a174ecc >> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git >> Tested: 44 unique boards, 14 SoC families, 24 builds out of 204 >> >> Boot Regressions Detected: >> >> arm: >> >> multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: >> exynos5422-odroidxu3: >> lab-collabora: new failure (last pass: v4.12.2) > > I am seeing boot failure on odroid-xu4 with 4.13-rc1 with exynos_defconfig. > 4.12 is fine. > > I am debugging this and based on this report it sounds like it might be > easier for me to start with 4.12 and try to isolate the change. Will keep > you posted. I suspect that these CONFIG_PROVE_LOCKING=y issues are actually not kernel issues directly, but kernel size limitations based on the load addresses used in lab-collabora LAVA. Comparing against my lab, I'm using load address: 0x42000000 where as lab-collabora is using 0x41000000. I'm wondering if that is not enough room to ucompress down to the default boot address without overwriting itself? I suspect the same problem in the lab-collabora panda boots since the load address differes from mine in the same way. @Sjoerd: can someone in lab-collabora maybe have a closer look? Kevin