Under very rare circumstances, some ACP requests in hazard with multiple full cache line writes by the CPUs can cause arbitration issues in the SCU leading to processor deadlock. For the condition to occur, the CPUs must be operating in SMP mode and on a coherent memory region while one CPU writes a cache line at approximately the same time as the other CPU is reading the same cache line and the ACP has also issued a request to the cache line.
The issue affects SMP systems and is very improbable because the timing window is very small and the three requests all center around one cache line. If the condition cannot be avoided in the operating system, then a control bit can be set so the problem does not occur.
Minor. Not expected to occur. See Impact Details below for additional information.
A software work-around is available, see Work-around Details below for more information.
Systems that use the ACP port and both ARM processors in SMP mode.
|Device Revision(s) Affected:|
All. No plan to fix. Refer to (Xilinx Answer 47916) - Zynq-7000 AP SoC Silicon Revision Differences.
Under very rare circumstances, some ACP requests in hazard with full cache line writes from two processors can cause arbitration issues in the SCU leading to processor deadlock.
The issue is encountered when the two processors work in SMP mode and on coherent memory regions (Write-Back Shared). The two processors need to perform full cache line writes, and the ACP needs to perform coherent requests which are in hazard with some of the processor requests.
The example below describes one scenario which could lead to the deadlock:
CPU0 performs a full cache line write at address A (this write is in hazard in the SCU, indicating that the other CPU or the ACP is already performing an access to this cache line).
CPU0 then performs a full cache line write at address B.
CPU0 then performs a read request at address C (this read is in hazard in the SCU with the 2nd request from CPU1 mentioned below).
And at approximately at the same time:
CPU1 performs a full cache line write at address D (this write is in hazard in the SCU, indicating that the other CPU or the ACP is already performing an access to this cache line)
CPU1 performs a full cache line write at address C
CPU1 performs a read request at address B (this read is in hazard in the SCU with the 2nd request from CPU0 mentioned above)
The ACP performs a read or write request at address B (this request is in hazard with the 3rd request from CPU1)
In this scenario, under extremely rare conditions, all requesters (CPU0, CPU1, and the ACP) might eventually end up in hazard. The pseudo round-robin arbitration in the SCU might finally remain stuck on the ACP, so that neither CPU, nor ACP request can make forward progress, leading to system deadlock.
The impact is minor. When it happens, the issue leads to system deadlock. It is important to note that the scenario leading to this deadlock is very uncommon: it requires both processors writing full coherent cache lines, without taking any semaphore, along with the ACP accessing the same lines; meaning that these latter accesses are not deterministic. This, on top of the extreme rareness of the micro-architectural timing conditions under which the defect can happen, explains why the issue is not expected to cause any significant malfunction in a real system.
A software work-around is available for this problem by setting bit 21 of the undocumented Diagnostic Control register placed in CP15 c15 0 c0 1.
The bit can be written in Secure state only, with the following Read/Modify/Write code sequence:
When this bit is set, the direct eviction optimization in the Bus Interface Unit is disabled, which prevents the failure to happen.
Setting this bit might prevent the processor to utilize the full bandwidth when performing intensive traffic of full cache line writes, and a slight performance drop might be visible in the system.
Note that the failure cannot happen if any of the two following bit is already set in the undocumented Diagnostic Control register:
bit 23 Disable Read-Allocate mode
bit 22 Disable Write Allocate Wait mode