next/master boot: 273 boots: 63 failed, 209 passed with 1 untried/unknown (next-20171106)

[Arnd Bergmann]

On Thu, Nov 9, 2017 at 1:51 PM, Guillaume Tucker
<guillaume.tucker at collabora.com> wrote:
> On 09/11/17 11:29, Jon Hunter wrote:
>>
>>
>> On 09/11/17 10:43, Guillaume Tucker wrote:
>>
>> ...
>>
>>> I actually built these kernel revisions with module support
>>> disabled to speed up the builds, and no modules are being
>>> downloaded in the LAVA job.
>>>
>>> If you have a public URL with your known working kernel zImage
>>> and dtb, let me know so I could re-run the same test LAVA boot
>>> test to see if I get the same results as you (i.e. no hang).
>>
>>
>> I don't have a public URL for the zImage but I can definitely email it
>> to you. By the way, when booting I am setting 'init=/bin/bash' so no
>> start-up scripts are running.
>
>
> Thanks, I tried your binary and it booted fine.  I built
> next-20171109 again with and without loadable module support
> enabled and it fails with it disabled but passes with it
> enabled (even without actually loading any modules):
>
>   * with CONFIG_MODULES disabled (fails):
>     https://lava.collabora.co.uk/scheduler/job/981215
>
>   * with plain multi_v7_defconfig and no modules loaded (passes):
>     https://lava.collabora.co.uk/scheduler/job/981217
>
>
> So I guess this means disabling loadable modules support has some
> interesting side-effects that cause the kernel to crash.  I think
> the kci builds all leave modules enabled with multi_v7_defconfig,
> so the failing boots must be due to something else.  Taking
> another look at the failing kci boots now...

The one thing that comes to mind that happened recently with
modules is

371435f78e9e ("kernel debug: support resetting WARN_ONCE for all architectures")

Can you try reverting this? It's probably something else, but I'd like
to rule it out.

      Arnd