Partial cacheline flush problems on ARM and MIPS

[Alexander Kabaev]

On Thu, 23 Aug 2012 15:50:35 -0600
Warner Losh <imp at bsdimp.com> wrote:

> 
> 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

I agree with Warner that this should be addressed at busdma level. When
asked for DMA buffer, it should contrain its start address size to the
cache line boundary. USB is insane allocating DMA buffers inside of own
transfer structure and that was stated on a more than one occasion
already. Since USB code refused to budge, we came with a horrible
USB_CACHE_BYTES hack as as _temporary_ workaround.

-- 
Alexander Kabaev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20120823/088989de/signature.pgp