Arria® V SX and ST SoC Errata

ID 683370
Date 7/14/2015
Public
Document Table of Contents

1.2.1.26. 771225: Speculative Cacheable Reads to Aborting Memory Regions Clear the Internal Exclusive Monitor and May Lead to Livelock

Description

On the Cortex* -A9, when a cacheable read receives an external abort, the aborted line is allocated as invalid in the data cache, and any allocation in the data cache clears the internal exclusive monitor.

Therefore, if a program executes a LDREX/STREX loop that continues to receive an abort answer in the middle of the LDREX/STREX sequence, then the LDREX/STREX sequence never succeeds, leading to a possible processor livelock.

As an example, the following code sequence might exhibit this erratum:

loop LDREX
...
DSB
STREX
CMP
BNE loop
...
LDR (into aborting region)

The LDREX/STREX does not succeed on the first pass of the loop, the BNE is mispredicted, and the LDR afterward is speculatively executed.

Therefore the processor keeps on executing:

LDR to aborting region (this speculative LDR now appears “before” the LDREX & DSB)
LDREX
DSB
STREX

The LDR misses in L1 and never gets allocated as valid because it is aborting.

The LDREX executes and sets the exclusive monitor.

The DSB executes. It waits for the LDR to complete, which aborts, causing an allocation (as invalid) in the data cache, clearing the exclusive monitor. The STREX executes, but the exclusive monitor is now cleared, so the STREX fails. The BNE might be mispredicted again, therefore the LDR is speculatively executed again, and the code loops back on the same failing LDREX/STREX sequence.

This erratum happens in systems that might generate external aborts in answer to cacheable memory requests.

Impact

If the program reaches a stable state where the internal exclusive monitor continues to be cleared in the middle of the LDREX/STREX sequence, then the processor might encounter a livelock situation.

In practice, this scenario is very unlikely to happen because several conditions might prevent it:

  • Normal LDREX/STREX code sequences do not contain any DSB, so it is very unlikely that the system would return the abort answer precisely in the middle of the LDREX/STREX sequence on each iteration.
  • Some external irritants (for example, interrupts) might happen and cause timing changes that might exit the processor from its livelock situation.
  • Branch prediction is usually enabled, so the final branch in the loop is usually predicted correctly after a few iterations of the loop, preventing the speculative LDR from being issued, so that the next iteration of the LDREX/STREX sequence succeeds.

Workaround

For this erratum, either of the following workarounds fixes the problem:

  • Turn on the branch prediction.
  • Remove the DSB in the middle of the LDREX/STREX sequence. If a DSB is required, Arm* recommends that you place it before the LDREX/STREX sequence, and implement the LDREX/STREX sequence as recommended by the Arm* architecture.

Category

Category 3