Re: [PATCH] arm64: Disable big endian builds with clang

From: Robin Murphy <robin.murphy@arm.com>
To: Mark Brown <broonie@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>
Cc: Tri Vo <trong@google.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Nathan Huckleberry <nhuck@google.com>,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	Nathan Chancellor <natechancellor@gmail.com>,
	Will Deacon <will@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] arm64: Disable big endian builds with clang
Date: Wed, 7 Aug 2019 15:41:25 +0100	[thread overview]
Message-ID: <ec7bef46-7dcf-d165-b772-b4fd6055d964@arm.com> (raw)
In-Reply-To: <20190807123809.GA4048@sirena.co.uk>

On 07/08/2019 13:38, Mark Brown wrote:
> On Tue, Aug 06, 2019 at 04:47:23PM -0700, Nick Desaulniers wrote:
>> On Tue, Aug 6, 2019 at 2:25 PM Nick Desaulniers <ndesaulniers@google.com> wrote:
>>> On Tue, Aug 6, 2019 at 11:39 AM Mark Brown <broonie@kernel.org> wrote:
> 
>> +Huck
>> Huck notes that the device eventually boots in qemu, it just takes on
>> the order of 165 seconds to boot.  What's the timeout on KernelCI?
> 
> It's not a timeout in kernelci, it's the kernel timing out being unable
> to find something in userspace being booted it can use as /init (there's
> a timeout in that process to cope with network filesystems).  IIRC it's
> about 2 minutes.  You can see this clearly in the logs I pointed you at:
> 
> | You can see a bunch of reports here (all the big endian failures):
> 
> |         https://kernelci.org/boot/all/job/next/branch/master/kernel/next-20190730/
> 
> For example:
> 
> 	https://storage.kernelci.org/next/master/next-20190730/arm64/defconfig+CONFIG_CPU_BIG_ENDIAN=y/clang-8/lab-baylibre/boot-meson-gxbb-nanopi-k2.html

I thought it looked suspicious that there were EFI messages in that boot 
log; from that job's config: 
https://storage.kernelci.org/next/master/next-20190730/arm64/defconfig+CONFIG_CPU_BIG_ENDIAN=y/clang-8/kernel.config

...
# CONFIG_CPU_BIG_ENDIAN is not set
...

I think that's a kernelci problem...

Robin.

> 
>> I think if we can determine why we see:
>> [  144.626755] request_module: kmod_concurrent_max (0) close to 0
>> (max_modprobes: 50), for module binfmt-4c46, throttling...
>> [  149.752826] request_module: modprobe binfmt-4c46 cannot be
>> processed, kmod busy with 50 threads for more than 5 seconds now
> 
>> a lot, then we don't actually need to disable this outright when
>> building w/ Clang?
> 
> Those error messages are happening because the kernel can't figure out
> how to execute a binary it's trying to run, like I say the module it's
> trying to load is binfmt_misc.  If the kernel can't work out how to
> execute userspace it's not terribly useful.
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel