From: Will Deacon <will.deacon@arm.com>
To: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>, Paul Walmsley <paul@pwsan.com>,
linux-omap@vger.kernel.org,
Rajendra Nayak <rnayak@codeaurora.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] ARM: avoid Cortex-A9 livelock on tight dmb loops
Date: Mon, 4 Jun 2018 10:42:43 +0100 [thread overview]
Message-ID: <20180604094241.GE9482@arm.com> (raw)
In-Reply-To: <E1fOhn6-00008E-3b@rmk-PC.armlinux.org.uk>
Hi Russell,
On Fri, Jun 01, 2018 at 12:00:16PM +0100, Russell King wrote:
> Executing loops such as:
>
> while (1)
> cpu_relax();
>
> with interrupts disabled results in a livelock of the entire system,
> as other CPUs are prevented making progress. This is most noticable
> as a failure of crashdump kexec, which stops just after issuing:
>
> Loading crashdump kernel...
>
> to the system console. Two other locations of these loops within the
> ARM code have been identified and fixed up.
Can you confirm that this only happens if CONFIG_ARM_ERRATA_754327=y?
The only erratum I can find for A9 that matches this behaviour exists
when the body of the tight loop contains a DMB and some of the possible
workarounds are:
- Add ten NOPs after the DMB
- Use DSB instead of DMB in the tight loop
- Set bit 16 in the diagnostic control register (p15, c1, 5, 0, c0, 1)
WFE is probably fine (the write-up isn't clear), but if this only occurs
due to CONFIG_ARM_ERRATA_754327=y it would be nice to mitigate it in the
alternative cpu_relax() definition itself, which isn't generally possible
with WFE.
Will
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] ARM: avoid Cortex-A9 livelock on tight dmb loops
Date: Mon, 4 Jun 2018 10:42:43 +0100 [thread overview]
Message-ID: <20180604094241.GE9482@arm.com> (raw)
In-Reply-To: <E1fOhn6-00008E-3b@rmk-PC.armlinux.org.uk>
Hi Russell,
On Fri, Jun 01, 2018 at 12:00:16PM +0100, Russell King wrote:
> Executing loops such as:
>
> while (1)
> cpu_relax();
>
> with interrupts disabled results in a livelock of the entire system,
> as other CPUs are prevented making progress. This is most noticable
> as a failure of crashdump kexec, which stops just after issuing:
>
> Loading crashdump kernel...
>
> to the system console. Two other locations of these loops within the
> ARM code have been identified and fixed up.
Can you confirm that this only happens if CONFIG_ARM_ERRATA_754327=y?
The only erratum I can find for A9 that matches this behaviour exists
when the body of the tight loop contains a DMB and some of the possible
workarounds are:
- Add ten NOPs after the DMB
- Use DSB instead of DMB in the tight loop
- Set bit 16 in the diagnostic control register (p15, c1, 5, 0, c0, 1)
WFE is probably fine (the write-up isn't clear), but if this only occurs
due to CONFIG_ARM_ERRATA_754327=y it would be nice to mitigate it in the
alternative cpu_relax() definition itself, which isn't generally possible
with WFE.
Will
next prev parent reply other threads:[~2018-06-04 9:42 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-01 11:00 [PATCH v2] ARM: avoid Cortex-A9 livelock on tight dmb loops Russell King
2018-06-01 11:00 ` Russell King
2018-06-01 15:35 ` Tony Lindgren
2018-06-01 15:35 ` Tony Lindgren
2018-06-01 15:55 ` Russell King - ARM Linux
2018-06-01 15:55 ` Russell King - ARM Linux
2018-06-01 16:12 ` Tony Lindgren
2018-06-01 16:12 ` Tony Lindgren
2018-06-04 9:42 ` Will Deacon [this message]
2018-06-04 9:42 ` Will Deacon
2018-06-04 18:08 ` Russell King - ARM Linux
2018-06-04 18:08 ` Russell King - ARM Linux
-- strict thread matches above, loose matches on Subject: below --
2019-01-25 21:03 Russell King
2019-01-25 21:03 ` Russell King
2019-01-25 23:20 ` Tony Lindgren
2019-01-25 23:20 ` Tony Lindgren
2019-01-26 21:00 ` Paul Walmsley
2019-01-26 21:00 ` Paul Walmsley
2019-01-26 23:51 ` Russell King - ARM Linux admin
2019-01-26 23:51 ` Russell King - ARM Linux admin
2019-01-27 1:15 ` Paul Walmsley
2019-01-27 1:15 ` Paul Walmsley
2019-01-27 15:28 ` Russell King - ARM Linux admin
2019-01-27 15:28 ` Russell King - ARM Linux admin
2019-01-31 13:58 ` Will Deacon
2019-01-31 13:58 ` Will Deacon
2019-01-31 22:58 ` Russell King - ARM Linux admin
2019-01-31 22:58 ` Russell King - ARM Linux admin
2019-02-01 10:19 ` Will Deacon
2019-02-01 10:19 ` Will Deacon
2019-02-01 21:20 ` Russell King - ARM Linux admin
2019-02-01 21:20 ` Russell King - ARM Linux admin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180604094241.GE9482@arm.com \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=rmk+kernel@armlinux.org.uk \
--cc=rnayak@codeaurora.org \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.