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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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.

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

--
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



[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux