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

[Sjoerd Simons]

On Sat, 2017-07-22 at 08:47 -0700, Kevin Hilman wrote:
> + 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/br
> > > anch/linux-4.12.y/kernel/v4.12.2-85-g908a8d27d1c5/
> > > Full Build Summary: https://kernelci.org/build/stable-rc/branch/l
> > > inux-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/li
> > > nux-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?

Adjusting the load address for XU3 resolved the boot failure (changing
from memory start + 16M to memory start + 32M which is the default for
that board in u-boot/lava as well these days)

> I suspect the same problem in the lab-collabora panda boots since the
> load address differes from mine in the same way.

Correct, tuning the load addresses there results in a happy boot.

The kernel does relocate itself on boot if it detects decompression
will overwrite itself. On the panda though that seemingly meant the dtb
got overwritten, just bumping that out of the way made it boot as well.
I didn't check if the same happened on XU3 (which has/had far more
space between the kernel and the dtb).. That said, it's far safer (and
faster) to avoid running into that corner case :) 

> @Sjoerd: can someone in lab-collabora maybe have a closer look?
> 
> Kevin

-- 
Sjoerd Simons
Collabora Ltd.