Re: SGI MIPS, Speculative Execution issue

["Maciej W. Rozycki" <macro%orcam.me.uk@localhost>]

On Sun, 27 Oct 2024, DiTBho Down in The Bunny hole wrote:

> >  In a cache-coherent system this is resolved transparently by hardware and
> > such synchronisation happens automatically.
> 
> Thanks for the clarification =)

 You are welcome.

> I wonder why the linux kernel perfectly runs on an O2/R5K, while it
> crashes in less than 10 seconds from boot on an O2/R10K?

 I think MIPS/Linux matters will best be discussed at 
<linux-mips%vger.kernel.org@localhost>.  There are people there who have experience 
with running Linux on SGI hardware there (I don't).

> If we assume that it is the CPU that does not implement any
> cache-coherency mechanism, then why does Linux kernel run perfectly on
> an Octane/R10K?

 A hardware workaround may have been implemented in a later system, or a 
later stepping of the CPU may have the erratum fixed.  Also the crash may 
be unrelated.  You may have to debug it yourself.

> Do NetBSD and OpenBSD work on O2/R10K?

 I'll leave answers to this question to the others; I don't know.

> I think (my speculation) the hw-mechanism, it implemented, is external
> to the CPU, but there is more that is not yet clear to me.

 In the R4k and R10k architecture coherency logic is on-chip of all the 
participating agents, both CPU(s) and DMA masters.  See the diagrams in 
the respective processor manuals for an overview.

> The post(1) on the mailing list talks about a problem specifically
> related to the speculatively execution of loads and stores on a
> superscalar MIPS4 CPU { R10K, R12K, R14K, R16K }.

 There is a section on this erratum in the R10k manual, section 1.7, pp. 
21-25.  I suggest that you read it, it may help debugging the problem.

> R5K belongs to the MIPS3 class, and it's not superscalar.

 The R5k is actually a MIPS IV CPU.  And it's dual-issue (between CPU and 
FPU instructions).  It doesn't implement speculative execution or coherent 
operation though.

  Maciej