Date: Fri, 28 Oct 2011 10:07:47 -0600 From: Warner Losh <imp@bsdimp.com> To: Adrian Chadd <adrian@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org Subject: Re: newbus IO ordering semantics - moving forward Message-ID: <34E9F112-930C-4836-9949-FA8A01763969@bsdimp.com> In-Reply-To: <CAJ-Vmom1M46dxby_aRYBT_FMWG5xN3kXdH-gahyrqWcBxtVyMA@mail.gmail.com> References: <CAJ-VmonFJG3xLn2JvarOUN6o-e7MC%2BA%2B=W9_vocZqY6L3CmTmQ@mail.gmail.com> <20111028073710.GP25601@funkthat.com> <CAJ-Vmom1M46dxby_aRYBT_FMWG5xN3kXdH-gahyrqWcBxtVyMA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 28, 2011, at 7:07 AM, Adrian Chadd wrote: > On 28 October 2011 15:37, John-Mark Gurney <jmg@funkthat.com> wrote: >>> I'd appreciate some feedback/comments before I go off and code all = of this up. >>=20 >> I think we should complain about the drivers that are NOT using the >> lazy/loose semantics as those are the drivers that are slower than >> they should be, and/or not written properly. Complaining about = properly >> written drivers that use the lazy/loose semantics when they get = updated >> to be correct is wrong... >=20 > Right. My point though is that I'm not sure of how many drivers have > been tested outside of i386/amd64. Marcus's response is helpful, > indicating that the sparc64 guys have tested a lot of this. Yes, the > barrier calls are expensive and yes, drivers on i386/amd64 still need > to do bus_dmamap_sync() calls. >=20 > I can only speak from my limited experience here after tracking down > that ath/ath_hal bug. My experience is that ath(4) triggered on PPC > because of a loop which read the same register a few times. I recall > seeing an ethernet driver recently have a commit which also did this. > I'm happy to do the reverse. Ie, on platforms where it matters, add a > warning printf (in verbose boot) when drivers aren't indicating > they've been fully tested. Or, I'm happy to completely ignore the > situation. :) I would have thought that multiple reads to the same location to an = uncached location wouldn't be a problem. Perhaps you can share how that = didn't work. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34E9F112-930C-4836-9949-FA8A01763969>