Re: [PATCH 4.12 00/84] 4.12.3-stable review

[Kevin Hilman]

+ 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