linux-mips
[Top] [All Lists]

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

To: "Kevin D. Kissell" <kevink@mips.com>
Subject: Re: [patch] linux 2.4.17: The second mb() rework (final)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Fri, 15 Feb 2002 14:17:30 +0100 (MET)
Cc: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>, mdharm@momenco.com, ralf@uni-koblenz.de, linux-mips@fnet.fr, linux-mips@oss.sgi.com
In-reply-to: <008601c1b61e$ff4d88b0$10eca8c0@grendel>
Organization: Technical University of Gdansk
Sender: owner-linux-mips@oss.sgi.com
On Fri, 15 Feb 2002, Kevin D. Kissell wrote:

> >  The code is not correct if "bc0f" is needed to be sure a write-back
> > happened.  If that is the case, the processors need their own wbflush() 
> > implementation like R2k/R3k configurations in older DECstations. 
> 
> Note that I did not say that "the code is correct", only that it
> is correct *in considering the TX39 to be effectively SYNC-less*.

 Then you are probably misinterpreting CONFIG_CPU_HAS_SYNC (shame on me
for not documenting it at all).  It means a CPU has the "sync" 
instruction but it does not imply a "sync" is sufficient for mb() on the
CPU.  See the code in include/asm-mips/system.h in my patch.  If
CONFIG_CPU_HAS_WB is set wbflush() is executed for mb() regardless the
setting of CONFIG_CPU_HAS_SYNC.  Fast_mb() is set to a "sync" in case a
wbflush() implementation needs it for something -- the DECstation's
wbflush() actually uses it in a patch I have queued waiting for my
pending submissions to be applied by Ralf.

> I'm sure that the code is anyway broken six ways from Wednesday,
> as usual.  ;-)

 I hope with my fixes the number of ways decreases, though. ;-) 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


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