newbus IO ordering semantics - moving forward

Warner Losh imp at bsdimp.com
Fri Oct 28 16:09:15 UTC 2011


On Oct 28, 2011, at 7:07 AM, Adrian Chadd wrote:

> 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. :)

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



More information about the freebsd-arch mailing list