Missing hack to resolve umass issues on RouterStation Pro

Alexander Kabaev kabaev at gmail.com
Thu Mar 4 06:22:43 UTC 2010

On Thu, 4 Mar 2010 13:53:30 +0800
Adrian Chadd <adrian at freebsd.org> wrote:

> On 4 March 2010 12:53, Alexander Kabaev <kabaev at gmail.com> wrote:
> > Hi,
> >
> > in order to fix issues with umass on RouterStation Pro, I had to
> > fix/hack the kenel in two places. One was related in the way we
> > handled partial cache line invaidations and I committed it to
> > -current already as http://svn.freebsd.org/changeset/base/203080.
> >
> > Another one is a hack that is not suitable for inclusion into
> > official sources, but still is good enough to get RouterStation Pro
> > to work reliably. Get it from here:
> >
> > http://people.freebsd.org/~kan/usb_rspro.diff
> >
> > I would appreciate if people who still have issues getting their
> > USB-attached storage working reliably with RSPro can test it and
> > report success/failure.
> It works fine for me. I do see occasional segfault-on-exec which I
> wonder whether is due to USB or VM/TLB magic; this smells somewhat
> like it could be both. I'll have to re-test things on an NFS root (and
> hope there's not MIPS/rspro-y issues with the NFS and NIC code. :)
> Is this USB alignment patch something that is needed for all MIPS/USB
> stuff, or just this specific SoC. If so, why? And will it potentially
> be an issue with other SoCs?

This alignment hack is required for all MIPS or non-MIPS platforms
that do not have cache coherent DMA. Our existing USB code allocates
buffer used for DMA transfer that shares cache lines with other
structures and write accesses to these structures can easily interfere
with in-progress DMA transfers by uncontrollably re-dirtying and
by the CPU flushing the cache line out. My hack just uses brute
force to align the buffer start and end to 32, which happens to be the
cache line size on RSPro. If other SOCs use different cache geometry,
they should use their cache line size there instead.

The proper fix is to make USB stack aware of cache line sizes and
unfortunate effects of cache line sharing. 

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-mips/attachments/20100304/1cec7dc2/signature.pgp

More information about the freebsd-mips mailing list