Re: mainline/master bisection: baseline.login on odroid-xu3

From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Mark Brown <broonie@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	kernelci-results@groups.io, bot@kernelci.org,
	gtucker@collabora.com, linux-arm-kernel@lists.infradead.org
Subject: Re: mainline/master bisection: baseline.login on odroid-xu3
Date: Sun, 17 Apr 2022 22:37:49 +0100	[thread overview]
Message-ID: <YlyIrd+lV6hihpcc@shell.armlinux.org.uk> (raw)
In-Reply-To: <YlyGXodyosHUcCDn@shell.armlinux.org.uk>

On Sun, Apr 17, 2022 at 10:27:58PM +0100, Russell King (Oracle) wrote:
> On Sun, Apr 17, 2022 at 08:35:29PM +0100, Mark Brown wrote:
> > On Sun, Apr 17, 2022 at 04:59:47AM -0700, KernelCI bot wrote:
> > 
> > The KernelCI bisection bot found a boot regression on Odroid-XU3 with
> > commit 8d9d651ff2270 (ARM: use LOADADDR() to get load address of
> > section).  It appears to trigger a deadlock somehow at some point after
> > the secondary CPUs come up:
> 
> If the primary CPU is still happy, then the secondary CPUs should be.
> Quite simply, if something is broken in the setup of the vectors, the
> primary CPU would also be affected by this commit. However...
> 
> > <6>[    0.133301] smp: Bringing up secondary CPUs ...
> > <6>[    0.138439] CPU1: thread -1, cpu 1, socket 1, mpidr 80000101
> > <6>[    0.139400] CPU2: thread -1, cpu 2, socket 1, mpidr 80000102
> > <6>[    0.140325] CPU3: thread -1, cpu 3, socket 1, mpidr 80000103
> > <6>[    0.141167] CPU4: thread -1, cpu 0, socket 0, mpidr 80000000
> > <6>[    0.141185] CPU4: Spectre v2: using ICIALLU workaround
> > <6>[    0.168676] CPU4: Spectre BHB: using loop workaround
> 
> Given that there was a problem with the loop implementation, please
> ensure that when you bisect, you have the following commit in place
> every time you test a bisect point:
> 
> 6c7cb60bff7a ("ARM: fix Thumb2 regression with Spectre BHB")
> 
> Otherwise, yes, it is known that Thumb2 will be broken.

Also, I should say, if this commit is really the case:

8d9d651ff227 ("ARM: use LOADADDR() to get load address of sections")

then I need to see two vmlinux binaries (the decompressed kernel ELF
image) for analysis of why this commit is causing the failure.
Basically, I need to disassemble the code and see what the toolchain
is doing to screw up the kernel.

If it isn't obvious from that, then I have no idea why this commit
would cause such a strange regression.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

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