Messages in this thread | | | From | Ard Biesheuvel <> | Date | Sat, 16 Nov 2019 16:35:53 +0100 | Subject | Re: rmk/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3 |
| |
On Sat, 16 Nov 2019 at 11:49, Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > > On Sat, Nov 16, 2019 at 10:26:27AM +0000, Ard Biesheuvel wrote: > > (+ Arnd) > > > > On Sat, 16 Nov 2019 at 05:54, kernelci.org bot <bot@kernelci.org> wrote: > > > > > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > > * This automated bisection report was sent to you on the basis * > > > * that you may be involved with the breaking commit it has * > > > * found. No manual investigation has been done to verify it, * > > > * and the root cause of the problem may be somewhere else. * > > > * * > > > * If you do send a fix, please include this trailer: * > > > * Reported-by: "kernelci.org bot" <bot@kernelci.org> * > > > * * > > > * Hope this helps! * > > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > > > > > rmk/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3 > > > > > > Summary: > > > Start: b6c3c42cfda0 ARM: 8938/1: kernel: initialize broadcast hrtimer based clock event device > > > Details: https://kernelci.org/boot/id/5dcf3f0359b514dc84cf54c8 > > > Plain log: https://storage.kernelci.org//rmk/for-next/v5.4-rc5-26-gb6c3c42cfda0/arm/oxnas_v6_defconfig/gcc-8/lab-baylibre/boot-ox820-cloudengines-pogoplug-series-3.txt > > > HTML log: https://storage.kernelci.org//rmk/for-next/v5.4-rc5-26-gb6c3c42cfda0/arm/oxnas_v6_defconfig/gcc-8/lab-baylibre/boot-ox820-cloudengines-pogoplug-series-3.html > > > Result: ea70bf6e92c5 ARM: 8935/1: decompressor: avoid CP15 barrier instructions in v7 cache setup code > > > > > > > OK, so this regression is caused by the fact that the 'armv7' cache > > maintenance routines in the decompressor are also used for ARMv6 cores > > if they implement the CPUID extension, which I failed to realise when > > I sent this patch. > > > > There are roughly three ways to deal with this: > > 1) add a mask/val match pair for ARM11MPcore and ARM1176 that hardwire > > them to the ARMv6 routines, even though they implement the CPUID > > extension. This would be very easy, but assumes that those two cores > > are the only ones that are affected by this. > > 2) modify the v7 routines to check for the L1Hvd MMFR1 attribute (in > > the flush routine) and for the CP15BEN SCTLR bit (in the on/off > > routines), and jump to the respective v6 variants if the CPU turns out > > not to support the v7 one. > > 3) revert the patch, and just enable the CP15 barriers (and issue a v7 > > barrier) in the v7 on() and flush() routines. > > > > I am leaning towards the latter, since it is the most straightforward, > > even though it mixes v7 and cp15 barriers in the same function, but > > that was mostly a cosmetic concern anyway. > > I'm going to drop the patches - if -rc8 is released tomorrow maybe we > can have a go at solving it next week. >
Fair enough.
| |