Getting Started, Documentation, Tips & Tricks

I recently acquired a working 2x250 R10k Octane, and separately a 2x360 R12k Octane2. With the latter came a "spare" Octane chassis populated with a 2x300 R12k. I was told the spare chassis had no PSU or disk, but... After getting it home and out of the impossibly tight static bag it was taped into, I found it had both -- though the 9GB drive was only held in place by the SCA connector and a matchbook ... Yet it stayed there despite me briefly having it on it's side as I tried to fit everything into the car -- glad I happened to later rotate that one upright.

The system booted for me once, but the password wasn't set to the value I was given for the working system (no surprise there). I was easily able to fix it in the other Octane chassis, but was subsequently unable to get the "spare" chassis to boot from it. The system would log multiple errors/resets on the SCSI bus. My next step was to try the drive from the working R10k system, but there appears to be an executable format difference between R10k and R12k, at least for the bootstrap/kernel.

Running the Diags from the PROM, the cursor stops spinning after a few seconds and the system appears to be wedged.

At this point I'm rqs'ing a fresh install of 6.5.18 on a random 18GB drive in the "spare" chassis with the R10k board. During the install I'm seeing "checkerboard" artifacts that make me think there's a problem in the EMXI framebuffer, but despite a few SCSI retries it seems to be working.

1. I'll have to try the diags again with a working drive installed, but don't expect much joy there. How can I find out where it's getting stuck?
2. I'm going to have to determine if the unsupported drive has damaged the SCSI backplane or pulled a connector loose. Anybody seen anything like this before in an Octane?
3. Anybody actually try to diagnose and repair these gfx cards, or is that likely a write-off?

--S.

After some post-Inst lockups on the "spare" chassis, I decided to make sure the IP30 w/ 2x250 and random disk were working properly in the original chassis. This included running the PROM diags, which also paused while the spinner was up, but I walked away and when I came back much later it was done (and had passed). So I might not have been patient enough with the "spare" diags, will have to retest. (That IP30 and disk/installation worked fine in the other chassis, fwiw.)

I did notice that the "spare" chassis reports Xbow 1.2, so I take it that the Xbow is part of the XIO backplane assembly? Would make sense if it's the crossbar switch...

I'll probably want to test the IP30 and MXI from the "spare" chassis in the working one next and see how they behave. And I guess I'll do another IRIX installation for R12k.I also have to go back to the respective original drives and grab the FlexLM license files and see if I can recover my "lmgrd fu" from back in the day. Guess I'll need to hope the HostID is tied to the IP30 board as opposed to the chassis...

Haven't touched the Octane2 yet as I saw it running when I picked it up, and I want to know what-all I've got before I make up a shopping list.

Yes, that's correct, it's on the backplane (some would call it a frontplane, but whatever).

The SCSI backplane is separated from the system frontplane by a funny connecting board that runs the length of the underside of the drive cage. Have you inspected the SCA connectors to see if anything was damaged in the move? That might be a good place to start, especially if, as it sounds, the drive is working fine in other Octanes.

BTW, I have a few spares you may be interested in if you isolate the problem: a SCSI backplane and a frontplane with Xbow 1.3.

It's called a frontplane because it's in the front of the system ;P And the host ID is in that canister looking thing (called a "number in a can") on the frontplane. It is easy to exchange if need be.

XBOW rev 1.2 was the subject of a recall by SGI, so my guess is that there were some issues there.

I just re-read my own initial posts and had a hard time following the swaps from chassis to chassis. Or maybe that's because I was mentally adding in the swaps that weren't mentioned. Either way, I'll try to keep it a little more focused or leave out the blow-by-blow.

Bearing that in mind, the IP30 (2x300) from the "spare" chassis had 3 x 128MB DIMMs and 3 64MB DIMMs. I'm assuming a mixed pair in one bank might account for some issues, so I took the odd pair out. It's busy installing IRIX on another spare drive in the known-good chassis to see how it behaves on a longer run... And quickly developing a desire to setup for netinstall as I swap CDs.

zuluchas: Yeah, I might be interested in those bits after I've sorted out what's bad and what's good. Would be nice to fix it with the right part(s) and release a working system back into the wild.

So, I'm talking about:
A : Green Octane found at Weirdstuff Warehouse , 2x250 R10k on -0887
B : Octane 2, 2x360 R12k on -1467 board
C : "spare" green Octane, 2x300 R12k on -1467, came with Octane2
D : Loose -1467 IP30 with 2x225 R10k, came with Octane2

A was an impulse "as-is" purchase when I spotted it at Weirdstuff. Turned out to be complete and working with 384MB RAM, 4GB HDD, "EMXI" gfx

B was running when I picked it up, and is running fine here at home. hinv posted in appropriate forum

C booted once, then rapidly got worse until it wouldn't get to the PROM. The system board included a mismatched set of RAM in the second bank that might have been causing some of the problems. But the IP30+CPU ran demos for many hours after being swapped into the A chassis with properly matched RAM. I'll come back to the chassis later.

D wouldn't light any LEDs when swapped into the A chassis. PSU started when power was connected, and power switch did nothing. Peeking through the DA15 cutout under the front skin, the top two green LEDs (R50+R51) were lit, the two below were not. I removed the 030-1271-002 CPU module and mounted it on the -1467 from C, and it powered up fine in the known-good A chassis. I put this CPU module back in the D -1467 with different (working) RAM, and the system continued to be non-responsive.

C chassis : I took the IP30+2x250 from A and popped it in, using the RAM from C (why keep things simple?) and got stuck at a lit red LED. Owner's Guide says that's likely to be a poorly seated mainboard or XIO option. Reseating the boards made no difference, so I popped out the MXI and BingoI I get the PROM on serial port 1. And the system just passed the diagnostics headless, so we're definitely on to something.

- Reinserted the MXI, back to a red LED lockup. Removed the TRAM modules, no improvement. Removed the suspect MXI and installed the MXI from A, and it comes right up and passes diags.

So in summary , all three chassis appear to be working. I've got one bad -1467 mainboard, but the CPUs and RAM were okay; and one bad MXI which can easily be replaced ... with a V6 maybe. Not seeing any more SCSI errors in chassis C at the moment.