* IP27 (Origin) family:*
o Origin 200. Dual-Origin 200 systems using the CRAYlink connection should work, but currently limited to the first node.
o Origin 2000 and Onyx 2 have not been tested, but should work, currently limited to the first node.
* IP30 (Octane a.k.a Speedracer) family:*
o Octane
o Octane 2
* IP32 (O2 a.k.a Moosehead) family:
o O2
o O2+
R5000, RM5200, RM7000 as well as R10000 and R12000 processors are supported. RM7000 level 3 cache is supported.
* IP35 (Tezro) family:*
o Fuel
o Origin 300, Onyx 300 and Origin 3000 have not been tested, but should work, currently limited to the first node.
o Origin 350, Onyx 350, Onyx 4 and Tezro have not been tested, and are not supported yet due to lack of support for their PCI-X controller.

* support for these families has been added after the 4.5 release.

here i have a fuel R16K loaded with irix, what is the status of the linux kernel about this machine ?

also, the O2-R12K is known as "less than 20seconds working from the bootstrap till the panic" machine, but it is now reported in the supported openBSD machines ... so what is the status of the linux kernel about this O2/R12K ?

anyway it seems *bsd guys have success, i have to verify by myself
(just asking my friend if he could let me try his fuel - R16-700Mhz with net/open/whatever-BSD)

My O2-R5k was nice under Linux as well. Don't remember the kernel. Sadly, the Motherboard seems to have expired. My point was that I've only got Octanes left, which are not fun under Linux (bootloader issues). I might check out OpenBSD on one of them, since OpenBSD claims to support them now.

It is a shame that MIPS hardware is expensive to acquire, given the age of it.

Linux on R10000/R12000 on O2 is tricky for a few reasons. The OpenBSD people worked around the issue because the OpenBSD memory code is a lot simpler, and some of the solutions that worked for the R10K issue on IP28 systems were easily adapted to this machine (I believe). Linux has a much more complex memory system, because of the various layers you have to allow the code base to build on as many different systems, architectures, and configurations as Linux is capable of these days, and the only two known ideas that might work, one of which has been tested somewhat, are:

- The same approach to IP28, where we use the R10K cache barriers capability available in GCC 4.4 to protect the code from the speculative execution issue present in these systems/CPU combinations.
- Leverage a feature only available on R12000 O2 systems called "Juice", which lets the CPU avoid this issue. I believe the knowledge needed to implement this completely is still locked away in lost/forgotten SGI internal documentation, but you can find references to it in the last known updated copies of the NEC MIPS Vr10000 processor manual, of which the R12000 is a member of.

I believe the approach the OpenBSD people took was the first, and because of the simpler nature of their distribution, writing up the needed cache support code was fairly easy for them I believe. I think for Linux, we'd have to model the IP28, protecting the network driver and SCSI drivers at minimum from the speculative execution issue, and that's not very easy to do, especially with a common driver that changes a lot like the aic7xxx used in O2 systems.

Octane:
I last played with this in 2.6.30-rcX, and was able to restore SMP support, but could not boot into user land. The INIT process segfaults as soon as it is executed, and I haven't had a lot of time to get back to it and try to figure out what's wrong. I currently have no time table on when I'll be able to get back to it either, so this machine is pretty much dead for the time being.

IP35-based hardware (Including Origin 300, 3000, Fuel, and Tezro):
There was some work done on booting Linux on the core hardware of this line, the Origin 300 system. If one pokes into the Linux MIPS Git repo, you'll find a tag in there for IP35 code. The catch, this code only boots the kernel. No userland support is available yet, and networking is dead because Ralf Baechle, who runs the Linux/MIPS port in the kernel itself, hasn't had a lot of luck decoding the MAC Address out of the EEPROM chip that these systems use. If Origin 300 can get up and running, it's theoretically possible that the other systems, Fuel especially, could be usable if someone had the hardware. Tezro might be tricky, as it's a pretty complex machine, but Origin 3000 support is unknown due to the scalability of those systems. Anyone whose ever tried getting Linux to play nice on old Origin 2000 hardware knows how difficult those systems can be to work right on Linux.

Not to mention the difficulty of finding these systems on eBay or such. The reseller market has a very high demand for old SGI equipment, which puts it out of reach of hobbyists who just want to hack on it for fun._________________"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic

- Leverage a feature only available on R12000 O2 systems called "Juice", which lets the CPU avoid this issue. I believe the knowledge needed to implement this completely is still locked away in lost/forgotten SGI internal documentation, but you can find references to it in the last known updated copies of the NEC MIPS Vr10000 processor manual, of which the R12000 is a member of.

umm what is Juice ? a special motherboard of O2 ?
if so, in what it differs ?

here I have
* R12K-400Mhz O2 cpu module
* R5K O2 motherboard, in where i could plug the R12K module cause i have the "adapter kit" (just mechanical stuff, nothing special, nothing of electronic, i mean)