Re: SGI MIPS, Speculative Execution issue

[DiTBho Down in The Bunny hole <downinthebunnyhole%gmail.com@localhost>]

>  For UP it means that there is no bus snooping implemented in the CPU to
> support DMA bus masters.  Consequently DMA reads will supply data from RAM
> regardless if there's dirty data in the CPU's cache for the corresponding
> location and DMA writes will update data in RAM only regardless if there's
> corresponding data (dirty or clean) in the CPU's cache.
>
>  So you need to synchronise RAM with the CPU's cache by hand via software
> means for the affected memory area ahead of any DMA transfer, normally by
> issuing write-back and invalidate requests for the relevant cache lines
> (the MIPS architecture has suitable CPU machine instructions for this
> purpose).
>
>  In a cache-coherent system this is resolved transparently by hardware and
> such synchronisation happens automatically.

Thanks for the clarification =)

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

I found these (2) lines in the Linux kernel. Interesting.

Do NetBSD and OpenBSD work on O2/R10K?

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.
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 }.
R5K belongs to the MIPS3 class, and it's not superscalar.

(1) Post to NetBSD sgimips Mailing List on 29 Jun 2000
http://mail-index.netbsd.org/port-sgimips/2000/06/29/0006.html

(2) https://github.com/torvalds/linux/blob/master/arch/mips/mm/dma-noncoherent.c