lkml.org 
[lkml]   [2022]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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

\
 
 \ /
  Last update: 2022-07-19 16:40    [W:0.073 / U:0.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site