[vishnu]

SGI basically invented symmetric multiprocessing, which they subsequently open sourced, the symmetric multiprocessing code in the Linux kernel is based on SGI's open source release.

[weblacky]

I would definitely need to see a reference for the Linux kernel. The last time I saw a clustering single system image in Linux it was a hack from the 2.2 kernel in the late 90s. SMP support has been on Linux for nearly ever. I don't known about NUMA.

I've drooled over being able to put together a single system image Linux cluster for years, I've never seen it done with a modern kernel. I've seen attempts that got close, but they didn't even have process migration, the processes would be stuck on whatever nodes they were initially launched on and didn't support checkpoints & restores.

If I could grow a blade system with Infiniband or something to be single system image I'd be wanting to do that right now.

[vishnu]

I just did a quick check on the Linux kernel source code, SGI is referenced 409 times.

[weblacky]

Okay?...... That's not what your point was above??? I never refuted that SGI didn't contribute to Linux. I asked for hard evidence that SGI specifically contributed to the subsystems I was talking about. You specifically mentioned SMP and I was talking about single system image clustering. I would need you to please provide information claiming that SGI added either to Linux. Because Linux had SMP support well before SGI got involved with them, I was using it back in the 2.2 days, and according to Google sources it was added in 1996 at the 2.0 kernel

But SGI also contributed file systems and other things to Linux because they actively used that stuff... Firmware interfaces, bus architectures, graphic systems.  Of course SGI references would be all over Linux for those systems.

This article seems to imply that Linus himself wrote SMP support in Linux: https://www.linuxjournal.com/article/3515

Please provide sources that SGI added SMP support into the Linux kernel and more succinctly please provide a reference that Linux supports single system image clustering because I would absolutely love that I have been waiting over 25 years for it...

[Raion]

Let's not scare off the newcomer guys. The majority of references to SGI code in the Linux kernel are from the late 2.4 to early 2.6 era. Most are related to the incorporation of XFS. I am not sure of the theory that early Linux is related to IRIX, knock on wood. This is because the two are very different internally, and afaict, things do not just "drop in" on one or the other.

[weblacky]

Yo,
Totally willing to admit that SGI added stuff to Linux, I just don't see that any of that was the topics (SSI or/and SMP) that were claimed in the initial aside. Anyone with any evidence is welcome to introduce it to me and we can talk on a separate thread. I'm fine with dropping it.

[jander31]

In terms of what's actually good, the prom performs a fairly quick diagnostic of most things, including your graphics memory, before you should see the graphical interface. There is a much more rigorous PROM diagnostic called factory diagnostic that you can enable with virtual switches but that's usually not really required. I would personally say that if you get to the PROM graphical interface and go to the terminal and type: hinv

And get a good hardware listing and things look like what they're supposed to be that I would assume you're good until you hit a problem. The only problem I would expect you to ever hit is either that you have a flaky memory module or that your power supply is so old that it's nearing failure and you'll wind up with very odd VRM dips and other power related alerts and warnings. Outside of those two things I wouldn't expect anything odd. I would however say that when you load Irix it naturally resets a lot of your boot params, so that tends to clear out any weird stuff that people do. But overall I would trust the PROM diagnostics 98% of the time.

basic starter info:
https://archive.irixnet.org/apocrypha/ne...376/1.html
https://web.archive.org/web/201603251532...er_Updates
https://forums.irixnet.org/thread-4032-p...l#pid29516

user Jwhat has a nice archive of this stuff, I should have a copy somewhere, of all the PROM versions and all the flashers that you would need as each ProM bin file only works in a certain flasher version, it's a problem.  So if you're L1 and PROM are very old, fix it first and then once you get Irix running you'll need to upgrade whatever's left. You have to chain load the bin files to the right flasher versions as you go. But you can do so within the same Irix version as long if it's a later version like 6.5.30.  I've done this once.  On your platform the serial number will sometimes disappear during flashing. Make sure to write down your serial number before flashing, it's usually easy to add it back in.

This should all have what you need for now. Good luck and let us know.

---

NOTE: Oh, so when you turn off the ENV you will be turning it off!  You turn it back on by doing the opposite command and use the word "on" instead of "off".  So assume all commands are "sticky" unless told otherwise.

Thank you for the information, here is the PROM output when I entered "hinv":

1) Start System
2) Install System Software
3) Run Diagnostics
4) Recover System
5) Enter Command Monitor

Option? 5
Command Monitor.  Type "exit" to return to the menu.
>> hinv
System  SGI-IP35
2 500 MHz IP35 Processors
Main memory size: 1024 Mbytes
Integral Fast Ethernet
IOC3 serial port
USB (OHCI interface)
Integral SCSI controller 0: Version Qlogic 12160
    Disk drive: unit 1 on SCSI Controller 0, (dksc(0,1,0))
Integral SCSI controller 1: Version Qlogic 12160

______________________________
Also I was curious about the IP, for when I get in the fans (I ended up getting a bundle of 8, in the event more of the fans die in the future).  Here's the printenv output:

>> printenv
AutoLoad=No
root=dks0d1s0
netmask=255.255.255.0
nonstop=0
rbaud=19200
SystemPartition=dksc(0,1,8)
OSLoadPartition=dksc(0,1,0)
OSLoader=sash
OSLoadFilename=unix
TimeZone=PST8PDT
console=d
oldConsolePath=/hw/module/001c01/iobrick
gConsoleIn=default
gConsoleOut=default
diskless=0
scsihostid=00
ProbeAllScsi=n
RestorePartEnv=y
dbaud=9600
volume=80
sgilogo=y
netaddr=192.0.2.1
AutoPROMVars=0
cpufreq=500
dbgname=
dbgtty=/dev/tty/hubtty0
ConsolePath=/hw/module/001c01/iobrick
ConsoleOut=/dev/tty/hubtty0
ConsoleIn=/dev/tty/hubtty0

__________________________________
How would I go about setting a usable IP address within the Origin?  I know I wouldn't be configuring my Cisco Catalyst, as it appears the Origin hasn't set itself a usable IP.

Thank you again!

Edit: For some reason, it won't let me go back to L1. Every time I press Ctrl + T, it lasts only for a single command before it says "returning to console mode 001c01 console, <CTRL_T> to escape to L1." Why is this? The command to permanently go back to L1 is 11, and it won't stick:

returning to console mode 001c01 console, <CTRL_T> to escape to L1

escaping to L1 system controller
001c01-L1>11
ERROR: command not found.

returning to console mode 001c01 console, <CTRL_T> to escape to L1

[vishnu]

All of the original SMP support in the Linux kernel came from SGI. If you look at the Linux kernel mailing list from back then, Linus himself said many times that Linux would never support more than one processor. When SGI started contributing code to the kernel, Linus complained vociferously about the code structure, but he incorporated it into the kernel nonetheless.

[weblacky]

So this is a little bit out of my wheelhouse, I always use manual CDROM loading on my stuff just because I have many external SCSI CD/DVD drives and my network is not hybridized to properly set up for loading or automation of Irix installs (eventually).

Most old stations use BOOTP instead of DHCP at the PROM to autoconfig anything. There are of course PROM commands to set a static IP address as well as a file location if you're doing network based BOOTP file fetching.

If you're using the LOVE utility to do network installs, read here: https://github.com/ColinLaws/love

Just so you're aware while SGI did support network installs the machines generally did not anticipate needing network at their firmware level or much during boot. The actual interface "up" occurs later in the kernel start up then you might expect, after say using systems like Linux. Most people would use local media unless you were part of a lab or a large infrastructure and spent the money for a network share and to set up the automation. Outside of booting and installing you can't do anything else with the network on an SGI in its firmware modes. You can't update firmware using the network. So most of the time you're talking local volumes. Network setup is not terribly bad for doing remote OS installs, but it's going to be command based and very few if any of the prompts are going to be graphical.

One thing to keep in mind as you go through the various items with the system as these were not designed to be user-friendly. They were not designed to be as well-rounded as a PC bios was with its options and date selections and all that. They're better off being considered specialty pieces of equipment that you were supposed to have a service contract and you were supposed to call SGI on your service contract for anything you needed. For a lot of things a tech would come out to do the work themselves instead of anyone from the business. Unless you're running a lab where you could afford to screw up, if you only had one or two of the systems and they had to keep working you may not even trust an employee to do it. You'd have SGI come out with a field technician to do the upgrade or the patches that are needed and then claim that everything is ready to go and then hand it back to the operator. You're going to run across quite a few things both at the hardware setup level and at the OS install level that you would've thought you wouldn't have to do or should be much easier, this is because a field tech was supposed to do this job and not the owner. So just consider that some of these things will be obtuse or difficult the first time you do them because you weren't ever supposed to do them. The product isn't as well-rounded as your average PC, certain things didn't need to be user-friendly because the user wasn't supposed to be doing them. OS Installation is one of those things.

I'm not saying it's hard for anyone that's installed Linux before, but if you've only installed an operating system like Windows or MacOS you would definitely be caught up in a few of the steps.

When it comes to the L1 and text PROM interface, yeah they fight, I've always felt it was mainly because both of them were waiting for input and so there appears to be activity that forces one to the other. Yes there is a way apparently go permanently go back to L1, but I've only used that on a graphical PROM... You're using a serial terminal PROM.

I see that your system only carries a single serial port, the workstations don't do this and have multiple ports and so they tend to spread out over a separate terminal for each interface, the way I use them. I have seen what you're talking about with it jumping back-and-forth and the best I could really say is we don't normally need to fiddle with the L1 when you're in PROM... I'd sort of forget about it being useful.

So I would just acknowledge that you can issue a single command really fast from PROM to the L1 by doing the terminal switch but in reality I just consider it kind of unusable. The only reason to access L1 from PROM would be to check your ENV tables, which if you go fast you can do.

Another word of advice on the installation of Irix, when using FX to partition, don't use AUTO and don't use the [FOR]MAT command. It doesn't do what you think it does. Use the manual methods outlined in the guides you'll read. I can explain why but just don't...you won't like what happens as you won't be expecting it.

[jander31]

Most old stations use BOOTP instead of DHCP at the PROM to autoconfig anything.  There are of course PROM commands to set a static IP address as well as a file location if you're doing network based BOOTP file fetching.

If you're using the LOVE utility to do network installs, read here: https://github.com/ColinLaws/love

Just so you're aware while SGI did support network installs the machines generally did not anticipate needing network at their firmware level or much during boot. The actual interface "up" occurs later in the kernel start up then you might expect, after say using systems like Linux.  Most people would use local media unless you were part of a lab or a large infrastructure and spent the money for a network share and to set up the automation. Outside of booting and installing you can't do anything else with the network on an SGI in its firmware modes.  You can't update firmware using the network. So most of the time you're talking local volumes.  Network setup is not terribly bad for doing remote OS installs, but it's going to be command based and very few if any of the prompts are going to be graphical.

I'm not saying it's hard for anyone that's installed Linux before, but if you've only installed an operating system like Windows or MacOS you would definitely be caught up in a few of the steps.

When it comes to the L1 and text PROM interface, yeah they fight, I've always felt it was mainly because both of them were waiting for input and so there appears to be activity that forces one to the other. Yes there is a way apparently go permanently go back to L1, but I've only used that on a graphical PROM... You're using a serial terminal PROM. 

I see that your system only carries a single serial port, the workstations don't do this and have multiple ports and so they tend to spread out over a separate terminal for each interface, the way I use them. I have seen what you're talking about with it jumping back-and-forth and the best I could really say is we don't normally need to fiddle with the L1 when you're in PROM... I'd sort of forget about it being useful.

So I would just acknowledge that you can issue a single command really fast from PROM to the L1 by doing the terminal switch but in reality I just consider it kind of unusable. The only reason to access L1 from PROM would be to check your ENV tables, which if you go fast you can do.

Another word of advice on the installation of Irix, when using FX to partition, don't use AUTO and don't use the [FOR]MAT command. It doesn't do what you think it does. Use the manual methods outlined in the guides you'll read. I can explain why but just don't...you won't like what happens as you won't be expecting it.

The Origin 300 has 2 serial ports and one console port.  How do I use the serial ports?  I'm currently on console (38400, RTS/CTS, etc).  I guess I do see your point with L1 only being used to see ENV tables, L1 didn't have much use other than diagnosing which fan was malfunctioning.

I'm ready for the command-based install.  Though my Mac Mini Server's Ubuntu installation was graphical initially, a lot of the reverse SSH configs, firewall configs, package/software installations, and IP configs were from a command line.

I had a few questions about the IRIX installation.  How long do you think a network installation of IRIX 6.5.22 would take (an hour or more)?  And where should I go about finding an ISO of IRIX?  I would like to avoid spending $100 on a physical copy of IRIX.  Thank you for the heads up on the installation procedure though, will be making a note of that.