Re: linusw/devel boot bisection: v5.4-rc1-31-g6a41b6c5fc20 on rk3399-puma-haikou

[Guillaume Tucker <guillaume.tucker@xxxxxxxxxxxxx>]

On 04/11/2019 15:18, Linus Walleij wrote:
> On Thu, Oct 31, 2019 at 8:35 PM Chris Packham
> <Chris.Packham@xxxxxxxxxxxxxxxxxxx> wrote:
>> On Thu, 2019-10-31 at 11:41 -0700, kernelci.org bot wrote:
> 
>>> Breaking commit found:
>>>
>>> -------------------------------------------------------------------------------
>>> commit 6a41b6c5fc20abced88fa0eed42ae5e5cb70b280
>>> Author: Chris Packham <chris.packham@xxxxxxxxxxxxxxxxxxx>
>>> Date:   Fri Oct 25 09:27:03 2019 +1300
>>>
>>>     gpio: Add xgs-iproc driver
>>>
>>>     This driver supports the Chip Common A GPIO controller present on a
>>>     number of Broadcom switch ASICs with integrated SoCs. The controller is
>>>     similar to the pinctrl-nsp-gpio and pinctrl-iproc-gpio blocks but
>>>     different enough that a separate driver is required.
>>>
>>>     This has been ported from Broadcom's XLDK 5.0.3 retaining only the CCA
>>>     support (pinctrl-iproc-gpio covers CCB).
>>>
>>>     Signed-off-by: Chris Packham <chris.packham@xxxxxxxxxxxxxxxxxxx>
>>>     Link: https://lore.kernel.org/r/20191024202703.8017-3-chris.packham@xxxxxxxxxxxxxxxxxxx
>>>     Acked-by: Scott Branden <scott.branden@xxxxxxxxxxxx>
>>>     Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx>
>>
>> Hmm,
>>
>> I don't see how this commit would have caused the oops. The new driver
>> shouldn't (and doesn't appear to be) run on any platform as nothing
>> declares .compatible = "brcm,iproc-gpio-cca" (yet).
> 
> I think it looks really bogus as well.
> 
> Could it be that these systems are memory constrained such that
> the kernel image just exactly right now collides with the upper
> memory limit or corrupts its own ramdisk?
> 
> I suppose I can't ask the kernel robot to do any more detailed
> debugging.
> 
> I can't see any problem with this patch.

Yes it's possible that this patch increases the kernel image size
above a threshold that causes the board to fail to boot.  However
that board isn't in the Collabora lab so I don't have direct
access to it.  I'll see what we can do to debug this, will
disable bisections in lab-theobrama-systems for now to avoid more
noise.

Guillaume