[Top] [All Lists]

Re: [patch] linux 2.4.17: The second mb() rework (final)

Subject: Re: [patch] linux 2.4.17: The second mb() rework (final)
From: Atsushi Nemoto <>
Date: Thu, 21 Feb 2002 21:00:52 +0900 (JST)
In-reply-to: <>
Organization: TOSHIBA Personal Computer System Corporation
References: <> <>
>>>>> On Fri, 15 Feb 2002 20:39:09 +0100 (MET), "Maciej W. Rozycki" 
>>>>> <> said:
macro>  Well, the "classic" MIPS R2020 and R3220 ones would break PCI
macro> (or actually any I/O) ordering semantics as they return data
macro> from a posted write upon a hit.  The affected read never
macro> appears at the I/O bus in that case.  They never reorder writes
macro> though, as they work as FIFOs (the former is four stage deep
macro> and the latter is six stage deep), so wmb() may be null for
macro> them.

macro>  I've read a suggestion a "bc0f" might be needed for the TX39's
macro> write buffer as a barrier.  That means the buffer behaves as
macro> the "classic" ones.

As I wrote in another mail, TX39's uncached load does NOT return data
from a write buffer.  Uncached load/store always appears on I/O bus in
same order.

The problem of TX39's write buffer is that cached load/store operation
can overtake preceding uncached store operation (even if "SYNC" was
exist between these operations).

Atsushi Nemoto

<Prev in Thread] Current Thread [Next in Thread>