[back to collection]

SGI Indy #4

(last updated: 22-Jan-2017)


Operational Status

Configuration

The current configuration is in its original 'as acquired' condition, except that the 175MHz CPU module has been swapped back from a companion Indy (#3).

Major Events

Still To Do


Description

Pickup

31-Jul-2012

This system turned up in a browse through the University of Utah's surplus store. The price was just $10, and I couldn't resist. This is one of two Indy's purchased today.

Cleanup

31-Jul-2012

The system had just a bit of dust, but no grime. It was clean inside too, requiring just a simple vacuuming. The external surfaces were wiped down with Windex, as is my usual practice. Inside, there are two empty drive brackets, but no two-way drive power cable which can be added pretty easily if needed later.

After my experience with Indy #3 (see notes) and it having the 'wrong' CPU module, a little research shows that the CPU module in this unit as purchased is not the R4400 175MHz unit that the model number would indicate, rather it is an R4500 100MHz module. The other Indy should have this type of CPU, according to it's model number. (See notes on UofU Indy #3 for more.) So I would appear that these two units have had their CPU modules swapped.

System checkout

31-Jul-2012

I connected the Indy to my large 20" Sampo sync-on-green monitor using the "Indy" 13W3-to-VGA adapter I already use with my first two Indy's. I connected up a keyboard and mouse, and powered up. I see appropriate color changes to the Indy power LED, going from green to red and back to green, I hear the power on chime, but I not get any output on the monitor's screen. It stays black.

After discovering that the CPU modules had been swapped, I then replaced the 'correct' R4400 150MHz module into this system and again powered-up. I see the same result. At least I have proven that both CPU modules work (hearing the power up chime). (See UofU Indy #3 notes for more.)

Video restoration

03-Aug-2012

A little web research hinted that the system might be configured to use a serial console, instead of the normal graphics console, which would explain the blank screen. The way to restore the system to using a graphics console would be to attach a serial console to the sytsem, enter the PROM console and set "console=g" instead of "console=d". The trouble with this method is that it requires a null-modem cable between the Indy and the terminal. That cable must have a mini-DIN8 connector on one end to match the Indy port. Alas, I have no such cable, or the connector with which to make one.

Further research indicated that if the mainboard's "password" jumper is removed (normally done to reset the system password), it will also reset the console to the normal graphics mode. This is worth a try!

I removed all cables from the system, removed the cover, and located the jumper near the power cable jumper. I removed it and powered up. Indeed, it worked! I now see the normal splash screen on the monitor.

I was able to press EsC and clicked "Enter Command Monitor", which showed a popup with "[!] Warning: Password jumper has been removed. Not enforcing PROM password." I clicked Continue and enter the command monitor window. At the >> prompt I took a look at the hardware inventory and the environment variables:

>>hinv
System: IP22
Processor: 175 Mhz R4400, with FPU
Primary I-cache size: 16 Kbytes
Primary D-cache size: 16 Kbytes
Secondary cache size: 1024 Kbytes
Memory size: 64 Mbytes
Graphics: Indy 8-bit
Audio: Iris Audio Processor: version A2 revision 4.1.0

>>printenv OSLoadPartition=/dev/sda1 OSLoader=kernel OSLoadFilename=kernel AutoLoad=Yes TimeZone=MST7MDT ConsoleWarning=PASSWD JUMPER MISSING--forced to g. console=g diskless=0 dbaud=9600 volume=80 sgilogo=y autopower=y netaddr=155.101.96.155 eaddr=08:00:69:08:f9:59 ConsoleOut=video() ConsoleIn=keyboard() cpufreq=175 gfx=alive >>

I powered down and replaced the jumper. Powering up again, I see no video! Ha! I have to actually change the settings myself. Again, powered down, removed the jumper, entered the PROM command monitor:

>>setenv console g
>>

Mmmm...well, this worked to get the video back, but now I am presented with a popup showing "[?] Enter password: ________". So I need to reset that password, too. Another cycle of power, pulling the jumper, etc...

>>resetpw
Password cleared.
>>

...and at last, I am able to proceed without a password! Life is good.

System checkout (cont.)

03-Aug-2012

From the PROM environment variables it appears to me that this system was running some OS other than IRIX. The OSLoadPartiion=/dev/sda1 suggests that it might have been NetBSD, since NetBSD supports Indys and, at least in the past, has required a serial console. NetBSD had no support for the onboard framebuffer video system, as I recall from prior research.

So, I would guess, then, that this system had a hard disk, and was running NetBSD. well, well, without that hard disk, we'll never know. I now need to locate a suitable hard disk, along with a power cable, and give this box a new life!

Graphics module swap

14-Aug-2014

Since this system is the faster of the two most recent Indys that I've acquired, it is a shame that it has only the 8-bit graphics option, where the lowly 100Mhz Indy has a 24-bit graphics option. I swapped the graphics options between the two. Now this system, "cosine", is the all-around beefiest Indy that I have.

Hard disk installation

14-Aug-2014

Somewhere along the line I acquired a few more Indy-style HDD mounting brackets and last fall I came across a pile of 3-1/2" SCSI drives at the Utah State University surplus store for just 25 cents each. I bought the pile of five drives, and installed a 1GB drive in this system.

For the HDD power cable, which was missing, I rounded up an old, dead AT power supply and simply snipped off the power plugs leaving me with about six inches of cable terminated on each end with the female MOLEX connector. It works perfectly!

IRIX 5.3 installation

14-Aug-2014

(more to come)

dd drive

PROM option 2 -> CD

Admin menu mkfs

main menu keep * install default go ... quit (builds ELF inventory file) (runs rqs(1) on ELF file) Restart

Login root System tools -> Admin tools -> System Setup - change hostname - change IP address - turn on networking reboot

return to System Setup -

The key to getting "ARPAnet" networking functional are three specific adjustments:

- Change Hostname and TCP/IP Address

- Insert Default Route command into /etc/rc2.d/S30network

- Create correctly structured /etc/resolv.conf

IRIX 5.3 for 175HHz or 200MHz Indy

25-Nov-2015

Since configuring this system, and installing IRIX 5.3, it has shown a few instabilities, commonly showing a Kernel Panic at bootup, or if it gets past that, then over a period of days it will experience a panic. Researching this a little shows that the Indy with a R4400 processor running at 175Mhz or 200Mhz requires an updated IRIX 5.3 distribution, one labeled for this higher speed processor. My copy of IRIX 5.3 is the original release, and it works fine one my two 133Mhz Indys and my 100Mhz Indy. And now I think I have the explanation for why this system is unstable, and shows disparate values for processor speed using PROM hinv (175Mhz), IRIX shell-executed hinv (200Mhz) and the System Manager GUI (150Mhz).

Installing IRIX 5.3 for 175MHz Indy

26-Jan-2016

Last night I was able to locate the "IRIX 5.3 for 175MHz Indy" CD-ROM image, and I burned it. This morning, I installed it:

First, boot into the disk label tool:

>> boot -f dksc(0,2,8)sashARCS dksc(0,2,7)stand/fx.ARCS --x

then, to create a single 'root' partition, rather than the default 'root + usr' partitions, choose:

l)abel --> ..
r)epartition --> b)oot --> ..
exi)t

then, boot to the cd using PROM screen button 2. Once in the 'inst' tool I just used these three commands:

> keep *
> install default
> go

and it took off installing the basic IRIX 5.3 system. This installation took about 20 minutes. Then:

> quit

and the installation finalizes by building the ELF inventory file.

Once that was complete, I rebooted and logged in as root. Then I fixed up the hostname, default route (in /etc/rc2.d/S30network), /etc/resolv.conf, and /etc/hosts using instructions from SGI Indy #1 notes (and above), section Network Tuning.

I also added the tgcware elements for rsync support. This required that I install the following tgcware packages:

- expat-2.0.1-2.tgc-irix5.3-mips1-tgcware.tardist
- gettext-0.16.1-3.tgc-irix5.3-mips1-tgcware.tardist
- libgcc_s1-4.5.3-4.tgc-irix5.3-mips1-tgcware.tardist
- libiconv-1.11-2.tgc-irix5.3-mips1-tgcware.tardist
- libstdcxx7-7-8.tgc-irix5.3-mips1-tgcware.tardist
- rsync-3.0.6-1.tgc-irix5.3-mips1-tgcware.tardist

Then I setup auto-start of the rsync 'daemon' with:

- installing /etc/init.d/tgc_rsyncd start/stop script that I created using tgcware's samba script as a model
- create /etc/config/tgc_rsyncd file containing 'on'
- create /etc/rc0.d/K05tgc_rsyncd soft-link
- create /etc/rc2.d/S95tgc_rsyncd soft-link


[back to collection] [top]

Copyright © 2006-2025 Jared Blaser. All rights reserved.