On Thu, Nov 9, 2017 at 1:51 PM, Guillaume Tucker <guillaume.tucker@xxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
