4.1.15. 754323: Repeated Store in the Same Cache Line Might Delay the Visibility of the Store
The Cortex* -A9 implements a small counter that ensures the external visibility of all stores in a finite amount of time, causing an eventual drain of the Merging Store Buffer. This counter is present to avoid a situation where written data could potentially remain indefinitely in the Store Buffer.
This Store Buffer has merging capabilities and continues to merge data as long as the write accesses are performed in the same cache line. The issue that causes this erratum is that the draining counter resets each time a new data merge is performed.
In the case when a code sequence loops and continues to write data in this same cache line, then the external visibility of the written data might not be ensured. A livelock situation might consequently occur if any external agent is relying on the visibility of the written data, and where the writing processor cannot be interrupted while doing its writing loop.
This erratum can only happen on Normal Memory regions. The following examples describe scenarios that might trigger this erratum:
- The processor continues incrementing a counter, writing the same word at the same address. The external agent (possibly the other processor) polls on this address, waiting for any update of the counter value to proceed. The Store Buffer continues merging the updated value of the counter in its cache line, so that the external agent never sees any updated value, possibly leading to livelock.
- The processor writes a value in a given word to indicate completion of its task, and then continues writing data in an adjacent word in the same cache line. The external agent continues to poll the first word memory location to check when the processor completes its task. The situation is the same in the first example, because the cache line might remain indefinitely in the merging Store Buffer, creating a possible livelock in the system.
This erratum might create performance issues, or worst case, a livelock scenario, if the external agent relies on the automatic visibility of the written data in a finite amount of time.
The recommended workaround for this erratum is to insert a DMB operation after the faulty write operation in code sequences that this erratum might affect to ensure the visibility of the written data to any external agent.
Did you find the information on this page useful?