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

[Guillaume Tucker]

On 09/11/17 15:23, Jon Hunter wrote:
>
> On 09/11/17 13:17, Arnd Bergmann wrote:
>> 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.
>
> I have been able to reproduce the problem by disabling support for
> loadable modules on both Tegra124 Nyan-Big and Jetson TK1. Disabling
> DRM_NOUVEAU appears to avoid the problem.
>
> Guillaume can you try the same?

Alright, so here's all the results I got all based on
next-20171109 and running on tegra124-nyan-big:

   * plain multi_v7_defconfig, passes:
     https://lava.collabora.co.uk/scheduler/job/981295

   * CONFIG_MODULES disabled, fails:
     https://lava.collabora.co.uk/scheduler/job/981342

   * CONFIG_MODULES and CONFIG_DRM_NOUVEAU disabled, also fails:
     https://lava.collabora.co.uk/scheduler/job/981343

   * CONFIG_MODULES disabled and 371435f78 [0] reverted, also fails:
     https://lava.collabora.co.uk/scheduler/job/981353


What I could try to run next is a bisection with CONFIG_MODULES
disabled between when the DRM branch got merged (so the first
crash should be fixed) and next-20171109.


Guillaume

[0] "kernel debug: support resetting WARN_ONCE for all architectures"
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=371435f78e9e26519763411c2cd20975d2293efe