On Fri, 2004-06-18 at 16:41, Alan Stern wrote:

On Fri, 18 Jun 2004, Benjamin Herrenschmidt wrote:

quoted

I think it's more likely we are dealing with an ordering issue of
accesses to memory vs. mmio, those aren't order unless you use memory
barriers. Actually, it's worse, you need a full mb() to order them,
which is why lately, we made ppc64 writeX() do full sync's ... that sucks
but it's near to impossible to get an abstract IO API that would cover
our needs here and still make other archs happy it seems...

I recently changed a few mb() calls to wmb(), because they only protected
data the CPU was writing to be read by the device.  Do you think changing
all the wmb()'s back to mb()'s would make a difference?

(Actually it seems likely that this is _not_ directly related to the
original problem, but it might be important anyway.)

Well, the problem on ppc is that the eieio done by wmb() (or implicitely
done by all writeX IO accessors) will only order stores in the same
domain. That is cacheable aren't ordered vs. non cacheables.

For example, write to a descriptor in memory, then writel() to your
device, that isn't guaranteed to happen in order.

In this case, you indeed need an mb(), but that's a ppc thing and the
race on ppc32 CPUs is quite small (though ppc64, typically POWER4 and
POWER5, will eat you for lunch with their multiple deep store queues).

Ben


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/