Messages in this thread | | | From | Arnd Bergmann <> | Date | Tue, 19 Jul 2022 16:33:15 +0200 | Subject | Re: [RFC PATCH] arm: i.MX6 Cortex-A9: Fix memory ordering inconsistency by disabling prefetch instructions |
| |
On Mon, Jul 18, 2022 at 4:51 PM Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> Request for Feedback > ==================== > > This fix targets all i.MX configurations, but it is likely too broad (or > too narrow). It would be great if people with access to different > Freescale i.MX test boards, and test boards from other vendors, could try > to reproduce the issue to figure out what would be the right scope for > this fix. > > It would also be great if people with knowledge of the ARM CPU internals > could help understanding whether this fix really fixes an issue between > prefetch and memory barriers, or just happens to hide the issue. It > would be good to understand whether this issue only affects PLDW or if > it also affects the PLD instruction.
I don't have any relevant hardware at hand, but looked at this for a few hours today, unfortunately without any notable success. Just documenting what I did here:
- looked at the errata lists for cortex-a9 r2, for pl310 and for imxq6q to see if anything stuck out. I assume you've already done the same, but I can confirm that the errata that would match the symptom are listed as fixed in r2p10 or earlier.
- looked at objdump output from linux-image-5.18.0-0.bpo.1-armmp_5.18.2-1~bpo11+1_armhf.deb (not the same version, but hopefully be close enough), and compared that to v5.18.2 built with the same config using gcc-7.5 and gcc-10.3 to see if I could tell what is different. The output looks very similar, though my own gcc-10 apparently fails to inline arch_futex_atomic_op_inuser() and futex_atomic_op_inuser(). This looks like something we may want to force-inline in principle, but it seems unrelated to the bug you found since the debian vmlinux has these functions inlined and I don't think they are actually part of the broken code path.
- looked for other quad-core Cortex-A9 SoCs to find someone with a similar revision to check if they have the same bug. The closest I can think of is the OMAP4 that uses an A9 r1p2.
- Looked at the disabled errata handling in arch/arm/Kconfig. Unfortunately a couple of the workarounds we have there are now always disabled because of a dependency on ARCH_MULTIPLATFORM. It's a long shot, but you could try removing the dependencies and enabling all the Cortex-A9 fixes like ARM_ERRATA_742230, ARM_ERRATA_742231, ARM_ERRATA_743622, ARM_ERRATA_751472, and ARM_ERRATA_754327.
Arnd
| |