Re: mainline/master boot bisection: v4.19-12838-g71e56028173b on beagle-xm

[Kevin Hilman <khilman@baylibre.com>]

Guillaume Tucker <guillaume.tucker@collabora.com> writes:

> On 06/11/2018 10:54, Guillaume Tucker wrote:
>> On 05/11/2018 14:33, Olof Johansson wrote:
>>> On Mon, Nov 5, 2018 at 1:43 AM Guillaume Tucker
>>> <guillaume.tucker@collabora.com> wrote:
>>>>
>>>> Hi Linus,
>>>>
>>>> Please see below, the kernelci.org automated boot bisection found
>>>> that the OMAP3 BeagleBoard-xM is failing to boot with SMP
>>>> disabled and PREEMPT enabled in multi_v7_defconfig.  There is no
>>>> log output after the bootloader so the kernel seems to be
>>>> crashing very early on.
>>>
>>> Can you enable DEBUG_LL to capture what goes wrong?
>> 
>> Yes I've scheduled a re-run of the automated bisection with
>> DEBUG_LL turned on, but the beagle-xm board is currently offline
>> in lab-baylibre.  I'll keep you posted when I get some results.
>
> Unfortunately, enabling the DEBUG_LL config didn't help.  There's
> still no visible kernel log at all from the failing LAVA jobs:
>
>     http://lava.baylibre.com:10080/scheduler/alljobs?length=25&search=lava-bisect-9638#table
>
>
> This might be a hard one to debug without physical access to the
> board, but please let me know if you think there's anything else
> I can try.  For example, if there's a known older kernel revision
> where the combination of SMP=n and PREEMPT=y worked then I could
> try to run an automated boot bisection based on that.

The reason DEBUG_LL doesn't show anything is because it also needs
a specific UART enabled for the output.  For the case of beagle-xm, it
needs CONFIG_DEBUG_OMAP3UART3=y also.

It did that locally, and the error on the console is this:

   Error: invalid dtb and unrecognized/unsupported machine ID
     r1=0x0000060a, r2=0x00000000
   Available machine support:

Upon closer inspection, the load addrs are such that it appears the DTB
is getting overwritten during zImage compression.

So bascially, it's just an (un)lucky fluke that CONFIG_PREEMPT=y changed
the kernel size just enough to cause this problem.

I did a local test (with pyboot, not LAVA) with all the same load
addresses, but without initrd_high and fdt_high, and it boots fine[1]

Guillaume, I think the proper solution is to fixup the LAVA device-type
for beagle-xm.  In particular, it's setting the u-boot variables
'initrd_high' and 'fdt_high' which means it's not letting uboot move
them.

Looks like that can be overridden in the device-dict using
"set base_high_limits = false", so I've done that now to this device[2]

Kevin

[1] http://termbin.com/9mm6
[2] http://lava.baylibre.com:10080/scheduler/device/omap3-beagle-xm-sea/devicedict