On Thu, Nov 9, 2017 at 1:51 PM, Guillaume Tucker guillaume.tucker@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