Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Aug 2012 19:51:02 -0400
From:      Alexander Kabaev <kabaev@gmail.com>
To:        Warner Losh <imp@bsdimp.com>
Cc:        freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org
Subject:   Re: Partial cacheline flush problems on ARM and MIPS
Message-ID:  <20120823195102.2dcc1fcc@kan.dyndns.org>
In-Reply-To: <3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com>
References:  <1345757300.27688.535.camel@revolution.hippie.lan> <3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/xAKsUfCFhIS7lv_PazDak7K
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

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

>=20
> 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
>=20
> 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.
>=20
> 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!
>=20
> 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.
>=20
> 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.

--=20
Alexander Kabaev

--Sig_/xAKsUfCFhIS7lv_PazDak7K
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iD8DBQFQNsHtQ6z1jMm+XZYRAqeaAJsE2dyZ0FISrcOVX3Je3YvLQ1MNZQCfcF+M
bBDN5eQWXQgUWXM3/UOthNI=
=mcBu
-----END PGP SIGNATURE-----

--Sig_/xAKsUfCFhIS7lv_PazDak7K--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120823195102.2dcc1fcc>