- 18.104.22.168. 782772: Speculative Execution of LDREX or STREX Instruction After a Write to Strongly Ordered Memory Might Lead to Deadlock
- 22.214.171.124. 761320: Full Cache Line Writes to the Same Memory Region From Both Processors Might Cause Deadlock
- 126.96.36.199. 845369: Under Very Rare Timing Circumstances Transition into Streaming Mode Might Create Data Corruption
- 188.8.131.52. 751476: Missed Watchpoint on the Second Part of an Unaligned Access Crossing a Page Boundary
- 184.108.40.206. 782773: Updating a Translation Entry to Move a Page Mapping Might Erroneously Cause an Unexpected Translation Fault
- 220.127.116.11. 794072: A Short Loop Including DMB Instruction Might Cause a Denial of Service When the Other Processor Executes a CP15 Broadcast Operation
- 18.104.22.168. 794073: Speculative Instruction Fetches with MMU Disabled Might Not Comply with Architectural Requirements
- 22.214.171.124. 794074: A Write Request to an Uncacheable, Shareable Normal Memory Region Might be Executed Twice, Possibly Causing a Software Synchronization Issue
- 126.96.36.199. 729818: In Debug State, the Next Instruction is Stalled When the SDABORT Flag is Set Instead of Being Discarded
- 188.8.131.52. 757119: Some Unallocated Memory Hint Instructions Generate an UNDEFINED Exception Instead of Being Treated as a NOP
- 184.108.40.206. 771221: PLD Instructions Might Allocate Data in the Data Cache Regardless of the Cache Enable Bit Value
- 220.127.116.11. 771224: Visibility of Debug Enable Access Rights to Enable/Disable Tracking is Not Ensured by an ISB
- 18.104.22.168. 771225: Speculative Cacheable Reads to Aborting Memory Regions Clear the Internal Exclusive Monitor and May Lead to Livelock
- 22.214.171.124. 775419: PMU Event 0x0A Might Count Twice the LDM PC ^ Instruction with Base Address Register Write-Back
126.96.36.199. 771225: Speculative Cacheable Reads to Aborting Memory Regions Clear the Internal Exclusive Monitor and May Lead to Livelock
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.
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.
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.
Did you find the information on this page useful?