On Mon, Oct 18, 2010 at 5:03 PM, Shinya Kuribayashi <shinya.kuribayashi.px@xxxxxxxxxxx> wrote: > IIUC, the problem is that write operation originating from step 5. seems > to overtake the one originating from step 3., correct? Correct. This particular system makes no guarantees that data flushed out through CACHE operations will not overtake subsequent uncached stores. For the case of DMA, it is possible that data that I am attempting to send to a device (via DRAM) could still be in transit when dma_cache_wback() returns, and may be incomplete when the DMA operation starts. Or that dirty cachelines that I am attempting to "free up" for a DMA_FROM_DEVICE operation are still in transit when dma_cache_wback_inv() returns, potentially clobbering whatever data the peripheral is trying to write to memory. Adding SYNC at the end of dma_cache_wback* guarantees that the write buffers have been emptied out to DRAM and I do not have to worry anymore about any of these cases. > Then we'd like to know, what is that 'Caller mentioned at step 5.', and > what kind of operation will be done by the Caller? It is my recollection that the caller was the USB EHCI driver, and it was allocating some sort of uncached descriptor block that contained pointers. Sometimes those pointers got inexplicably zeroed out, and this is what we found to be the root cause.
