On Thu, Nov 8, 2018 at 2:34 PM Kevin Hilman <khilman@xxxxxxxxxxxx> wrote: > > Guillaume Tucker <guillaume.tucker@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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] Argh, I remember hitting these issues a few times through the years. Thanks for finding the problem, Kevin. -Olof
