newbus IO ordering semantics - moving forward
jmg at funkthat.com
Fri Oct 28 17:48:42 UTC 2011
Adrian Chadd wrote this message on Fri, Oct 28, 2011 at 21:07 +0800:
> On 28 October 2011 15:37, John-Mark Gurney <jmg at funkthat.com> wrote:
> >> I'd appreciate some feedback/comments before I go off and code all of this 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. Complaining about properly
> > 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. :)
How about when we have debugging turned on (i.e. -current) we warn on
all platforms for drivers that aren't "correct", and then on -releases
we only warn on platforms that it maters on?
That gives developers encouragement to fix their bugs, but also lets
users on these alternate platforms know that if something isn't working,
it's possibly a driver bug...
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
More information about the freebsd-arch