Date: Fri, 28 Oct 2011 21:07:44 +0800 From: Adrian Chadd <adrian@freebsd.org> To: Adrian Chadd <adrian@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: newbus IO ordering semantics - moving forward Message-ID: <CAJ-Vmom1M46dxby_aRYBT_FMWG5xN3kXdH-gahyrqWcBxtVyMA@mail.gmail.com> In-Reply-To: <20111028073710.GP25601@funkthat.com> References: <CAJ-VmonFJG3xLn2JvarOUN6o-e7MC%2BA%2B=W9_vocZqY6L3CmTmQ@mail.gmail.com> <20111028073710.GP25601@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 th= is up. > > 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. =A0Complaining about properl= y > written drivers that use the lazy/loose semantics when they get updated > to be correct is wrong... 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. 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. :) Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmom1M46dxby_aRYBT_FMWG5xN3kXdH-gahyrqWcBxtVyMA>