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

[Ralf Baechle <ralf@oss.sgi.com>]

On Thu, Aug 01, 2002 at 06:05:17PM +0200, Maciej W. Rozycki wrote:

>  Huh?  Coherent caching mode can be used for a few processors only, namely
> R4[04]00MC and presumably SB1 (inferred from the sources), i.e. the ones
> that support the interprocessor coherency protocol.  If you know of any
> other processor that supports the protocol, I'd be pleased to see a
> reference to a spec -- I hoped someone, possibly you, would fill the
> missing bits when I proposed the patch a month ago.  Nobody bothered,
> though, sigh...

R10000.

>  I see your changes are broken conceptually, as the caching mode for the
> TLB should be inferred from the CPU configuration in the first place and
> not the system selection (actually it should be best selected ath the run
> time).  Hence I'd invert the flag, since most systems are non-coherent,
> and only permit it for certain processors.

Back in time I prefered CONFIG_NONCOHERENT_IO over CONFIG_COHERENT_IO
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.

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.

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

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

  Ralf