Date: Thu, 4 Mar 2010 01:22:29 -0500 From: Alexander Kabaev <kabaev@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-mips@freebsd.org Subject: Re: Missing hack to resolve umass issues on RouterStation Pro Message-ID: <20100304012229.3bec1492@kan.dnsalias.net> In-Reply-To: <d763ac661003032153l73e89acat6357f8277a7552ac@mail.gmail.com> References: <20100303235333.794674a4@kan.dnsalias.net> <d763ac661003032153l73e89acat6357f8277a7552ac@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/HpDcetHcX6_L5nG/YTHl4qn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 4 Mar 2010 13:53:30 +0800 Adrian Chadd <adrian@freebsd.org> wrote: > On 4 March 2010 12:53, Alexander Kabaev <kabaev@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. >=20 > 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. :) >=20 > 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? >=20 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.=20 --=20 Alexander Kabaev --Sig_/HpDcetHcX6_L5nG/YTHl4qn Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iD8DBQFLj1GrQ6z1jMm+XZYRAt1BAJ404agCg6KUG0tFcWhwmPR8MVCfYACg54aN 8Q3p6A550IU3RaPorW5M/n8= =bBH7 -----END PGP SIGNATURE----- --Sig_/HpDcetHcX6_L5nG/YTHl4qn--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100304012229.3bec1492>