From: Marek Szyprowski <m.szyprowski@samsung.com> To: Sudeep Holla <sudeep.holla@arm.com> Cc: linux-arm-kernel@lists.infradead.org, Liviu Dudau <liviu.dudau@arm.com>, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>, LKML <linux-kernel@vger.kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org> Subject: Re: ARM Juno r1 + CONFIG_PROVE_LOCKING=y => boot failure Date: Fri, 11 Oct 2019 12:21:23 +0200 [thread overview] Message-ID: <d315d99c-ef5d-eae0-86e0-a6d71355ffc1@samsung.com> (raw) In-Reply-To: <20191011100521.GA5122@bogus> Hi Sudeep, On 11.10.2019 12:05, Sudeep Holla wrote: > Hi Marek, > > On Fri, Oct 11, 2019 at 11:26:04AM +0200, Marek Szyprowski wrote: >> Hi >> >> Recently I've got access to ARM Juno R1 board and did some tests with >> current mainline kernel on it. I'm a bit surprised that enabling >> CONFIG_PROVE_LOCKING causes a boot failure on this board. After enabling >> this Kconfig option, I get no single message from the kernel, although I >> have earlycon enabled. >> > I don't have Juno R1 but I tried defconfig + CONFIG_PROVE_LOCKING and > it boots fine. > > So if you disable CONFIG_PROVE_LOCKING(i.e. defconfig) boots fine ? > Are you using DTB from the mainline ? Yes, ARM Juno r1 boots fine with pure defconfig and mainline dtb. However a few minutes ago I found that it boots with v4.14+PROVE_LOCKING, so I will bisect it and share the results. >> I've did my test with default defconfig and current linux-next, >> v5.4-rc1, v5.3 and v4.19. In all cases the result is the same. I'm >> booting kernel using a precompiled uboot from Linaro release and TFTP >> download. >> > OK, I use UEFI+GRUB but I don't think that should cause any issue. > >> Is this a known issue? Other ARM64 boards I have access to (Samsung TM2e >> and RaspberryPi3) boots fine with the same kernel image. >> > Not that I am aware of. If you could send me the bootlog with defconfig > I can take a look and see if I get any clue. > Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
WARNING: multiple messages have this Message-ID (diff)
From: Marek Szyprowski <m.szyprowski@samsung.com> To: Sudeep Holla <sudeep.holla@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>, Catalin Marinas <catalin.marinas@arm.com>, Liviu Dudau <liviu.dudau@arm.com>, LKML <linux-kernel@vger.kernel.org>, Will Deacon <will@kernel.org>, linux-arm-kernel@lists.infradead.org Subject: Re: ARM Juno r1 + CONFIG_PROVE_LOCKING=y => boot failure Date: Fri, 11 Oct 2019 12:21:23 +0200 [thread overview] Message-ID: <d315d99c-ef5d-eae0-86e0-a6d71355ffc1@samsung.com> (raw) In-Reply-To: <20191011100521.GA5122@bogus> Hi Sudeep, On 11.10.2019 12:05, Sudeep Holla wrote: > Hi Marek, > > On Fri, Oct 11, 2019 at 11:26:04AM +0200, Marek Szyprowski wrote: >> Hi >> >> Recently I've got access to ARM Juno R1 board and did some tests with >> current mainline kernel on it. I'm a bit surprised that enabling >> CONFIG_PROVE_LOCKING causes a boot failure on this board. After enabling >> this Kconfig option, I get no single message from the kernel, although I >> have earlycon enabled. >> > I don't have Juno R1 but I tried defconfig + CONFIG_PROVE_LOCKING and > it boots fine. > > So if you disable CONFIG_PROVE_LOCKING(i.e. defconfig) boots fine ? > Are you using DTB from the mainline ? Yes, ARM Juno r1 boots fine with pure defconfig and mainline dtb. However a few minutes ago I found that it boots with v4.14+PROVE_LOCKING, so I will bisect it and share the results. >> I've did my test with default defconfig and current linux-next, >> v5.4-rc1, v5.3 and v4.19. In all cases the result is the same. I'm >> booting kernel using a precompiled uboot from Linaro release and TFTP >> download. >> > OK, I use UEFI+GRUB but I don't think that should cause any issue. > >> Is this a known issue? Other ARM64 boards I have access to (Samsung TM2e >> and RaspberryPi3) boots fine with the same kernel image. >> > Not that I am aware of. If you could send me the bootlog with defconfig > I can take a look and see if I get any clue. > Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-10-11 10:21 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <CGME20191011092604eucas1p1ca11ab9c4c7508776914b0eb4f35e69b@eucas1p1.samsung.com> 2019-10-11 9:26 ` ARM Juno r1 + CONFIG_PROVE_LOCKING=y => boot failure Marek Szyprowski 2019-10-11 10:05 ` Sudeep Holla 2019-10-11 10:05 ` Sudeep Holla 2019-10-11 10:21 ` Marek Szyprowski [this message] 2019-10-11 10:21 ` Marek Szyprowski 2019-10-11 10:38 ` James Morse 2019-10-11 10:38 ` James Morse 2019-10-11 10:59 ` Sudeep Holla 2019-10-11 10:59 ` Sudeep Holla 2019-10-11 13:02 ` Marek Szyprowski 2019-10-11 13:02 ` Marek Szyprowski 2019-10-11 13:10 ` Sudeep Holla 2019-10-11 13:10 ` Sudeep Holla 2019-10-11 13:15 ` Marek Szyprowski 2019-10-11 13:15 ` Marek Szyprowski 2019-10-11 13:43 ` Sudeep Holla 2019-10-11 13:43 ` Sudeep Holla 2019-10-11 14:42 ` Sudeep Holla 2019-10-11 14:42 ` Sudeep Holla 2019-10-14 9:02 ` Marek Szyprowski 2019-10-14 9:02 ` Marek Szyprowski 2019-10-14 10:16 ` James Morse 2019-10-14 10:16 ` James Morse
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=d315d99c-ef5d-eae0-86e0-a6d71355ffc1@samsung.com \ --to=m.szyprowski@samsung.com \ --cc=catalin.marinas@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=liviu.dudau@arm.com \ --cc=lorenzo.pieralisi@arm.com \ --cc=sudeep.holla@arm.com \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.