Partial cacheline flush problems on ARM and MIPS
Warner Losh
imp at bsdimp.com
Thu Aug 23 21:50:38 UTC 2012
On Aug 23, 2012, at 3:28 PM, Ian Lepore wrote:
> A recent innocuous change to the USB driver code caused intermittant
> errors in the umass(4) driver on ARM and MIPS platforms, and this
I think the proper solution is to segregate DMA and non-DMA parts of structures so that you don't have both sharing a cache line.
I also wonder why we don't allocate the DMA memory for these structures separately from the non-DMA parts. This would eliminate the USB_CACHE_BYTES kludge (which is CPU dependent, not arch dependent) and move the knowledge of this junk into busdma layer where it belongs. From my understanding of the issue, this would completely eliminate the problem forever!
Sharing a cacheline between something that is DMA aware and something that is just begging for trouble. We're doing more work than we need to to support this dubious feature and we'd be miles ahead if we could not share at all.
Warner
More information about the freebsd-arch
mailing list