The Linux 5.5 kernel due out as stable in early 2020 will finally have mainline support for the MIPS-powered SGI Octane and Octane II workstations that originally ran with SGI’s IRIX operating system about two decades ago.
There have been out-of-tree patches for running Linux on the SGI Octane MIPS-based systems while Linux 5.5 is set to finally have this support mainlined for these two decade old workstations should you still be running the hardware and looking for something else besides IRIX or support in other platforms like OpenBSD. Mind you, these workstations were already succeeded by the SGI Octane III a decade ago with Intel x86.
Better late than never.
Not familiar with Linux on MIPS, other than the PS2 fat with a hard drive. Wonder if any code from that was used for the Octane and Octane II support.
You’ve got it backwards but yeah… MIPS support is really old and has been in place for a decade this is just bringing to mainline patches that have been living out of tree and bitrotting for ages.
Also every other Router runs Linux + MIPS.
Thanks for the correction. Are there any smartphones using Android for MIPS?
MIPS android devices stalled out in 2012 or so as Ingenic didn’t release thier updated Xburst2 CPUs… and the Xburst1 CPUs have issues such as less than desireable PowerVR 540 GPUS… instead of Vivante which would have been in Xburst2.
You can still buy devices with Ingenic CPUs but they will be a bit dated in performance. Think cheapo chinese tablet…
It seems it only took 1500 lines of code in the kernel which is neat. Strikes me that probably doesn’t include GUI capability which, obviously lives outside the kernel; and even if standard(ish) GPUs from that era were used, it seems doubtful that they would still be supported on Linux.
Old kit is nice but the dream is not always so practical in use.
Rene Rebe commented that it does not include framebuffer support, but the patches for that exist and are planned to be merged also. And no it doesn’t live in userspace…. these framebuffers aren’t that complex and Linux doesn’t really support OpenGL on them anyway in hardware even though it could be possible.
How well is the graphics hardware supported?
Running Linux on an Octane certainly isn’t useful, and if there isn’t good support for the specialized graphics (and audio!) hardware, then it isn’t cool either.
Why would anyone ruin a classic SGI workstation to run Linux, even if everything was supported?
You know people say stupid crap like that about Solaris/Sparc and running Linux/Sparc… the fact is that Solaris is actually slower than Linux when not running bloatware because Linux implemented a ton of optimizations that Solaris never even considered. So for instance running Solaris 8 vs Redhat 6.2… Redhat just blows away Solaris in everything except where Solaris has some sort of accelerator support Redhat did not.
It’s a shame we can’t have unbloated software like back then… you didn’t need an ultra mega turbo optimizing compiler, to get useful work done, because the software wasn’t that complex.
Sparc is used in number-cruncher systems. Linux fits well in those. With an SGI workstation, the reason to have one is the refined nature of IRIX and the unique GPU.
cb88,
I’m curious, what exactly do you mean by this? Funnily enough, a performance comparison was posted to osnews many years ago:
https://www.osnews.com/story/16314/solaris-vs-linux-performance-on-a-sun-ultra-20/
The wayback machine still has the source data!
https://web.archive.org/web/20061107174646/http://www.geekpatrol.ca/blog/161/
He also tested windows.
As the comments back then pointed out, it doesn’t exactly test the OS itself, but rather the combination of OS+compiler, in this case Solaris+VStudio versus Linux+GCC. Nevertheless, this can be meaningful for those who end up using the native build tools on each respective platform, which I suspect is most people. It would have been interesting to see Solaris+GCC versus Linux+GCC to isolate the OS as the only variable. The geekbench tests focus mostly on algorithmic performance. This is not to say that the OS can’t have any impact on it, but geekbench tests are inadequate for thorough OS benchmarking.
Looks like this is an x86_64 arch comparison. Interesting, but not what the comment was talking about, which was SPARC…
vocivus,
True. I’m still curious about what specific optimizations linux is supposed to have over solaris on either platform. It needs to be elaborated!
If I remember correctly it was some call optimizations Linux does that make things calling into the kernel faster. Also I believe context switching was much faster on Linux than Solaris. Note these are OS level performance issues… that may be glossed over entirely by many benchmarks not designed to check for them even though they can have a massive effect on performance. Also, this is calling back to early Linux 2.2-2.6 era… things could have changed since.
Also you should only change one variable at a time, rather than kernel + compiler at the same time while doing such comparisons. So GCC on Solaris probably is slower than GCC code on Linux…. since you only swapped the Kernel and the kernel itself is faster (for some code anyway that interacts with the kernel alot).
Well, lets start with the fact that it’s some of the nicest MIPS hardware ever built. Yeah, there were other MIPS systems out there, but most of them were slower, with more limited options.
Add to that though that if the GPU and audio hardware are supported, you actually have an excellent platform for doing old-style CGI work.
—-
The thing is, almost any old system can have some use found for it, even if it’s just having an actual usable system. Up until recently when I got tired of paying the power bills for it, I had an old HP 9000 E series server that I was still running Linux on despite having zero support for much other than the CPU, NIC, and serial terminal. The PA-RISC ISA has a rather neat feature in that you can force the FPU to use any of the IEEE 754 rounding modes, so you can easily use it to test algorithmic stability of FP code, which is exactly what I was using it for.
How many of them are still laying around in some animation studio collecting dust along with SUN (beige) Sparc workstations? I personally dont see a strong userbase for such proprietary niche hardware.
It’s never about practicality. You wouldn’t be wrong to point out all the ways that it isn’t practical (from low performance, high operating costs, bad component availability, etc), but what it really comes down to is simply that some people are emotionally attached to legacy hardware and take pride in getting it to work. It’s the same thing with the BSDs that insist on continuing to support esoteric architectures.
Hi Thom,
The Octane-III bares absolutely *ZERO* relationship to the original Octane/Octane-II. Wrong ISA, by that stage different company had taken over SGI (hint..they changed the sgi logo to resemble a washing detergent logo.. *ahem*). Not worth mentioning the Octane-III in the same breath as the -III was a bunch of off the shelf x86 super-micro boards running linux, rather than MIPS running IRIX. Different non-crossbar switch architecture also. Just.. yeah no.
To the Solaris slammers. Anything running RHEL6.x .. on the hardware of the day, if you had a job that required large datasets, then the SPARC64/SPARC’s from Fujitsu/SUN of the day could actually move enough data off the enterprise storage arrays to keep the processors fed. Whilst they were faster than the 32bit x86 systems of the day.. lets say not by much purely to satisfy pundits because benchmarking is ugly (and I can’t be bothered for this argument) .. the x86 junk wasn’t much use when you needed I/O that wasn’t supported by the same ATA33/66 HDD you’d find in mum’s web browsing machine in the kitchen she looked up recipes on. Same goes to the IBM and HP gear of the day. If you needed serious processing and I/O throughput and UNIX, you were on big iron or making things up.
The x86 stuff has though in the last decade improved and it even scales a lot better now.