[Top] [All Lists]

Re: [update] [patch] linux: Cache coherency fixes

To: Ralf Baechle <>
Subject: Re: [update] [patch] linux: Cache coherency fixes
From: "Maciej W. Rozycki" <>
Date: Thu, 1 Aug 2002 19:14:05 +0200 (MET DST)
In-reply-to: <>
Organization: Technical University of Gdansk
On Thu, 1 Aug 2002, Ralf Baechle wrote:

> R10000.

 OK.  Any specs anywhere?

> because the noncoherent case needs additional code and in general I'm
> trying to reduce the number of the #if !defined conditionals for easier
> readability.

 Hmm, what's wrong with "#ifndef"?  Not much less readable than "#ifdef",

> The R10000 is our standard example why looking at the processor type doesn't
> work.  It's used in coherent mode in IP27 but in coherent mode but in
> coherent mode in IP28 or IP32.  Otoh I don't know of any system that
> supports coherency but also is being used with non-coherent processors.

 Yep, I suppose so, but the first criterion should be the CPU anyway.

1. Does the CPU support coherency?

2. If so, does the system?

I'm going to express it this way in the config script.

> >  Using a non-coherent
> > configuration for an UP system that supports coherency (do SGI IP27 and
> > SiByte SB1250 have another agent in the chipset that may issue coherent
> > requests regardless of the number of processors started?)
> Yes.  That's how coherency is working - all agents have to support coherent
> requests or coherency simply won't work.  So basically we'd be trully
> picky we'd have to verify that all agents, processor and other support
> coherency but just using the system type seems to be sufficient.

 Well, inferring from docs and my experience it's not needed.  A system
may simply require areas used for DMA to be marked as non-coherent by
CPUs.  Often uncached accesses are used to prevent spoiling the caches

> > results in a
> > performance hit only due to superfluous invalidations, but using a
> > coherent configuration for a processor/system that doesn't support it may
> > lead to a hard to debug hang with no apparent reason (as I wrote
> > previously, even NMI/Reset stopped working on my system -- I had to hit
> > the power switch). 
> Using a non-coherent mode on IP27 may result in nice, hard to trackdown bus
> errors.

 Weird, but I accept it as a fact.  Still a bus error expresses more than
a hang. ;-) 

+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail:, PGP key available        +

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