Forum Thread: SGI System to PCI Type Cross Reference
Source: forums.sgi.sh
--- Post by fraserN64 ---
I'm working on a much bigger project and realized this little piece could help some folks out when considering PCI cards. (References at the bottom)
NOTE: Universal PCI Cards should fit in all systems that support PCI, these have 2 keys [gaps] in the card edge connector.
PCI and it's sub-specifications and implementation by SGI can be confusing.
64-bit PCI is NOT PCI-X
64-bit PCI is an addition to the 2.1 PCI specification. PCI-X is a new specification that is backwards compatible with PCI and 64-bit PCI.
The key feature that PCI-X adds is 100 MHz and 133 MHz transfer rates, compared to the 64-bit PCI standard at 66 MHz
PCI-X is only 3.3V while 64-bit PCI can be 3.3 or 5V.
PCI Type and Version Chart
Model Brick or Shoebox 33 MHz 66 MHz 100 MHz 133 MHz 32 Bit 64 Bit PCI-X 3.3V 5V O2 1 1 X Octane XIO PCI
1 slot 1 1 X Octane XIO PCI
chunk 0
Forum Thread: 3D filament color matching
Source: forums.sgi.sh
--- Post by JDub ---
I'm working on printing the missing CD-ROM cover for my O2. Does anyone have any recommendations on filaments that match the O2 blue?
--- Post by flexion ---
Creality Matte Navy Blue PLA is the closest match I have. not 100% but I'd say it would look better than no CD cover
chunk 0
Forum Thread: O2 RM7000C CPU upgrade and OC tutorial
Source: forums.sgi.sh
--- Post by sdz ---
You will need:
-RM5271/RM7000 CPU module.
-RM7000C CPU
-O2 CPU PROM emulator ( https://forums.sgi.sh/index.php?threads/o2-cpu-prom-emulator.1512/ )
Steps are as follows:
1. Bake the RM5271/RM7000C CPU module and the RM7000C CPU for ~16 hours at 120-130C.
This is needed to ensure there is no moisture in the ICs and PCB. It is really good practice to do this for such old boards/ICs.
2. Remove the heatsink from the RM5271/RM7000 module.
Use freeze spray to cool down the heatsink. Then, insert a plastic credit card between the PCB and the heatsink. Use a flat head screwdriver or similar implement to pop off the heatsink (while pushing against the plastic credit card)
3. Remove the RM5271/RM7000C.
Use a preheater/hotplate and hot air to remove the CPU.
4. PCB pads cleanup.
After removing the CPU, clean off the pads using solder wick and a soldering iron (and flux). When done, clean the area well with IPA so none of the old flux remains.
5. Solder RM7000C
chunk 0
Forum Thread: O2 CPU PROM emulator
Source: forums.sgi.sh
--- Post by sdz ---
PROM emulator for the PROM IC that sits on the SGI O2 R5k/RM5271/RM7000A (and other CPUs that can be fitted on there) modules.
The PROM is responsible for configuring basic CPU functionality like multipliers, endianness, caches etc.
The part numbers used by SGI are truly PROM devices (Programmable Read Only Memory), which means they can be programmed only once. With the PROM emulator, anything can be changed on the fly, nothing needs to be desoldered/programmed/soldered back over and over again.
Besides choosing between a couple of sane bitstreams for each supported CPU, there is also the option for custom config for all CPUs. This process is interactive, there is no need to look at the datasheets and manually craft the bitstream for testing.
The board implements USB CDC-ACM. When connected to a computer, a virtual com port device will be crated. Use a terminal emulator set to 1152008n1 to communicate with the PROM emulator.
chunk 0
Forum Thread: O2 CPU modules PROM dumps and analysis
Source: forums.sgi.sh
--- Post by sdz ---
The PROM (Xilinx IC) that sits on the CPU modules (usually has a little sticker with text on it, SOIC-8 package), not the system PROM.
1. R5k 180MHz 512kB external cache
EDIT: I previously make an error when decoding the bitstream, this has been corrected now.
On the R5k, the PROM is read directly by the CPU (which also provides the clock for reading the PROM).
It took a little bit of work to figure how to read out that PROM so maybe this will help others in the future: valid data is present on the falling edge of the clock. Even though at a first glance it appears that valid data is provided shortly after the rising edge of the clock, like this:
That is to be ignored.
The PROM, for whatever reason, is read twice on the R5k module during power on (maybe there is a second reset signal, haven't checked).
During system startup, the R5K reads 256 bits from the PROM (although it never stops the clock and it seems that there is some data at the end of the PROM).
For the R5k 180MHz 512kB module, this is the bistream that is read (left is bit 0):
chunk 0
Forum Thread: O2 CPU modules teardown
Source: forums.sgi.sh
--- Post by sdz ---
No CPU modules were harmed.
1. R12k 300MHz 1MB
--- Post by ruckusman ---
sdz said:
2. R10k 150MHz 1MB
View attachment 3744
View attachment 3745
View attachment 3746
View attachment 3747
View attachment 3748
View attachment 3749
View attachment 3750
View attachment 3751
View attachment 3752
View attachment 3753
Click to expand...
180Mhz underclocked to 150Mhz?
--- Post by chulofiasco ---
ruckusman said:
180Mhz underclocked to 150Mhz?
Click to expand...
sdz said:
Indeed
Click to expand...
Savage.
--- Post by sdz ---
4. R5k 200MHz 1MB
I did not remove the VICE heatsink as it's glued on pretty well and we already know how it looks.
--- Post by sdz ---
5. RM5271 300MHz 1MB (newer revision with QFP cache ICs)
chunk 0
Forum Thread: Cleaning up a crude .stl model of an O2 to hopefully produce a good model of an O2
Source: forums.sgi.sh
--- Post by Irinikus ---
Here's a picture of the original .stl model, just alert being loaded into Blender on My Mac Pro:
This .stl file was made available by @gijoe77 (A very big thanks!!! )
It imported as a single group of polygons, so I can't select the individual parts of the model!
So the only way in which I can free up the various parts of the model to clean them up is to delete all of the vertices constituting the parts that I don't want! (This is a very time consuming process, as you have to make sure that you don't delete any of the vertices of the part that you want, and all of the parts of the model are overlapping!)
I will have to go through this process multiple times to free up all of the individual parts of the model!
I've started off by working on the main plastic body of the O2. (So this is the first part that I've freed up.)
This was the first iteration of the cleanup process:
chunk 0
Forum Thread: SOLVED - ZuluSCSI in R5000 O2 with SCSI ID 2
Source: forums.sgi.sh
--- Post by philden ---
I'll leave this question here in case it is of use to someone else, but have I replaced the log files with a photo of my temporary solution.
It occurred to me that the simplest solution would be a physical connection issue. Looking at my two disk sleds, it seemed that the connector for the hard drive protruded slightly more than that from the ZuluSCSI. Maybe 1mm. Perhaps on my old O2, the connector for sled 2 is slightly deeper in the drive slot than that for sled 1.
So I temporarily mounted the ZuluSCSI onto the back of the sled, by one pair of screws only. I tried using the center screw holes on the ZuluSCSI, but there were components in the way. See attached photo.
Loading the ZuluSCSI this way, I see drive 2 in 'hinv', and unmounted in File Manager, as I would expect.
I will contact Rabbit Hole Computing to see if I can get a slightly different bracket for the board. Maybe the problem is general, or caused by distortion to my O2.
I'm sure summarizing the issue here helped me find the solution!
Thanks, Phil.
chunk 0
Forum Thread: O2 VGA Sync On Green ultimate guide + MB mod
Source: forums.sgi.sh
--- Post by sdz ---
The O2 is known to output sync on green signal (hsync and vsync embedded in the green channel). For some reason it also outputs separate hsync and vsync signals, which can cause various issues.
If you get something like this (permanent or random when starting up the machine):
You are in one of these 3 cases:
1. Your monitor supports sync on green, but the image always has a tint of green.
This happens because, even though the monitor supports sync on green, it sees the separate hsync and vsync signals provided by the O2, and decides to use those instead of sync on green.
Because of this, it does not correctly interpret the green channel, causing a green tinted screen.
Fix for this is simple, take the VGA cable, and remove the pins that carry HSYNC and VSYNC (13 and 14). Only need to remove them on one side of the cable.
My Dell SE2416H always displayed a green tinted image, and according to the manual it does not support sync on green. However, this is how it looks after removing the hsync and vsync pins:
chunk 0
Forum Thread: O2 motherboard repairs
Source: forums.sgi.sh
--- Post by sdz ---
Got two broken O2 motherboards a little while back.
Board #1:
This board gave a solid red light when powering up, regardless if RAM or CPU was installed. No signs of life via serial or VGA. It also looks brand new, basically unused (except for a dent on the top serial port).
Since it behaved the same regardless if a CPU was inserted or not, I inspected the area near the CPU, and found this:
This is a factory defect, the inductor was never soldered on one side (the pad still has the ENIG finish, other side is soldered). This inductor powers the 133MHz oscillator on the other side of the board:
Soldered the inductor and now the board is fully functional.
--- Post by sdz ---
Board #2:
This board gave a solid amber light when powering up. No signs of life via serial or VGA. With no RAM installed, still solid amber light (it should be blinking amber if it got to the point of checking the RAM).
However, without a CPU module installed, it gave a solid red light. So at least it tries to do something when a CPU is installed.
chunk 0
Forum Thread: O2 system PROM socket adapter
Source: forums.sgi.sh
--- Post by sdz ---
Socket adapter for the O2 system PROM, so that the flash can be easily removed and programmed externally when needed.
Installation instructions:
-remove Dallas socket
-remove flash IC
-solder the two FFCs
-solder Dallas socket back
-install adapter
-install Dallas IC
-connect the two FFCs
-install flash IC
--- Post by sdz ---
Attached SGI_O2_SYSTEM_PROM_SOCKET_ADAPTER_A00_RELEASE.zip archive (will be available at https://sdz-mods.com/index.php/2026/02/13/sgi-o2-system-prom-socket-adapter/ as well).
It contains the following:
1.SCH_BRD - contains editable schematic and board file. Format is Eagle CAD, but they can be imported in other tools, like Kicad.
2.SCH_PDF- schematic in pdf format.
3.P&P - pick and place files
4.BOM
5.GERBER - gerber files
Notes:
-the two FFCs are not identical, pay attention at the photos to see how they need to be installed (both FFCs and the adapter PCBs are marked with L and R)
-header pins that plug into the Dallas socket need to be the machined type, round
chunk 0
Forum Thread: Octane Power Supply mvm5 2k 10% part?
Source: forums.sgi.sh
--- Post by 3DChris ---
Does anyone know where to source, or have any of these resistors? It's labeled MVM5 2K 10%. Apparently it (they) has failed and is the cause of my power supply not working anymore.
I had the power supply at an electronics repair place and they looked over it. They said the capacitors all passed their test and didn't show any signs of leaking or damage.
They indicated that this resistor part is what might be the issue, but they cant source a replacement anywhere.
Any info would be appreciated
As it is, my Octane has been sitting dead for months and months
--- Post by weblacky ---
You should post a picture of the part and dimensions to confirm. You don't specify the wattage either.
I'm making a guess based on the part markings: MVM5 2K 10% can mean 5W, vertical mount, 2K Ohm, metal oxide, cement resistor 10% (or less) tolerance.
I think you're looking for a part like either of these:
Ohmite TWM5J2K0E: 5 Watt, 2K Ohm, 5% Tolerance, Vertical Mount Cement Resistor.
TE Connectivity (CGS) SQMR72K0J: 7 Watt, 2K Ohm, 5% Tolerance, Vertical Mount.
chunk 0
Forum Thread: O2 new 128MB RAM modules
Source: forums.sgi.sh
--- Post by sdz ---
Got an O2 last week (my first SGI machine!) and it seems like the 128MB RAM modules are pretty hard to find, so I designed some new modules.
These are designed with currently in production off the shelf parts, so no need to source obsolete components. Also added test points for the card edge pins that were not used on the original SGI 128MB modules. I'll probe them at some point, and if anything looks like an extra address line (that the O2 tries to use), I'll try making 256MB modules and see what happens.
EDIT: Just read the CRIME 1.5 spec, 256MB modules won't work.
I'll update this thread when I get the PCBs and test them.
Also attached the vanilla SGI 128MB module schematic (decoupling caps and filtering not shown) O2_DRAM_128MB_ORIG.pdf.
--- Post by stormy ---
Wow this is excellent work, thank you!
--- Post by CiaoTime ---
Genius! I'm very interested in this.
--- Post by sdz ---
Got the PCBs today, and assembled 4 modules:
chunk 0
Forum Thread: SGI Indigo 2 Replica Cases
Source: forums.sgi.sh
--- Post by andrean ---
Hey folks,
I have seen a couple of threads already started about the unfortunate inexistence of quality replica cases for SGI Indigo 2 machines, e.g.:
Indigo 2 broken case.
Hello. I was working while having my indigo 2 under my desk and then I heard a loud bang one time when I spun my chair to look at one of my monitors and... lo and behold.... I broke the Case of my dear Indigo 2... I can't describe the pain and Shame I feel right now... Do you guys know what...
forums.sgi.sh
and given their sensitive nature, the plastics are becoming almost impossible to come by nowadays, especially the front flaps, but other parts as well..
chunk 0
Forum Thread: New to SGI. Would anyone be kind enough to check if the monitors I have will work with 13w3 and support SOG correctly?
Source: forums.sgi.sh
--- Post by CH9NNEL99 ---
Hi! I'm an analog video artist and for the past year or so I've been getting back into animation after getting my BFA in 2008 and not really touching Maya for 12 years or so. I've been building some very unusual multiprocessor PC workstations and it occurred to me recently that I'd really like to learn, work with, restore and preserve SGI machines. I never got the opportunity to work with them too much, since most of what I had access to in college was all PC based, but I did work in electronic salvage and had quite a few onyx and octane and indigos pass through our warehouse and I've always been kind of captivated with them. I'm currently looking around for a well-equipped octane 2 or tezro for my studio to live with the wild assortment of PC's and analog gear I already have. I've got a pair of DELL u3011t 30" LCD monitors that seem to support sync on green over VGA, and I already have an SGI 13w3 to hd15 cable.
chunk 0
Forum Thread: 1600SW CFL tubes replacement
Source: forums.sgi.sh
--- Post by Jacques ---
Hi, does anybody know if the CFL tubes used in the 1600SW are still commercially available? Mine are really at the end now and while the display specs are not as good as a modern panel I’d still like to retain the display with my O2.
--- Post by chulofiasco ---
Here you go bud: https://www.niktec.com/sgi-1600sw-c...backlight-cold-cathode-fluorescent-lamps.html
--- Post by Jacques ---
Thanks, I’ll try and see if there is an EU seller as shipping would be $$$.
--- Post by Woof ---
I did get the ones from Niktec maybe 15 years ago, and dug through some old mails to find this from 2013:
SGI 1600SW End of Life Sale
chunk 0
Forum Thread: Indigo 150mhz Static Ram Error
Source: forums.sgi.sh
--- Post by legodude ---
My dead MIPS CPU woes continue... I was lucky enough to pick up a cheap 150mhz CPU for my Indigo a while ago and all was good until I went to use it recently. It failed partway through the boot process and I was at a loss until I hooked up a serial console:
The error is quite helpful at pinpointing the exact problem, and U4 is helpfully labeled as the third chip from the bottom on the right:
An Ebay seller had the replacement chips in stock so I broke out the hot air station and went to town:
Sadly, the error is exactly the same:
I doubt both chips failed in exactly the same way. I can't see any other damage to the CPU board. The system works fine with the old 100mhz CPU. Any ideas?
--- Post by legodude ---
Okay, now the system won't start with the 100mhz CPU. I'm worried the system board is on the way out.
Sigh
--- Post by weblacky ---
Yeah I was actually going to say don't remove the chip yet and actually check the traces for the connection to the chip. SRAM really-ish doesn't go bad, unless something external acts on it.
chunk 0
Forum Thread: Compact 4 MM DAT Drive
Source: forums.sgi.sh
--- Post by joeaero ---
I am trying to connect a compact 4 MM DAT drive to an Octane running IRIX 6.5. However the system does not recognize it. It there a solution?
Thanks.
--- Post by legodude ---
Does it show up in hinv? Does it work on other computers?
chunk 0
Forum Thread: Good source for XTalk connector covers
Source: forums.sgi.sh
--- Post by wogaut ---
Xtalk connector covers are hard to find, what is a good source for new or 3D printed covers that are a good functional match to the original ones?
--- Post by jenna64bit ---
If you're talking about the Octane style compression cap, here's one https://github.com/flexion-unity/SGI-3DPrint/tree/main/accessories/comp-cap
chunk 0
Forum Thread: Origin 300 failing to boot
Source: forums.sgi.sh
--- Post by edolnx ---
I have an Origin 300 system that has failed to boot after a thermal event (cooling failure in a data center). The L1 works, env shows everything is fine but when you power on the system one of the LEDs at the back of the motherboard doesn't light up and the CPUs are all stuck in INIT and never progress beyond that. I have verified that the RAM and HDDs are good (works in another machine). I've also swapped around the VRMs labeled 1, 2, 3 on the system diagram to see if that would move the light that is off to no success. Would love any other ideas.
chunk 0
Forum Thread: Zulu Wide-SCA review in SGI o2
Source: forums.sgi.sh
--- Post by stormy ---
Here is my review of the new Zulu Wide-SCA. The Zulu Wide-SCA is a 16-bit Ultra Wide SCSI emulator, enables read speeds of up to 33 megabytes/second with the Raspberry Pi RP2350B microcontroller. ZuluSCSI supports Ultra Wide synchronous SCSI transfers, with read speeds up to 33 megabytes/second, and write throughput of up to 18 megabytes/second. This in my opinion is a significant achievement in SCSI emulation, something the SGI community has been wanting for quite some time. An 80-pin Wide/Ultra Wide SCSI controller is required to achieve maximum throughput, along with a sufficiently-fast SD card.
I will be testing the Zulu Wide-SCA in my SGI o2 which is equipped with a 300mhz R5000 processor. I will for comparisons sake, include a benchmark vs a Fujitsu 10K RPM spinning SCA SCSI disk. It is worth pointing out that this review assumes a basic understanding of ZuluSCSI and it's operation, as this is an evolution of the ZuluSCSI product line. If you are not aware of the advantages and usability of ZuluSCSI please click here.
Firstly the device itself:
chunk 0
Forum Thread: Understanding the relationship between the ZuluSCSI and BlueSCSI codebases
Source: forums.sgi.sh
--- Post by aperezbios ---
In the interest of not derailing the original thread, this is a separate thread intended to cleanly peel off from this thread.
Since there seems to be a lot of confusion and outright FUD regarding this issue, I'd like to clarify that the BlueSCSI Pico/V2 firmware is ~98% re-branded ZuluSCSI firmware . That's why "Copyright <year> Rabbit Hole Computing" is present over 70 times in the current version of the BlueSCSI code base. This is easily verifiable via a simple recursive grep of the BlueSCSI code base for the string "Rabbit Hole Computing". We own the copyright to the code because we wrote it.
At a firmware level, the BlueSCSI V2 code base is nearly identical, with the notable exception of the format of the text in the log file, which is all most end users actually see. There are many other small and relatively superficial differences, but at the end of the day, nearly all of the heavy lifting was done by us, and at my expense. The BlueSCSI V2 firmware represents a search-and-replace of "Zulu" to "Blue"
chunk 0
Forum Thread: Indy, crackling speaker & strange smell
Source: forums.sgi.sh
--- Post by trembl ---
After being a SGI user in the mid-90ies, I finally got my hands on a SGI Indy!
The good news: it boots to the PRAM screen, I am planning to use a BlueSCSI has hard disk replacement.
The worrying news: the speaker started to make crackling sounds, which were soon followed by a strange burning smell. The video output kept working, but I pulled the power immediately.
I visually inspected the Sony PSU, no obviously blown caps.
I would be grateful for any advice or suggestions what to do next.
Was anyone in a similar situation?
--- Post by SolusRaion ---
Check the MOSFETs. These systems are known for needing a full recap. If that's beyond your capabilities, Weblacky has rebuilt two of my power supplies and while I have not yet tested either of them I am fully confident in his capabilities. There will be a review of his service as soon as I have time to fuck with them.
chunk 0
Forum Thread: DG5-2/DPLEX adventures
Source: forums.sgi.sh
--- Post by joshyfishy22 ---
Hello everyone! About a couple of weeks ago I was checking ebay for the 4th time that day and came across a listing for 2 DG5-2/DPLEX boards. I immediately knew that I had to buy them since I have the ability to run a 2 pipe DPLEX cascade in my g-brick and knowing the rarity of these boards I'll probably never have this opportunity again.
The main problem is I don’t have the special cables that they need to communicate to each other. They use the same style plug as the 1600sw and VBOB but have 40 pins. The users guide for the dplex board never references a part number for the cable and only calls it the LVDS cable. But some searching iv found that 018-0792-001 is the correct part number for the “cable assy DPLEX/NCLOPS”
My goal with these is to fully document everything related to Hyperpipes, Reality Monsters, and “DPLEX”. Also to get a fully running cascade up. If anyone has any info on this please let me know. Anything will be helpful!
chunk 0
Forum Thread: Getting SGI Iris 4K PSU back online - Need Help
Source: forums.sgi.sh
--- Post by megaimg ---
Team, I've been working on an SGI Iris 4K PSU for a while. I would appreciate any help from anyone with a PEC4044B model who can open it to verify a couple of parts for me. So far done, full recap, couple of damage zeners 15v , but the big issue is when I got the unit, the main PSU board had the transistor in Q104 burnt. I try to make the part number, but I am not 100% sure.
I need someone to get a good picture of the Q103 and Q104 transistors in the PSU. To get new parts.
chunk 0
Forum Thread: Presenter 1280 cable help
Source: forums.sgi.sh
--- Post by Roostie02 ---
Hi all,
I've recently acquired 2 Presenter 1280 displays, along with the Corona presenter board for the Indy. However, I am missing the cable.
Rather than try to find someone who has a spare I figure I may be able to fabricate my own, but I need some more information from one of you first.
My Presenter 1280 uses a 68 pin VHDCI connector, identical to what you would see on a 68 pin SCSI cable. But my board in the Indy has a 68 pin HPCN connector. I was able to find this document that implies the connector pinout for the 1280. I would assume that the original cable for the presenter was straight through (pin 1 on the VHDCI side goes to pin 1 on the HPCN side, etc) but I want to be totally confident before I try to make one on my own and let all the smoke out.
Can any presenter owners confirm my assumption please?
Thanks!
-Jack
68 pin HPCN:
68 pin VHDCI:
--- Post by mapesdhs ---
Sorry for posting to an old thread, but this one does show up high in search results.
chunk 0
Forum Thread: 4 mm DAT Drive
Source: forums.sgi.sh
--- Post by joeaero ---
I have a SGI Octane and need to mount a 4 mm DAT drive. I
have an internal one on there, but it doesn't work. I want to
unmount it and add an external one. However I can't find the
proper procedure. I would appreciate any help
Thanks.
chunk 0
Forum Thread: Octane2 number-in-a-can programming
Source: forums.sgi.sh
--- Post by jackal ---
Hi folks! New Octane2 owner here. Arrived without a NIC button on the frontplane so I can't use the network for lack of a MAC NIC. Gather that these are just iButtons so should be fairly trivial to program.
https://wiki.preterhuman.net/Number_In_a_Can seems to provide good information what is expected to be there. Do we think this is the totality of what would need to be written? Do we have an existing dump of the contents of a frontplane button? At $4 a pop for a DS1982 this isn't an expensive experiment, but at the same time I'd love to have something to compare against before I try to write the one-time-programmable device.
I think I have someone who's programming one for me already, but all the same I'd love to know in case I need to do it myself in future.
--- Post by miod ---
I can't seem to find dumps around, maybe I got rid of them.
chunk 0
Forum Thread: vw540 and 900mhz xeons?
Source: forums.sgi.sh
--- Post by funcle ---
Attempted replacing the orig 450mhz xeon pentium II's with 900mhz xeon pentium III's and machine will not boot. Wondering if I missed a step along the way. Maybe the VRM's? the prom? the whole concept? The pentium III's were from a Compaq server... that may be the issue as well.
--- Post by Woof ---
When I put 1GHz PIIIs in my 320 over 20 years ago, I'm pretty sure I changed the VRMs. But that was 20+ years ago so I'm a little hazy.
--- Post by Lastmile ---
Xeons need to be 2.8V, not 5/12V. I think the only stepping that comes in that voltage is SL4XY. Very rare. I don’t think you need new VRMs but PROM will have to be updated to the latest version while you still have the old CPUs installed X
chunk 0
Forum Thread: Nikon LS-2000 Film Scanner & IRIX
Source: forums.sgi.sh
--- Post by chulofiasco ---
I got the great idea to digitize some of my old film negatives, and thought to myself, what can I use that might also be fun on an SGI?
The Nikon LS-2000 is a Coolscan device that has a SCSI interface, and was sold for use with PC and Mac machines. Connected to the Octane, shows as:
Code:
hinv:
Integral SCSI controller 1: Version QL1040B (rev. 2), single ended
Scanner: unit 2 on SCSI controller 1
With depreciated scan and print services from a stock IRIX install, I wondered, how will I interface with the device to actually use it. That's when I discovered, nestled away in Freeware:
sane-backends-1.0.12 SANE scanner library backends 2003-07-01 sane-frontends-1.0.11 SANE scanner library frontends 2003-07-01 xsane-0.91 SANE graphical frontend 2003-07-01
Tragically, I don't have any film to scan, it's at Mom's, but the initial tests scanning nothing seem promising.
Would love to hear if anyone has experience using a film scanner in IRIX -- in the mean time, if anyone has questions, feel free to touch base.
chunk 0
Forum Thread: Indy Power Supply information
Source: forums.sgi.sh
--- Post by Elf ---
Hi all,
It is probably no secret that I am designing a replacement Indy PSU using off the shelf DC-DC converters. While that is a matter for another series of posts, along the way I have collected some basic information about the functioning of the Indy PSU.
If referencing or duplicating this information, I ask that you maintain a prominent link to this original forum post for further updates, as well as a credit by name.
To start that off, here is the power supply pinout from the motherboard's perspective:
Power is supplied on a 20-pin Molex Mini-Fit Jr. type connector, with the motherboard side being the male connector and the power supply side being female. The pin numbers are as per the mechanical drawing.
The +5V standby is supplied when the power supply is connected to AC line power but has main power turned off via the motherboard. I am guessing the -12V rail is for audio amplifiers.
chunk 0
Forum Thread: BlueSCSIv2 & Indigo2 problems?
Source: forums.sgi.sh
--- Post by stormy ---
If anyone else has experience with the Indigo2 and BlueSCSIv2 I'd be interested in their opinion on this:
https://github.com/BlueSCSI/BlueSCSI-v2/issues/281
--- Post by mousehouse ---
After some fiddling it’s working for me. I’m running the latest firmware 2025.08 and I did have to create a BlueSCSI.ini file.
[SCSI]
System=“General”;
Quirks=0;
EnableSCSI2=0 ;
SpeedGrade="TurboMax";
MaxSyncSpeed=20;
Weirdly enough with only the top 3 my Indigo2 would boot fine but I got block errors and a lockup running diskperf. With the turbo features enabled it runes smoothly on my new and clean 6.5.22f.
It’s the same speed as my 9GB 7200rpmIBM drive.
--- Post by stormy ---
@mousehouse I've tried the same settings as you, apart from turbomax and syncspeed 20 (as indigo2 can't run at that speed anyway) really you should be running at SpeedGrade=Default and MaxSyncSpeed=10.
chunk 0
Forum Thread: Help with slimline DVDs in Tezro
Source: forums.sgi.sh
--- Post by SGI22 ---
Hello all! I have a handful of 013-3993-001 (SR-8177-B) DVD drives which I couldn’t get my rackmount the TEZRO to read from. The 013-3993-002 (SR-8178-B) worked fine.
Failure Symptoms: The drives read the CDROM intermittently, they do not work with the CD Player software on the Tezro. Attempting to play the CD only locks up the system.
Any suggestions as I cannot sort this out. Thanks!
chunk 0
Forum Thread: Health Check (Diags?) for IRIX?
Source: forums.sgi.sh
--- Post by SGI22 ---
Besides PANDORA, POD and running heavy sessions of demos (powerflip, texcube, mirros, etc.) what other ways do you test SGI systems? Are there any methods or software options out there that can test and track system health or capture performance for comparison to other systems with same or different builds? Trying to come up with a way to log a systems "health" and benchmark performance in various configurations if possible.
--- Post by Woof ---
I'm also interested, since I've been running demos to gauge any overheating and power issues. I recently learned about Pandora, and I'd be interested to know about other more complex, heavier demos.
--- Post by SGI22 ---
So far no luck sorting this out - will keep everyone posted if progress is made
chunk 0
Forum Thread: SGI O2 main board release lever 3D printing
Source: forums.sgi.sh
--- Post by Old-school-cool ---
I just got an O2 and the plastic isn’t in great shape. The plastic lever for the main board release lever is gone entirely. I’ve found a few projects to replace parts, but so far I haven’t found a 3D model for this part. Does anybody know of a project to replace it? Or maybe someone can offer one to sell?
--- Post by stormy ---
I'm pretty sure it's the same as the drive-bay lever... you can get that here: https://www.thingiverse.com/thing:6146244
Or if you want to, feel free to print an entirely new case for the machine https://forums.sgi.sh/index.php?threads/sgi-o2-replacement-case-indigo1-inspired.1431/
--- Post by Old-school-cool ---
I see! I managed to get the board out, inspect the damage, and I understand the issue now. I’m going to try to rebuild the part of the plastic that supports the lever issuing epoxy, then file it down and attach a lever… some day. I did manage to make it but eventually. Someday I should fix the board lever issue.
chunk 0
Forum Thread: Requesting assistance with disabled CPUs on Origin 2000
Source: forums.sgi.sh
--- Post by mcguire ---
Greetings, learned colleagues. First post here, please forgive any breach of etiquette. I'm writing to request assistance with the resurrection of an Origin 2400.
We at LSSM are trying to awaken this 2400 after a few years' slumber. This system was mine personally from about fifteen years ago. We had it running at the museum at one time, but rotated it out of the exhibit area to make room for new machines about five years ago. It has sat in a climate-controlled warehouse since then. The config is two chassis in a rack, 16x 400MHz R12K, 32GB of RAM.
It was hanging on power-up, with N4 of the top chassis showing 0x9a ("CPU disabled by an environment varaible") for both CPUs. The machine comes up fine if I pull that node board. I've tried cleaning and reseating the DIMMs and the node itself, no joy.
Does anyone have any suggestions as to next steps to diagnose and recover that last node?
I'll be working over there this afternoon and all day tomorrow, and can get additional information if needed. Any and all assistance is greatly appreciated.
Thanks,
chunk 0
Forum Thread: Not power on when connecting cam to Indy
Source: forums.sgi.sh
--- Post by mryo20011024 ---
Hello.
Recently I get the old Indy (R5000,64MB) with Keyboard, mouse and Cam. When I connect to Cam to my Indy, Indy never power on.
But I remove Cam from my Indy, and press the switch button, it works perfectly. For this case, are there any problems on system board or only cam's problem?
I want to know how to check the cause of this symptom.
Best Regards.
--- Post by joshyfishy22 ---
My guess is something is shorted in the indy cam. Id crack it open and start probing around to see whats shorted.
chunk 0
Forum Thread: Origin 300 cluster power cycle issues.
Source: forums.sgi.sh
--- Post by nondem ---
Sorry to have my first post be a cry for help but we are still using a SGI cluster in production to model the weather.
We had to power-cycle the system for the first time in 20 years due to a UPS changeover and I am trying to troubleshoot what appears to be a broken model-run.
Is anyone good with these boxes? We actually have a replacement for this system in test but it's got a few more weeks till it's ready.
Some initial questions:
I did a shutdown command in the OS (Irix) and then after it completed - they moved the power. It came right back up fine and appeared to be working.
This morning - three of the four modules was powered off and the weather model failed to run at midnight. We powered them up but have no way to know it'll work till tonights run happens. Since those modules are powered up now - will they automatically join the cluster and work or is there something I need to enter at the L1: prompt(serial)?
chunk 0
Forum Thread: Origin 3900 - Looking for complete system or CX-Bricks
Source: forums.sgi.sh
--- Post by SGI22 ---
I have a project that requires a complete Origin3900 or for me to build one up from parts. Preferred IP53 is the 4x800/8MB with 8GB RAM but open to any and all possibilities. Unfortunately the 4x1GHz is not an option - sorry Ian
chunk 0
Forum Thread: Onyx2 Deskside no longer sees any internal SCSI devices
Source: forums.sgi.sh
--- Post by mgchristensen ---
This one has me completely stumped. Previously working Onyx2 Deskside, on startup, no longer finds any internal SCSI devices on startup. I have swapped the IO6G with a second 100% functional Onyx2 (machine #2), still no drives found in machine #1, and the swapped IO6G works in machine #2. The system drive from #1 boots in #2, all other hard drives appear on startup in #2 and noe found in machine #1.
I am using a serial terminal to watch the boot process, and can see when the two SCSI buses are walked on both machines. I have not tried yet attaching a terminal to the diagnostic port and turning the key switch to the diagnostic position.
chunk 0
Forum Thread: Source for GEs for Indigo?
Source: forums.sgi.sh
--- Post by legodude ---
I just purchased a XS24-Z for my Indigo - this will be a huge upgrade from my Entry graphics
I highly doubt I will be able to find loose GEs to upgrade this set to Elan. Is there an alternative source of GEs - IE, do any of the other graphics systems for different machines use the same chips such that they can be donors?
thanks
mike
chunk 0
Forum Thread: New to SGUG and Octane Red Light Bar problem!
Source: forums.sgi.sh
--- Post by 3DChris ---
Hello Everyone!
I'm new to the forums, but not new to SGIs in general. I first learned 3D animation on an O2 back in the early 2000's. I since bought an Octane system about 10-15 years ago and have upgraded it since then - Dual 600, V12, 4GB RAM, SSD Drive carrier, 1Gb Ethernet etc...
I haven't powered it on in about 10 years until today. I'm getting a solid red light on the front of the system. There's video output, but it just says, "running power on diagnostics" and never gets any further.
I pulled the system tray out to see if there was anything obvious, like leaking capacitors, battery acid etc... Nothing that I can see is wet or has any signs of corrosion (actually looks surprisingly new and dust free). I also pulled out the V12 board (with attached 1Gb ethernet card) and checked to see if there were any obvious signs of damage. Again, nothing. I plugged everything back in and made sure everything was tightly connected.
Still getting the solid light. Not sure what to try next.
chunk 0
Forum Thread: Video format (VFO) aggregator thread
Source: forums.sgi.sh
--- Post by bplaa.yai ---
Following recent discussions on the Discord, you can use this thread to share and reference any custom video format you built or found online.
Please include both VFO and VFS if possible, in case any ajustements are needed.
--- Post by Richard42 ---
Here are 3 video modes that I made:
1024x768 at 100Hz for Octane Vpro
1024x768 at 100Hz Stereo for Octane Vpro
1440x1080 at 60Hz for O2 CRM
--- Post by bplaa.yai ---
Attached is a 1920x1024 @60 for the O2 CRM.
It is probably the closest you can get to 1920x1080 at 32 bits / pixel on the O2, given the framebuffer limitations.
Please also note that the timings are intended for a flat panel monitor, so it may not work on a CRT.
--- Post by Richard42 ---
Here's another one - 1600x1152 at 55hz for the O2. We can't go over 55hz because the pixel clock will exceed the 144MHz limit, and we can't go over 1152 lines or else we will break the 128-tile limit. So this is about as close as we can get to a good 1600x1200 mode.
chunk 0
Forum Thread: Fuel repair attempt
Source: forums.sgi.sh
--- Post by rams ---
I got Fuel in a nonworking state and an additional CPU last year.
I have been slowly trying to get it working.
At first it didn't start up at all.
I connected console to L1 port on the motherboard.
First symptom was L1 not starting at all most of the time. Very rarely it would start.
I removed all cards, memory and V12, but it didn't help.
When it did start I got:
Code:
ALERT: Unknown PSC: 9
SGI SN1 L1 Controller
Firmware Image B: Rev. 1.14.4, Built 07/25/2002 13:34:38
001a01-L1>
I replaced the power supply with Akyga AK-B1-700BE and made ATX adapter myself. I used NE555 based square wave (50/50 duty cycle) generator for fan signal emulation.
I also replaced snaphat battery and DS1742W-120 with replacement from @cz7asm .
After replacing Dallas and snaphat battery the L1 was fixed.
I powered up with "pwr up":
Code:
chunk 0
Forum Thread: Indy Case Resurrection
Source: forums.sgi.sh
--- Post by legodude ---
There was an Indy on Ebay for a good price ($200 with Galileo and Cosmo cards). One small issue:
I started off with this:
Some careful piecing back together and I had almost all of the pieces:
I've had only so-so luck with super glue for this application so I decided to try some plastic solvent. I used Plastruct Plastic Weld from Amazon:
https://www.amazon.com/Plastruct-Plastic-Weld-applicator-Bottle/dp/B00FDFWJD8
I don't know if this is the best possible solvent, but I had pretty good luck with it.
chunk 0
Forum Thread: O2 AV1 video output ghosting issue
Source: forums.sgi.sh
--- Post by ArturaInd ---
I recently got an AV1 module for my O2. while the video capture looks clean and without artifacts (well as clean as composite video can be at least.) The output from this module however has been showing yellow ghosting to the left on icons and motif window elements (borders, buttons, title bars, etc). Images attached showing the ghosting effect on the desktop and color bar output. (this happens regardless of cable quality)
--- Post by stormy ---
I find these modules have a kind of yellow tacky substance that spreads/migrates across the PCB over time, I don't know what it is, perhaps something to do with the flux they used. It might be worth giving it an ultra-sonic bath (the pcb)
--- Post by ArturaInd ---
Ok good news, video playback out the AV1 has no problems. bad news: videoout is prob just screwed and bugged. Unsure if interlaced ogl out of av1 works, cant test.
chunk 0
Forum Thread: Double Panic on Indy at Startup
Source: forums.sgi.sh
--- Post by scavej0n_ ---
Hello everyone,
Two weeks ago, my Indy got a problem with the SIMMs so I replaced all the first bank.
Today I wanted to turn on the Indy to work with Maya, but it showed a Double Panic. I tried to restart from the little button under the power, but nothing. I also tried the old sticks and swap the banks, but the error still shows up. I attached an image of what happens on the screen.
How can I solve?
Thank you all,
With Love, From Venice
--- Post by legodude ---
I'm not familiar with error, so I may be off base, but I would try to gently clean the simm sockets with deoxit/contact cleaner
--- Post by scavej0n_ ---
legodude said:
I'm not familiar with error, so I may be off base, but I would try to gently clean the simm sockets with deoxit/contact cleaner
Click to expand...
I’ll try, then I tell you…
--- Post by scavej0n_ ---
Nope, RAMs are ok, but I'm still stuck
--- Post by jenna64bit ---
I'm not sure, but that can't be good. reseating things would be my thought too, but I guess not? Hopefully the CPU isn't just dead.
chunk 0
Forum Thread: Wiebetech ProSATA SS8 (SATA to SCSI RAID) Works!
Source: forums.sgi.sh
--- Post by stormy ---
Hi all,
I recently took the plunge on this awesome RAID enclosure:
I was warned by a few fellow members that it may/may not work due to IRIX being funny due to 32bit LUNs (or something along those lines) A few people had tried other solutions without luck.
I am here to report, this one works perfectly!
I simply set up 2x 120gb SSD's in RAID 0, assigned to SCSI ID 2 and LUN 0. IRIX picked it up without issue (Octane) Apparently Octane can do 40mb/s max, and this seems to be saturating it nicely. Here are my preliminary benchmarks. It seems to be outperforming the internal drive, especially on random access.
I've attached the user manual for this enclosure so it doesn't get lost.
External SCSI Wiebetech ProSATA SS8 using 2x Intel 120gb SCSI drives in RAID 0:
Code:
chunk 0
Forum Thread: A Mysterious Red Indigo2
Source: forums.sgi.sh
--- Post by bitpak ---
There's a picture of a red Indigo2 case with a strange badge floating around the internet.
Some say it was an early prototype for Impact systems.
To my eye it looks like a color corrected photo of a regular Indigo2 (hence the greenish reflection), but that's just me.
And that doesn't explain the strange badge. Until you look up old Alias site for StudioPaint 3D qualification charts..
Where it mentions Indigo2 KILLER Impact..
Pretty mysterious. What do you think? Maybe that was some SGI prank?
--- Post by johnnym ---
bitpak said:
There's a picture of a red Indigo2 case with a strange badge floating around the internet.
Some say it was an early prototype for Impact systems.
[...]
To my eye it looks like a color corrected photo of a regular Indigo2 (hence the greenish reflection), but that's just me.
And that doesn't explain the strange badge. Until you look up old Alias site for StudioPaint 3D qualification charts..
Where it mentions Indigo2 KILLER Impact..
[...]
Pretty mysterious. What do you think? Maybe that was some SGI prank?
chunk 0
Forum Thread: SCSI2SD v6 performance report
Source: forums.sgi.sh
--- Post by 23jodys ---
The host: a R5K/180 Indy.
Note: the Indy and scsi2sd required a terminator on the external scsi port. I don't normally leave one there, but the system would hang and crash without it.
The adapter: SCSI2SD v6.
SCSI2 turned on. Parity turned on. Set to 10MB/sync. 2GB allocated in the scsi2sd-util. FYI, you definitely need to have an SD card inserted for anything to work.
The SD card: Sandisk Extreme 128GB (this is A2 rated which is supposed to help with small random reads/writes)
The results.
Code:
chunk 0
Forum Thread: Indigo 2 boot error at startup
Source: forums.sgi.sh
--- Post by graphox ---
First time posting on here! It has been a dream of mine since the 90's to own a SGI Indigo 2 since I only ever had access to a remote shell and never got to experience the physical hardware.
I managed to acquire an Indigo 2 R4400 XZ Extreme via a seller. It was shown to work but I am not sure whether something got messed up in the shipping even although it was well packaged.
It does have a hard drive sled with a bootable SCSI disk inside, however whether the sled is slotted in or not the error message at boot remain the same. I attached a picture.
Does anyone perhaps have any tips for a complete newbie to trouble shoot this issue ?
--- Post by legodude ---
Press any button, then I assume you are shown a screen with options including "start system." Click "enter command monitor" and type hinv and then put a photo of the results here - that will show you if the had drive is detected or not
--- Post by graphox ---
legodude said:
chunk 0
Forum Thread: FIX: audio output switching / Indigo2
Source: forums.sgi.sh
--- Post by stormy ---
Just documenting this fix for anyone else who comes across this problem. My Indigo2 started having an issue where the internal speaker stopped outputting sound, this was after plugging in an external speaker jack. For some reason it would not go back to the default internal speaker as it should, and there are no software controls for this in IRIX, it should be automatic.
I replaced the EB2-4.5NU relay on the sound board with a new one, this fixed the issue for me. If you're wondering why I have replaced the Tantalum caps with polymers/lyrics. It's because of previous reports of these tantalums exploding on other people's machines, I just wanted to avoid that on mine.
Here are some photos:
chunk 0
Forum Thread: A custom paint job for my Onyx2
Source: forums.sgi.sh
--- Post by Irinikus ---
I'm going to start this thread off by stating that I'm a purist and generally like to keep things as original as possible!
About four years ago I managed to snag my Onyx2 from a surplice reseller in Israel. It was originally used in a Flight Simulator (More than likely from their military)
It came fitted with Four R14K's@500MHz (Top spec for such a machine), 1GB of RAM and an Infinite reality3 graphics system.
Here's a pic of the original set of modules that came in the machine:
Although is was a highly specced Onyx2, its plastics were scuffed to a point where it wasn't aesthetically pleasing to look at. (So I very quickly got on the task of flatting the plastics, with the intention of painting it in the future.) It ended up remaining in this state for a few years until I eventually got around to giving it a coat of paint.
I have since upgraded the machine with the following modules:
A DG5-8:
And two RM11's: (To get it up to the IR4 spec)
Here's a closeup of an RM11:
chunk 0
Forum Thread: Octane Short/PSU Problem
Source: forums.sgi.sh
--- Post by bnoji ---
I acquired a base model Octane (CMNB015ANF175) this weekend along with a second PSU. The previous owner said it was in use, froze while running and wouldn't boot again after that. He bought a new PSU and it still didn't work.
I plugged it in and both the chassis fan and PSU fan spin up for a second until the relay clicks and it shuts off and sits idle with a slight buzz. It sounds (and smells) like a short somewhere. I pulled the power supply out but I can't tell if that smell was from the chassis or the PSU. I opened the PSU and there's nothing obviously smoked and both fuses were fine.
The other PSU doesn't do anything so I'm assuming that's the bad one.
Are there any points on the boards where shorts are "common"? I'd hate to buy a third power supply only to find out it's a short on one of the boards instead. It seems like this PSU is working but hits some over current protection or short protection and it shuts down.
Edit: The one that doesn't do anything is a Lucent and the other is a different manufacturer.
chunk 0
Forum Thread: Power Supply Capacitor Lists
Source: forums.sgi.sh
--- Post by legodude ---
Please post any power supply capacitor lists that you have!
Indigo2 Impact: https://www.digikey.com/en/mylists/list/9FRD53TYGP
Not my pictures or list - stolen from discord. I will be ordering to check out.
--- Post by stormy ---
o2 PSU cap's:
Control board
0.47uf 50v x4
1uf 50v x2
220uf 16v
100uf 10v
22uf 16v
4.7uf 25v
Main PCB
220uf 450v (25mm width 45mm height)(10mm lead spacing)(pc pin)
22uf 50v
100uf 35v
220uf 16v x3
22uf 50v x3
180uf 25v
2200uf 6.3v x2 (10mm width 25mm height)(5mm lead spacing)
2200uf 25v x2 (12mm width 35mm height)(5mm lead spacing)
10,000uf 6.3v x4 (16mm width 35mm height)(7.68mm lead spacing)
Click to expand...
--- Post by Richard42 ---
Octane Lucent 623W PSU - All capacitors plus failure-prone AC/DC converter:
chunk 0
Forum Thread: "Reverse" SCA Adapter
Source: forums.sgi.sh
--- Post by legodude ---
I occasionally want to plug a non-SCA SCSI device into a backplane SCA connector. This would be even more useful when we get faster ZuluSCSI devices. I wanted to document my (failed) attempt.
There is one such commercial adapter that I know of:
Narrow 50 – SCA-80 Male Converter
cs-electronics.com
We contacted the company and were quoted ~$150/ea. I can't find any vendors online.
An obvious solution is to design and fab a PCB, but I wondered if a standard SCA adapter could be modified to work. I thought the clearances might be tight, but doable.
I started off with a standard SCA adapter and some Aliexpress SCA male connectors.
With the use of a desoldering gun and hot air, I was able to remove the female SCA connector.
In order to keep the pinout correct, you have to flip the placement of the SCA male connector (so it is on the opposite side of the PCB)
chunk 0
Forum Thread: IRIX install on ZuluSCSI
Source: forums.sgi.sh
--- Post by Jamieson ---
I've got a Indy and a ZuluSCSI card and I'm about to start on an IRIX install.
Seems like most folks are either installing from a SCSI CDROM drive or installing over the network.
I'm planning on loading the install disc images directly on the ZuluSCSI card, which claims to emulate a SCSI CDROM directly, then installing from there.
Has anyone tried this?
--- Post by Elf ---
I have not tried it that way specifically but have done similar things with Sun machines and the SCSI2SD (v6). I expect it would work at least to boot the installer? However you may have trouble swapping discs unless there is some sort of way to poke it to do that. I know that RASCSI has some sort of web UI to allow you to swap discs.
--- Post by trixster1979 ---
It should work fine. I used a zuluscsi to mount the install cd to start a miniroot, so there’s no reason irix shouldn’t install fine from an sd card with all the images mounted.
chunk 0
Forum Thread: 3Com 3C996B-T 10/100/ 1000Mbps PCI-X RJ45
Source: forums.sgi.sh
--- Post by draconpern ---
3com 3c996B-T cards are plentiful on ebay, and since I didn't see any documentation on making it work for SGI...
Here is what I used to reprogram a 3Com 3C996B-T card to be usable on SGI Fuel. It makes it look like a 3C996B-T-SGI1 (part) 9210289. Please note this doesn't work on 3C996B-SX fiber version of the card.
You'll need an older PC motherboard with a PCI bus, PCI-X not required because it's compatible. And linux mint 21 (ubuntu probably), ethtool is available on the normal download, live cd mode. No installation required. Just substitute eth0 with the right device from ifconfig -a. Mine is enp1s2, yours will be in the form of enpXsY.
First backup the old information somewhere. If you are using linux mint live environment, be sure to save it on usb or network, etc.
Code:
sudo bash
ethtool -e eth0 length 4 offset 0xa4 raw on > 0xa4.bin
ethtool -e eth0 length 96 offset 0x100 raw on > 0x100.bin
Then to program the card.
Code:
chunk 0
Forum Thread: Indy + CrystalEyes 3D Glasses
Source: forums.sgi.sh
--- Post by zoggins ---
I have an Indy and a working emitter/glasses combo and I cannot figure out how to get them to work. This page ( https://wiki.preterhuman.net/Stereographics_on_SGI_systems ) says to select a resolution with an "s" at the end, but I have none of those in my xsetmon. No clue what the secret it is to using them. Any advice? Thanks!
--- Post by weblacky ---
What CRT monitor are you using?
chunk 0
Forum Thread: Octane Gigabit Ethernet in 2025
Source: forums.sgi.sh
--- Post by legodude ---
I finally got a PCI card cage for my Octane, so gigabit was the next thing to work on.
There are a couple options for this, but the quickest and easiest seemed to be outlined here:
supported (non SGI) PCI gigabit cards? - Page 4 - Nekochan Net
The first order of business is getting the correct card, a HP NC7770 , not a NC7771 . Beware, some sellers will advertise a NC7770 but then have small print saying "or similar" and send you a NC7771. This is how I ended up with a stack of NC7771s (which can be reflashed for use in alphas, so all is not lost). I had to find an auction that had a picture of the actual card, it was $17 shipped.
Once you put the card in the system, you simply follow the instructions on the Nekochan post. I've attached a modified if_tg.o for 6.5.30. Put it in /usr/cpu/sysgen/IP30boot , and then you are a autoconfig -vf away from gigabit:
--- Post by stormy ---
Thanks for documenting. Original SGI units are getting harder and harder to find these days.
chunk 0
Forum Thread: Indy Etch A Sketch
Source: forums.sgi.sh
--- Post by pauliedweasel ---
Finally unboxed this bad boy.
--- Post by legodude ---
You do need to provide more context
--- Post by joshyfishy22 ---
Lovely, Was this a custom job or a sgi promotional item? I believe you told me that it was a promotional item they had given out to a very small batches. But it didn't actually contain a full indy.
chunk 0
Forum Thread: O2 Memory Slots being bad
Source: forums.sgi.sh
--- Post by joshyfishy22 ---
Hello Everyone, Im trying to take an inituative to post more and be more active on the forums for ease of sorting information thats going on in the discord.
Today the user @stormy had mentioned in #Hardware in the sgug discord that he believes that the o2 ram slots are kinda junk. Which I can agree with due to the contacts not being gold plated. He had an issue with a system not booting due to ram issues and only solution was to shove cardboard into the slot and pull it back out and then it would work.
I was just wondering if anyone here has any similar issues with RAM and the O2?
chunk 0
Forum Thread: SGI Origin 300 supported hard drives?
Source: forums.sgi.sh
--- Post by jander31 ---
Hello, I hope all is well.
I purchased my first SGI server today, an SGI Origin 300, and was also given an SGI NL4R router module for free. The Origin 300 starts up with no glaring issues, and I purchased a set of drive caddies for it. The only issue now is finding a suitable SCSI drive that will work, in addition to installing IRIX (I know the Origin 300 uses the ARCS firmware bootloader, which will affect a line or so during installation). If anyone could recommend a decent drive, not looking for a ton of storage (just enough to run some compute-related tasks remotely), I would really appreciate the assistance!
Also not really sure what to do with the NL4R, as it relies on DC power.
(Ignore the R730xd, it's a bit crowded in my dorm room)
--- Post by joshyfishy22 ---
Nice find. Mind I ask where did you get this from? For the drives, any scsi SCA drives will work. I recommend the HP 300gb SCA drives you can find on ebay. These drives have the long 80 pin single connectors on them.
chunk 0
Forum Thread: Guiness Prototype
Source: forums.sgi.sh
--- Post by elitedev ---
Hi everyone, I just wanted to share some photos with people more knowledgeable than myself.
Today I came across this computer with appears to be a prototype or pre release version of the SGI Indy. I've included photos of the outside of case.
I don't know a lot about these models, but I did notice that the logo placement is different from the R5000 version (the logo is on the opposite side) and has the same painted version of Indy logo as the other ones I see online, in the normal position.
There does appear to be what looks likes a signature on the top in marker, but it's too faded to make out.
The main obvious difference was the sticker on the bottom validating that it's not FCC certified, no serial number, pre-release and not for sale. It also appears to have a corporate SGI asset tag on it.
I have not opened it or attempted to power it on in case, so I don't know what's installed on it.
Have you seen anything like this before? Or possibly know how this could have ended up in a storage locker in Canada?
chunk 0
Forum Thread: Need to power a Virtual Research V6
Source: forums.sgi.sh
--- Post by cyvoid ---
This isn't directly SGI hardware, but one of the recommended uses of this HMD was with SGI workstations, so I've been told to post about it here. Instead of typing EVERYTHING whenever I ask someone about it, I wrote a article with pictures . The short story is: I have a virtual research v6 hmd with no power adapter, I need something to power it
chunk 0
Forum Thread: vw320 post clock error scrolling cant access arcs
Source: forums.sgi.sh
--- Post by krzrsms ---
Hi all. This forum has the most recent posts on VW 320s that I can find. Hoping someone here can shine some light on how to proceed.
My 320 used to run. After several years I went to start it up. I realize the cr2032 battery ran out. That of course means the clock needs set. With the dead battery, after changing it, and without a battery the same issue arises:
I know that normally to get to the arcs prom you'd hit escape to set the clock. When starting up however as soon as the 1st screen comes up the error screen not only comes up but continuously scrolls by, and no amount of pushing escape makes any difference. Ive tried dozens of times with multiple 3rd party keyboards and even without a keyboard in case they were causing the scrolling effect. No joy.
The only internet forum post I can find that is partially helpful suggested booting with no cr2032 battery. I also tried this as mentioned above but it didn't solve the problem.
Is there some other way to get that clock set or enter the prom?
chunk 0
Forum Thread: Found on eBay: Green Indy - superCluster - IATS Silicon Graphics Network
Source: forums.sgi.sh
--- Post by oliverx74 ---
*LOGS INTO IRIX!* Silicon Graphics SGi Indy R5000 150Mhz 64MB 2GB "superCluster" | eBay
PROM boot reports errors (due to lack of its super-dead superCluster network), but login screen accepts "root " with no password! 150Mhz R5000 with. Running IRIX 6.5. From the very last model line update produced of the Indy in 1996.
www.ebay.com
Never saw this before and couldn't find any info about it, but it looks great. Maybe anyone here knows anything about it?
--- Post by weblacky ---
Sorry to be the bearer of bad news but that wasn't originally green. You can see in the center how it's more blue. Indys turn green under a certain amount of sun damage. This is so extreme that most of the time the brittleness has destroyed the case by now. But if you look between the front grill and about an inch before the word Indy you'll see that it's still quite a bit blue.
So while black Indy's have existed do the re-badging, this is a normal blue indy that has sat in direct sunlight for 20+ years.
chunk 0
Forum Thread: Sgi Indigo , no keyboard issue
Source: forums.sgi.sh
--- Post by megaimg ---
Guys, need to verify, I am trying to get an Indigo R3K back online....so far, I was able to get the PSU working, but now it doesn’t detect the keyboard. I know is not a PS2, but I have an adapter. If someone can take couple of measurement. Pin4 of the Keyboard connector I know is 8v and Pin6 must be around -8v but I am getting -4v, can someone confirm.... I think that the previous owner plugin a PS2 Keyboard and damage it. I fallow the schematics pin 6 ends in Pin 8 of the U44 (SN74LS125AM). From U44 it continue to the DSP Pin 28 (TXD). the DSP U32 control the SCSI. Any feedback will be appreciated.
--- Post by luminescentsimian ---
I just poked at my (new-to-me) Indigo R4k and got +12 on pin 4 and -12 on pin 6. I did see -4.4 on pin 5 and 2.3V on pins 1 & 2. All referenced from pin 3 on the middle-right(down) of the connector. I don't have a keyboard to confirm that is 100% proper.
--- Post by Roostie02 ---
luminescentsimian said:
chunk 0
Forum Thread: EEPROM-Error on Onyx2
Source: forums.sgi.sh
--- Post by gandtimo ---
Hi there,
I've got a big problem with my beloved Onyx2.
Last week, suddenly after rebooting the machine, no gfx was put out. I connected to the serial console and was greeted with the following:
Code:
Discovering NUMAlink connectivity ......... DONE
Found 2 objects (2 hubs, 0 routers) in 10475 usec
Waiting for peers to complete discovery.... DONE
Global master is /hw/module/1/slot/n2 Testing/Initializing all memory ........... DONE Checking partitioning information ......... DONE Loading BASEIO prom ....................... DONE
BASEIO PROM Monitor SGI Version 6.156 built 11:26:28 AM Nov 18, 2003 (BE64)
4 CPUs on 2 nodes found.
Installing PROM Device drivers ............
Base I/O Ethernet set to /dev/ethernet/ef0
Installing Graphics Console...
graphics install: searching for pipe 0
Checking out EEPROM
address = 87ff00, limit = 87ff30
EEPROM state = 10101012
Warning: Found Bad KONA eeprom: 0x10101012
: Not Adding gfx device - gfxpipe
kl_graphics_install: installation failed for /hw/module/1/slot/io4/kona
chunk 0
Forum Thread: Oxidation on qLogic-controller?
Source: forums.sgi.sh
--- Post by MatzeLoCal ---
Hi,
recently I bought an Octane for a very good price. The machine runs well but yesterday I pulled out the graphics board and the mainboard.
All looked well except this on the motherboard. I'm not sure if that's oxidation and if the packaing of the chip is breaking of.
It's only this location which looks ugly, everything else looks pretty clean (except dust).
Is this concerning?
--- Post by joshyfishy22 ---
It looks to me more like a glue or paste. Do you know if the octane was stored in any moist area (Does the chassis show any oxidation?) It shouldn't be a problem but if it bothers you id use some 99% IPA to gently clean it off.
--- Post by MatzeLoCal ---
Thanks for your reply.
Unfortunately I don't know where the Octane has been stored over the last years. But the rest of the system looks fine and there is no corrosion or so. It's just that bit and I'm not sure what worries me more the white (oxidation) stuff or the broken of bits of the Chip.
chunk 0
Forum Thread: Post issues on Indy
Source: forums.sgi.sh
--- Post by gdog0622 ---
Hi yall
Recently I saved my first SGI computer
This Indy is in rather bad shape as it was left in a humid environment for years
The issue I’m currently having is the machine not starting at all
When plugged in and power button pressed the led turns red note that once button is pressed again it does not turn off
The chips on the graphics card get nearly too hot to touch
I’ve checked the voltages and they are all in spec
The fan doesn’t spin up leading me to believe that the motherboard isn’t properly communicating
Some other notes
The computer draws about 50w when turned on and the graphics chips do get warm
The power is good even from the molex connector
There are no drives at all
The heat sink on D103 has 120v AC
The PSU is a Sony
Again the machine was left in a humid environment so there was corrosion on some parts that I cleaned with IPA
--- Post by gdog0622 ---
The next heatsink over has -160v DC on it which i suppose both of these voltages could be fine assuming they aren't supposed to be insulated
chunk 0
Forum Thread: Origin 350 replacement PSU baffle
Source: forums.sgi.sh
--- Post by Woof ---
I'm sharing this with anyone who's missing a PSU baffle in their Origin 350/Onyx4 (after removing the second PSU, for example). It's a 3D printable drop-in replacement, part number 050-0866-002. I printed mine in PETG which should be fine with the temperatures in the PSU bay. It ensures the correct airflow when only one PSU is fitted.
Attached in the zip is a choice of STEP or STL depending on your slicer's compatibility. It should be printed hole-side down, designed to not require support material due to the pyramidal tops. An optional pair of small 'plugs' will flatten the hole bottoms for aesthetics.
chunk 0
Forum Thread: Iris Indigo R4k and 32MB RAM modules
Source: forums.sgi.sh
--- Post by altstar ---
Hi,
I'd like to upgrade my Indigo to the 384MB using 32MB modules. Does anyone know if the IBM 39H8312 32MB ECC memory modules would work (or can suggest ones that do)?
Regards
Christoph
--- Post by joshyfishy22 ---
Typically the 72-pin simms that the R4k systems use really only require fast page mode with parity thats around 70 or 60ns. Iv never seen an indigo with more than 192mb of memory in it. Those IBM sticks look like they would work but sometimes throwing RAM at these machines and seeing what will stick is a difficult thing to do.
Currently im waiting for an R4k Indigo in the mail since my 2 indigos have dead system boards in them. Hoping to test my box of 72-pin simms to see what works.
chunk 0
Forum Thread: Need comments/suggestions on replacing Indigo2 motherboard
Source: forums.sgi.sh
--- Post by rjm957 ---
I have a 195 MHz R10K motherboard that I want to replace in a "non-working" Indigo2. I would appreciate any advice on this, since I am not sure how to remove the EISA daughter board. I've built PCs in the past, but I'm a little bit clueless with how to approach the Indigo2.
--- Post by legodude ---
There is a screw going into the riser carrier from the back of the case. There is another screw roughly in the middle of the riser, right where it plugs into the system board. I can't remember any other screws. After that, it should come out easily with gentle upward traction.
On my non-impact system, replacing the riser is easy. On my impact, the system board would flex and I could not get the riser to seat properly. I had to remove the screws holding the PCB to the carrier. That would allow me to put a little more force on riser to get it to seat, then screw it into the carrier.
--- Post by 0xDEADBEEF ---
I did replace mobo to upgrade my I2 to R10K. It is straightforward, just a lot of screws to remember.
chunk 0
Forum Thread: Fixing the Indigo2 TRAM problem
Source: forums.sgi.sh
--- Post by CB_HK ---
Hello everyone! This post will detail a recent project in which I decided to solve the overheating TRAM issue that plagues High and Max IMPACT board sets that have the TRAM option boards installed. Additionally, I reworked the cooling setup by way of adding a PWM controlled fan that responds to compartment temperature and is rated at twice the cubic feet per minute and three times the static pressure of the stock Panaflo fan.
Problem 1: IMPACT TRAM modules are known for failing over time. This is noticed by the artifacts that are shown on screen when dealing with textures. Usually it begins to show by alternating lines that are missing (wrong color, white, etc.) and over time the issue can become more apparent until most of the textured image is obscured by these artifacts.
So HOW does this happen?
chunk 0
Forum Thread: Monitor flickers on and off
Source: forums.sgi.sh
--- Post by gmcenroe ---
I had not booted up my Indigo2 for several months. I am using a Dell Monitor that I have used in the past without a problem. When I bootup I get the initial screen indicating boot process has begun, then screen goes black and after about 30 seconds the login screen comes up. After I log in the screen looks fine, there is some wavering of the image near the top corners but it goes away. When I start a process from the drop down menu, the scree goes blank again and then after 10-20 seconds it comes back up where it left off. This screen blanking and coming back on seems to happen whenever I start something new. I a letting the screen saver run with the whales and it seems to be running continuously.
Is this a power supply problem or graphics card problem?
Suggestions for what tests to run would be helpful. Thanks,
Glenn
--- Post by mc68k ---
Same issue here but only with certain monitors (Samsung Syncmaster 19" LCD). Try a different monitor (Sony, Dell LCD...).
chunk 0
Forum Thread: Looking to Buy SGI Octane2 or Tezro in Good Condition
Source: forums.sgi.sh
--- Post by catusr ---
I live in South Korea and am looking to purchase a Silicon Graphics (SGI) Octane2 or Tezro in good condition. If any members have one for sale or know of a reliable site where I can buy one, please share the information. The listings on eBay seem suspicious, so I’d like to be cautious.
--- Post by jenna64bit ---
Thanks! I don't think we have a lot of members in that part of the world sadly. Personally, even from the US here, I often look on yahoo auctions Japan for that.
chunk 0
Forum Thread: Slow SCSI2SD V6 on an Indigo 4K (and diskperf errors)
Source: forums.sgi.sh
--- Post by altstar ---
Hi,
I'm trying to work out why my Indigo 4K "feels" so slow and thought I start with running diskperf as I'm using a SCSI2SD V6. Diskperf runs but I get lots of pread/pwrite errors. Are those expected? Also, throughput looks rather low. Should I try a SCA SCSI HDD + adapter instead?
Regards
Christoph
IRIS 5# diskperf -W -D -r 4k -m 4m testfile
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name : Unspecified
# Test date : Fri Jan 27 21:20:35 1995
# Test machine : IRIX IRIS 6.5 10070055 IP20
# Test type : XFS data subvolume
# Test path : testfile
# Request sizes : min=4096 max=4194304
# Parameters : direct=1 time=10 scale=1.000 delay=0.000
# XFS file size : 0 bytes
#---------------------------------------------------------
# req_size fwd_wt fwd_rd bwd_wt bwd_rd rnd_wt rnd_rd
# (bytes) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s)
#---------------------------------------------------------
pwrite() : Invalid argument
pwrite() : Invalid argument
pwrite() : Invalid argument
chunk 0
Forum Thread: Indigo 2 Impact PSU dead, diagnosis & advice
Source: forums.sgi.sh
--- Post by stormy ---
Hi people,
I'm attempting to diagnose a Zytec 22943507 Rev C for Impact Indigo 2 systems.
PSU details:
Description of fault:
Absolutely no output when power applied. Connecting 'run' pin 11 to 'standby 5v' pin 5 does not start the PSU. No output on pin 5 'standby 5v' at all.
Some things already done: Replaced most of the capacitors on both HV and LV sides, as suggested on Ian Maplesons guide. The only caps not replaced yet are the super-large two on the HV side and the 6800uf caps. I have also re-soldered most points on the boards that get hot, to make sure the solder is good. None of this helped.
In-depth testing:
I do not have an impact graphics terminator, it wasn't attached to my PSU like others, so I had to make one from scratch:
I measured which side was GND and plugged the sense cable in for black to GND yellow to 3.5v.
Another thing I was interested in was the initial AC filter. I tested the continuity and it all seemed fine. I opened it up and took a picture just for the record:
chunk 0
Forum Thread: O2 CD tray, worth fixing?
Source: forums.sgi.sh
--- Post by telackey ---
My R5k O2's CD tray just started misbehaving. The tray itself moves freely (I can pull it out or push it back in manually with little effort) and when I restart the machine, it makes a pretty terrible noise for a few seconds. In the startup sequence it reports the drive is "not ready".
I suspect this is the common problem where the little white plastic gear has fallen off its spindle. I am kicking myself for having opened the tray at all...
If the problem is what I think it is, it doesn't sound too hard to fix, but it means taking off the skin. At the moment, I am more scared of breaking the skins in the process than I am bothered by the CD (I can't recall the last time I used it).
Is this worth fixing, or should I just leave it be?
chunk 0
Forum Thread: Indigo smd id
Source: forums.sgi.sh
--- Post by vintech ---
I have an Indigo CPU board IP12 with a broken smd. I can't tell if it is a inductor or a resistor, the device marking is Dale 102 933, the silk screen list a L?? other smd's close to it list as L38, L39 etc..
--- Post by SolusRaion ---
Photo would be great
chunk 0
Forum Thread: Trying to buy an Onyx deskside near Portland Oregon
Source: forums.sgi.sh
--- Post by RaptorDesu ---
Let me know if you have any leads.
--- Post by SolusRaion ---
Onyx one or two? There is a significant difference.
--- Post by RaptorDesu ---
1, onyx 2 is a little big for my apartment
--- Post by SolusRaion ---
Uhh they're close in size
--- Post by RaptorDesu ---
Well that depends. One is a half sized deskside or can come in a full sized rack. But so is the onyx2. But onyx2 most commonly come in a rack configuration atleast in my experience. Therefore the onyx 2 is usually bigger in size. I would rather have an onyx 1. They more commonly come in deskside form factor and look cooler
--- Post by SolusRaion ---
I will contact my colleague out there. Runs a computer recycling business out of Northern California sometimes he finds rare stuff and puts it aside. He doesn't like destroying history.
--- Post by RaptorDesu ---
SolusRaion said:
Uhh they're close in size
Click to expand...
SolusRaion said:
chunk 0
Forum Thread: Sgi O2 auction closes today
Source: forums.sgi.sh
--- Post by axx0009 ---
There’s an sgi o2 and various vintage towers being sold by the university of Washington today
https://www.govdeals.com/asset/5880/6794
--- Post by siliboi ---
axx0009 said:
There’s an sgi o2 and various vintage towers being sold by the university of Washington today
https://www.govdeals.com/asset/5880/6794
Click to expand...
Wow wonder who the lucky buyer was
--- Post by mgtremaine ---
There was a Quadra 700 in there also.... imagine the hours messing around with all that vintage gear.
-Mike
chunk 0
Forum Thread: Octane PSU Repair - Click of Dead
Source: forums.sgi.sh
--- Post by megaimg ---
Couple of weeks ago, I salvage an Octane, for my disappointment the PSU was behaving what everyone calls the click of dead. So, I post couple of messages on this forum and decided to take it on myself to try to fix it.... After fixing the SGI Fuel PSU (Sparkle Power Int Model FSP460-60PFN - Look at my other post), I was up for the challenge.
This is for The LUCENT TECHNOLOGIES 060-0028-003 623W
First, disassembly: (Sorry forgot to take pictures)
NOTE: You will be dealing with high voltage components, High Voltage Capacitors can hold charge, I cannot be responsible, do this at your own risk
The Unit is based on 3 different PCB units’ stock together on the metal enclosure. This is not rocket science. You keep track of the screws
Top PCB is hold by 4 screws. There is a cable that connect the top PCB with the middle one, easy to remove. The white external plug is easy to use a pair of needle pliers to push the connectors (don't unplug it from the PCB).
chunk 1
can be 3.3 or 5V.
PCI Type and Version Chart
Model Brick or Shoebox 33 MHz 66 MHz 100 MHz 133 MHz 32 Bit 64 Bit PCI-X 3.3V 5V O2 1 1 X Octane XIO PCI
1 slot 1 1 X Octane XIO PCI
3 slot 3 3 X Fuel 2 2 4 X Tezro Tower 7 7 X Tezro (1) Rack 1 2 3 X Tezro Rack Expansion 4 4 X Origin 200 Module 3 3 X Origin 200 Expansion 3 3 X Origin 200 GIGA channel 4 4 X Origin 2000 / Onyx 2 (2) XIO PCI 1 slot 1 1 X Origin 2000 / Onyx 2 (2) XIO PCI 3 slot 3 3 X Origin 300 / Onyx 300 Compute 2 2 X Origin 300 / Onyx 300 PCI 12 12 X Origin 300 / Onyx 300 PCI 12 12 6 6 Origin 350 / Onyx 350 P 12 X Origin 350 / Onyx 350 P 12 X Origin 350 / Onyx 350 / Onyx 4 (1) Compute Base 1 2 3 X Origin 350 / Onyx 350 / Onyx 4 Compute Expansion 4 4 X Origin 350 / Onyx 350 PCI-X 4 4 X Origin 350 / Onyx 350 MPX 4 4 X Origin 3000 / Onyx 3000 I 3 2 5 X Origin 3000 / Onyx 3000 IX 11/12 11/12 X Origin 3000 / Onyx 3000 P 12 12 x Origin 3000 / Onyx 3000 PX 12 12 X
(1) Origin/Onyx 350 Compute Base and Tezro Rack have 3 slots available, the IO9 card (bus 1, slot 1) requires that the bus 1 slot 2 card be 66 MHz
(2) Origin 2000 / Onyx 2 Use the same Bridge ASIC - IO6
Maximum Transfer Rates
chunk 1
s cleanup.
After removing the CPU, clean off the pads using solder wick and a soldering iron (and flux). When done, clean the area well with IPA so none of the old flux remains.
5. Solder RM7000C
Add flux (if your RM7000Cs were exposed to the elements and the solder balls are quite oxidized, use some aggressive flux, like the Alpha OM-338. Aternatively, add flux to the CPU balls and do a reflow only on the CPU so that the oxides are gone) and place the CPU reasonably aligned with the silkscreen drawing. Use preheater/hotplate and hot air.
6. Set the VCORE regulator for 1.2V output.
The VCORE regulator on the RM5271/RM7000 is set to 2.5V. For the RM7000C it needs to be set to 1.2V
Remove R46 resistor and solder a zero ohm resistor (or jumper wire) in place of R50.
7. Glue the heatsink back on
Using thermal plaster or similar, glue the heatsink to the newly installed CPU
8. Remove the Xilinx PROM and solder the O2 PROM emulator FFC in place. Connect the FFC to the PROM emulator.
9. Configure the PROM emulator.
Connect an USB cable, type setup, select RM7000C. If the default settings are fine with you, simply choose 4. default RM7000C 600MHz tertiary cache on .
chunk 1
testing.
The board implements USB CDC-ACM. When connected to a computer, a virtual com port device will be crated. Use a terminal emulator set to 1152008n1 to communicate with the PROM emulator.
The USB cable can be connected for configuration with just the bare PROM emulator, PROM emulator connected to the CPU module while the system is off or PROM emulator connected to the CPU module while the system is on. USB cable is not needed for powering the emulator, it can be removed after configuration (or kept in place, it doesn't matter, it won't damage the CPU module even if it's powered by USB and the system is off).
Bitstream custom configs are non-volatile. The last bitstream set/configured (from the predefined list or custom set) will be loaded automatically every time the CPU requests it. For testing various things, one can leave the USB cable connected, configure the bitstream and simply reset the O2. New bitstream will be piped out immediately.
It can be soldered in place of both 3.3V and 5V devices.
Installation procedure:
-locate PROM device
-desolder PROM device
-solder FFC in place
-connect FFC and place the board where you think it's best
chunk 1
ts from the PROM (although it never stops the clock and it seems that there is some data at the end of the PROM).
For the R5k 180MHz 512kB module, this is the bistream that is read (left is bit 0):
000000001010101000001000000000000100010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Bit0 to bit17 are configuration bits, bit 18 up to bit 255 are marked as reserved. However, bit 20 33 37 are set to 1. This is fine, because:
Here is what that bitstream actually means:
Bit 0 - reserved
bit0 = 0
Bits 1:4 — XmitDatPat (block-write data pattern)
bits1..4 = 0000b = 0
Meaning: DDDD (no interleaving)
Bits 5:7 — SysCkRatio (PClock = SysClock × multiplier)
bits5..7 = 000b = 0
Meaning: Multiply by 2
Bit 8 — EndBit (endianness, OR’d with BigEndian pin)
bit8 = 1
Meaning: Big-endian (OR'd with the BigEndian pin)
Bits 9:10 — Non-Block Write mode
bits9..10 = 10b = 2
Meaning: Pipelined writes
Bit 11 — TmrIntEn (timer interrupt on Int*[5])
bit11 = 0
Meaning: Timer interrupt enabled
chunk 1
vidual parts of the model!
I've started off by working on the main plastic body of the O2. (So this is the first part that I've freed up.)
This was the first iteration of the cleanup process:
I'm in the process of replacing all of the triangles with quads. This has to be done manually and is incredibly time consuming! (It's basically going to be a complete rebuild!)
Here's the second iteration: (I cannot use mesh smooth on this model, so all of the smoothing has to be done manually, meaning the manipulation of the individual vertices!)
This is going to be an incredibly long process, but it should hopefully be worth it in the end!
Here's how I've modified the mesh so far:
--- Post by Elf ---
Nice work, thanks for putting in the effort
--- Post by Irinikus ---
Elf said:
Nice work, thanks for putting in the effort
Click to expand...
It's a pleasure!
--- Post by khral ---
Ooh, this would be a good starting point for 3D printed O2 skin recreation/replacement in future!
As O2 skin is brittle and often get damage during shipping these day.
chunk 1
I can get a slightly different bracket for the board. Maybe the problem is general, or caused by distortion to my O2.
I'm sure summarizing the issue here helped me find the solution!
Thanks, Phil.
Hi. I'm having problems with my ZuluSCSI in an R5000 O2, with two drive sleds.
I have been periodically cloning my system drive to a second hard drive, in sled 2, using the method on this page http://www.sgidepot.co.uk/disksfiles.html#CLONE
and had hoped to use this system to clone to the ZuluSCSI SD card instead. My current installation is 6.5.27, with about 60GB of files.
However, so far I have been unable to get the ZuluSCSI working in sled 2, SCSI ID 2.
I have updated the Zulu firmware using ZuluSCSI-FW_2026-01-24-universal.zip
I have downloaded the Irix 6.5.30 image file from https://archive.org/details/sgio-2-zulu-full
I formatted a microSD card using the official SDformatter app, then loaded the image file as HD1.img. If I put this in sled 1, then the O2 will boot and run that installation as expected. I can read and write files.
If I add a hard drive in sled 2, this is detected by 'hinv', and shows as an umounted disk in the File Manager.
chunk 1
able.
My Dell SE2416H always displayed a green tinted image, and according to the manual it does not support sync on green. However, this is how it looks after removing the hsync and vsync pins:
So it is worth a shot even if your monitor does not officially support Sync On Green (at the cost of a VGA cable).
2. Your monitor supports sync on green, but the image sometimes looks OK, sometimes has a green tint.
Same as the above, sometimes the monitor decides to go on the separate syncs route, and the green doesn't get decoded properly.
Fix is the same, remove HSYNC and VSYNC pins (13 and 14) from the VGA cable.
3. Your monitor does not support sync on green.
In this case, the O2 can be persuaded to output a standard VGA signal, without sync signals embedded in the green channel.
This is a hardware mod, it might be possible to convince the GBE/EVIL to stop outputting the composite sync signal, but I have no clue how to do that at the moment.
The O2 uses an ADV7120KS140 DAC. It is located near the VGA connector, here:
chunk 1
ould be blinking amber if it got to the point of checking the RAM).
However, without a CPU module installed, it gave a solid red light. So at least it tries to do something when a CPU is installed.
Checked for shorts, broken components, broken traces, broken solder joints (CPU module connectors), power rails were all good, oscillators were all good.
So maybe the board is trying to start up, but something is wrong. Either some broken ASIC, or, corrupted PROM.
The PROM resides in the flash underneath the Dallas IC:
Now, I really don't want to use hot air to remove the flash IC. Besides the fact that I'll melt the socket, there is still a chance that the flash IC is still fine, just the data is corrupted for whatever reason. And from my experience, these old flash ICs do not appreciate that much being heated.
So, with a desoldering gun, I proceed to remove the Dallas socket:
Then, with the soldering iron, I heat up all the pins on one side, while gently lifting the IC up with tweezers, and then do the same for the other side:
Now, using my not at all cursed TSOP32 to DIP adapter, I proceed to dump the IC with a TL866 programmer:
chunk 1
tention at the photos to see how they need to be installed (both FFCs and the adapter PCBs are marked with L and R)
-header pins that plug into the Dallas socket need to be the machined type, round
-not possible to install R10k/R12k CPU module when the socket adapter is installed (not really an issue as anyone using this will likely use it for RM7**** development).
--- Post by mattst88 ---
That's fantastic. If you have an extra, I'll gladly buy it from you.
--- Post by sdz ---
I don't currently have an extra, but I can make one. I'll drop you a message over discord.
chunk 1
ng for a part like either of these:
Ohmite TWM5J2K0E: 5 Watt, 2K Ohm, 5% Tolerance, Vertical Mount Cement Resistor.
TE Connectivity (CGS) SQMR72K0J: 7 Watt, 2K Ohm, 5% Tolerance, Vertical Mount.
Both are cement type vertical mount wire wound metal oxide resistors. You will need to measure the overall size and check to see if these are too small or too big. These often come in 5 to 10 Watt sizes. Because they're vertical amount they're meant to be crammed into a very specific space. So that's the part you should worry about the most. Likely if you can get a higher wattage in the same space that's not an issue. The Ohms value and the lead spacing as well as the fact that it's metal oxide are the important things to match in the replacement part. 10% tolerance is old stuff, you can get better tolerance like 5% and just feel better about having a more accurate value.
--- Post by 3DChris ---
Oh, interesting! I wish I had this info before I picked up the PSU from the tech who gave up on it.
I'm going to try a different guy in my neighborhood and point him in the right direction with these parts.
chunk 1
---
Wow this is excellent work, thank you!
--- Post by CiaoTime ---
Genius! I'm very interested in this.
--- Post by sdz ---
Got the PCBs today, and assembled 4 modules:
System runs fine, encountered no issues. I'll assemble 4 more modules and stress test the system for a couple of days. If there are no issues I'll upload the design & production files.
--- Post by sdz ---
Assembled the rest of the modules, system runs fine, no instability/memory errors etc. Rock solid.
Attached SGI_O2_DRAM_128MB_A00_RELEASE.zip archive (will be available at https://sdz-mods.com/index.php/2026/01/15/sgi-o2-128mb-dram-module/ as well).
It contains the following:
1.SCH_BRD - contains editable schematic and board file. Format is Eagle CAD, but they can be imported in other tools, like Kicad.
2.SCH_PDF- schematic in pdf format.
3.P&P - pick and place files
4.BOM
5.GERBER - gerber files
6.JLC - contains all the needed files for a production run at JLCPCB. Just upload the GERBER zip file, BOM file and CPL file. They currently have everything in stock except CDCVF2510APW and SN74ALVCH16721DGG. These can be found at Mouser/Digikey etc.
chunk 1
t...
forums.sgi.sh
and given their sensitive nature, the plastics are becoming almost impossible to come by nowadays, especially the front flaps, but other parts as well..
On amibay there is a user under the name Ordyne who already made a couple of batches of Amiga 4000D replica cases (I myself bought one, they are metallic and of superb quality: https://www.amibay.com/threads/amiga-a4000-reproduction-case-pre-order-closed.2445280/ ), and he is also working now on the Amiga 4000T replica case, with some other stuff queued up currently. But since I would be very interested in such replica cases for the Indigo 2, I have asked him if he'd be willing to do a similar project for Indigo 2 machines.
While he is currently busy with all these other projects ongoing, his answer also wasn't a definitive no, he told me if there were enough people interested, he'd have nothing against doing it. Also as a bonus, I do think he'd be able to make these cases from metallic materials, which would surely be more durable than the plastic material used by SGI.
chunk 1
the wild assortment of PC's and analog gear I already have. I've got a pair of DELL u3011t 30" LCD monitors that seem to support sync on green over VGA, and I already have an SGI 13w3 to hd15 cable. While I wait for one of those big beautiful CRT's to materialize, I thought it prudent to check whether or not the monitors I currently have are compatible. I'm fairly certain they are, and I've seen similar monitors actively plugged in to octanes, tezros, and fuels but no mention on whether adapters were used.
For reference, here is the manual for the monitors I have.
https://dl.dell.com/manuals/all-products/esuprt_electronics/esuprt_display/dell-u3011_user's%20guide_en-us.pdf
thanks in advance for patience with my novice. looking forward to learning. already bought some books on softimage to study.
xxx
CH9NNEL99
--- Post by flexion ---
Welcome!
I'd say the DELL monitor should work.
If the 13W3 cable doesn't work, here's the ultimate 'DIP switch' configurable cable we all use: https://www.ebay.de/itm/270832512031
chunk 1
eller as shipping would be $$$.
--- Post by Woof ---
I did get the ones from Niktec maybe 15 years ago, and dug through some old mails to find this from 2013:
SGI 1600SW End of Life Sale
As all of you know the SGI 1600sw has been out of production for many years. Dan Evanicky has provided exceptional end of life support for the display. Combined we both have done everything we could to "keep the light on" with these monitors. Unfortunately as of 2013 our new stock parts inventory is winding down and near the end. With no more parts being produced this is truly a last chance to stock up and keep enjoying such a great display. We both want to say THANK YOU for your previous business.
The OEM CCFLs were priced at 39 USD back then. It's worth asking but I doubt 10 years later there's any stock remaining.
--- Post by bjjames ---
I purchased a replacement (all components bundle) a few months ago. Still waiting to install it when I have time. Comes with detailed instructions and the shipping was very quick. I would not wait if they are still available.
chunk 1
cky ---
Yeah I was actually going to say don't remove the chip yet and actually check the traces for the connection to the chip. SRAM really-ish doesn't go bad, unless something external acts on it.
Broken solder joints are real thing, you see how you got a bunch of ffff, that normally doesn't indicate a bad cell it indicates that there's a total lack of communication to it. Given that there was no communication my guess would be a power, ground, or lack of enable signal. Chips have have a chip select line that tells them to pay attention or not, and often there's another chip that tells them to do this, some form of multiplexer.
chunk 1
I and it's operation, as this is an evolution of the ZuluSCSI product line. If you are not aware of the advantages and usability of ZuluSCSI please click here.
Firstly the device itself:
The PCB comes in a beautiful red with gold flashing, the layout and design of the circuit is extremely clean and efficient, hat's off to the designer. I particularly like the small touches, ie; having a spring-eject-mechanism on the SD card, and using USB-C rather than micro which adds to the professional presentation of the product overall. The second photograph shows the Zulu Wide-SCA in the o2 caddy ready to be installed inside the machine. The 3D printed bracket specifically designed for the unit was highly appreciated and worked perfectly.
Benchmarks
SD Card used: Official Raspberry Pi 256GB Class 10 SD card
ZuluSCSI Wide-SCA Fujitsu 10K RPM 300GB Disk
chunk 1
ly superficial differences, but at the end of the day, nearly all of the heavy lifting was done by us, and at my expense. The BlueSCSI V2 firmware represents a search-and-replace of "Zulu" to "Blue"
The BlueSCSI V2 hardware is slightly different, since the BlueSCSI V2 hardware designs only use the Pico/Pico2, so it's necessary for the pinout to be slightly different. It's also worth noting that the BlueSCSI V2 (and original V1) hardware designs omit components necessary to mitigate Electromagnetic Interference , and that these components, which are surface-mount ferrite bead inductors, can and do slightly affect signal timings. While those differences are small, they can and do matter in practice.
The Pico-based BlueSCSI V2 was publicly announced, to much adulation and fanfare, around seven weeks after we began sales of the original ZuluSCSI RP2040, in late 2022. This is not a simple coincidence.
chunk 1
uilt two of my power supplies and while I have not yet tested either of them I am fully confident in his capabilities. There will be a review of his service as soon as I have time to fuck with them.
--- Post by weblacky ---
I've seen something like this before. There's an audio amplifier on the board and usually one of the yellow tantalum capacitors has caught on fire on its circuit. Most of the time this is from a power supply that has fed very unclean power, possibly even out of tolerance voltages, to the motherboard. I actually bought a system from somebody that had done this exact thing. Make a little noise and start burning and yet the system kept running just fine (see attached photo) for a minute or so more before it was finally turned off.
chunk 1
firm my assumption please?
Thanks!
-Jack
68 pin HPCN:
68 pin VHDCI:
--- Post by mapesdhs ---
Sorry for posting to an old thread, but this one does show up high in search results.
If it's of any help, connecting an O2 with Presenter Adapter (also a VHDCI-type connector) to a Presenter 1280, using a standard VHDCI/VHDCI SCSI cable, worked just fine.
Ian.
chunk 1
ne who's programming one for me already, but all the same I'd love to know in case I need to do it myself in future.
--- Post by miod ---
I can't seem to find dumps around, maybe I got rid of them.
The DS1982 presents four memory pages of 256 bits each (32 bytes). But the chip contains more than four pages, there is a redirection table in the chip which tells which actual page to access for a given logical page; I don't know if your programming tools make this transparent for you, or if you'll need to set up the redirect memory (in the status data at offset 1 - factory defaults should be 0xff, 0xff, 0xff, 0xff which mean no redirection yet for pages 0 to 3).
You at least need to put in memory page 0 (or whichever page the redirect table for page 0 points to):
- 10 (0x0a) in the first byte, it's probably a length value for what follows.
- whatever you want in the next four bytes (might be a crc or a checksum though, or a serial number - i don't know).
- the MAC address, in reverse order (i.e. 0x56, 0x34, 0x12, 0x69, 0x00, 0x08 for 08:00:69:12:34:56) in the next six bytes.
--- Post by weblacky ---
jackal said:
chunk 1
ut the initial tests scanning nothing seem promising.
Would love to hear if anyone has experience using a film scanner in IRIX -- in the mean time, if anyone has questions, feel free to touch base.
--- Post by rqsall ---
(My first post here, used to be active on nekochan ages ago)
I have a CoolScan III (LS-30) and tried years ago to get it working on my SGIs with sane, but all I got was black images. I still have the idea to look into the sane source code to fix the issue. Alas, life got in the way for a few years and I only recently have unpacked my SGIs six years after moving house. Hope to find some time early next year or so to look into it, but I am not expecting to be able to fix it.
chunk 1
ical drawing.
The +5V standby is supplied when the power supply is connected to AC line power but has main power turned off via the motherboard. I am guessing the -12V rail is for audio amplifiers.
Pin # Wire Color Function 1 White +3.3V 2 White +3.3V 3 Red +5V 4 Red +5V 5 Red +5V 6 Red +5V 7 Red +5V 8 Red +5V 9 Green +5V Standby 10 Light Blue -12V 11 Black 0V 12 Black 0V 13 Black 0V 14 Black 0V 15 Black 0V 16 Black 0V 17 Yellow +12V 18 Black 0V 19 Black 0V 20 Black 0V
Auxiliary connections are supplied on a 20 position 0.1" spacing (2x10) pin header, with the motherboard side being male and the power supply side being female. Noting the position of the connector key, pin numbering on these connectors alternates between the bottom and top row, starting from the bottom left.
The power supply is controlled by pin 3 (Run), which is "ground to stop." It naturally floats at +5V (standby), meaning that disconnected from the motherboard, the power supply runs and supplies regular power. The motherboard grounds out this pin to stop the power supply.
chunk 1
usehouse I've tried the same settings as you, apart from turbomax and syncspeed 20 (as indigo2 can't run at that speed anyway) really you should be running at SpeedGrade=Default and MaxSyncSpeed=10.
--- Post by mousehouse ---
Yes I’m aware the Indigo2 does not support that speed, but maybe it triggers different code, it does work. If I leave the options out it does not work. Booting takes forever but once running it is very responsive. Software Manager for example is so much faster than the old drive.
--- Post by stormy ---
@mousehouse I just wanna let you know, after some troubleshooting my end & testing your ini settings, I figured out it's the EnableSCSI2=0 option which actually allows it to work.
But I must ask, since I'm assuming you discovered this by accident. What on earth made you even think to try disabling SCSI2 mode? Just a lucky accident or was there something behind that decision?
--- Post by flexion ---
Not BlueSCSI but ZuluSCSI here.. had the new ZuluSCSI Blaster in the mail today, old firmware on it.
I installed the Blaster in the Indigo2 R10k Impact using the same SD as used in the Zulu 2040 model before.
chunk 1
se and recover that last node?
I'll be working over there this afternoon and all day tomorrow, and can get additional information if needed. Any and all assistance is greatly appreciated.
Thanks,
-Dave McGuire, LSSM
--- Post by flexion ---
Hi! I'd say enter POD mode and try activating CPUs again. That's probably not going to fix it, but maybe this, and some POD debug flags, lead to other hints about what caused the CPUs to be disabled.
--- Post by pauliedweasel ---
Dave, on the off chance that it turns out to be a bad DIMM I just ran across a bunch of Onyx2/Origin 2000 DIMMs that I bought as spares when I had a couple of Onyx2s. I’m assuming the 2400 uses the same DIMMs, so if you need some spares let me know because I have no use for them now.
--- Post by mcguire ---
flexion said:
Hi! I'd say enter POD mode and try activating CPUs again. That's probably not going to fix it, but maybe this, and some POD debug flags, lead to other hints about what caused the CPUs to be disabled.
Click to expand...
chunk 1
know it'll work till tonights run happens. Since those modules are powered up now - will they automatically join the cluster and work or is there something I need to enter at the L1: prompt(serial)?
The system is completely undocumented and the online manuals I can find for this system give cluster troubleshooting commands that apparently aren't on this system.
I inherited this system from a past sysadmin that didn't record anything and there is no back/test system to learn on...just this production highly critical box that we use to predict smoke plumes. This is why I've got a replacement system in the works...I just need to limp this one along for another few weeks.
Also, as a side note - when they pulled the power the console actually never powered off....i can't imagine this has a 20+ year old UPS battery in the chassis somewhere that is still good? Any thoughts?
--- Post by nondem ---
As an added note - should I reboot the OS now that I've powered up the cluster modules so it sees them at boot? hinv -vm apparently builds its inventory on boot so that looks like it doesn't include the modules that were powered down.
I could post the output but don't want to flood.
chunk 1
boot process, and can see when the two SCSI buses are walked on both machines. I have not tried yet attaching a terminal to the diagnostic port and turning the key switch to the diagnostic position.
I cannot find any info specific to the Onyx2 midplane, but the Origin ™ and Onyx2™ Theory of Operations Manual (Document Number 007-3439-002) on pages 65 and 66 shows a picture of the Origen2000 midplane, which I am assuming is similar. It appears that the internal SCSI bus, including the far end termination, is contained entirely on the midplane. Diagram on page 70 shows that the internal SCSI bus on the front of the midplane connects to the IO6G SCSI controller via the white square connector at the top of the IO6G.
Schematics would be helpful, but I am sure such info has been lost to the mists of time, as SGI went through its changes and died.
Perhaps it is something so simple but so painful as broken connections on the midplane?
Any thoughts and feedback will be greatly appreciated. I can post any pictures or terminal output anyone might deem helpful.
Thanks!
chunk 1
see if there were any obvious signs of damage. Again, nothing. I plugged everything back in and made sure everything was tightly connected.
Still getting the solid light. Not sure what to try next.
--- Post by Woof ---
The first step is to plug in a serial adapter to the console connector. This is my go-to cable with modern machines, but any USB to serial will do:
https://www.galaxus.ch/en/s1/product/15296770
This will give you a starting point.
--- Post by 3DChris ---
I'll try to get one today and see if I can find out anything. I've never connected via console before. Any tips for what I should be looking for? Or for that matter, how to connect in the first place?
--- Post by legodude ---
Depending on the cable you end up with, you may need gender changers and/or null modem adapter. 9600 baud is standard.
--- Post by 3DChris ---
I bought a USB to Serial adapter (male end) and a female to female serial extension cable. Is this not going to work? Or will I be OK?
chunk 1
55hz because the pixel clock will exceed the 144MHz limit, and we can't go over 1152 lines or else we will break the 128-tile limit. So this is about as close as we can get to a good 1600x1200 mode.
--- Post by stormy ---
Thank you both very much! Can I just suggest adding little details in the first post like where to copy the VFO files? People can easily forget and it'd be nice to have all the required information here.
--- Post by Richard42 ---
On an O2 the VFO files go:
/usr/gfx/ucode/CRM/vof/
On an Indigo2 with SolidIMPACT or HighIMPACT, or an Octane with SI or SE, they go:
/usr/gfx/ucode/MGRAS/vof/
On an Indigo2 with MaxIMPACT, or an Octane with SSI, SSE, MXI or MXE, they go:
/usr/gfx/ucode/MGRAS/vof/2RSS
On an Octane with VPro they go:
/usr/gfx/ucode/ODSY/vof/
Also, IIRC the .vfo files have to be renamed with the extension .sdb for the MardiGras video boards.
--- Post by gijoe77 ---
Here is my collection of VFO's and various related things
eld from Amazon:
https://www.amazon.com/Plastruct-Plastic-Weld-applicator-Bottle/dp/B00FDFWJD8
I don't know if this is the best possible solvent, but I had pretty good luck with it.
There were a couple of issues to consider. One was that some of the pieces were warped, either from pre-crack distortion, or from released stresses post-crack. This meant that it was impossible to get perfect fit up when getting the pieces back together. Another solvable issue is that there were sometimes little plastic pieces (like burrs) that would prevent a good alignment, I removed these with an hobby knife. You also have to be careful about the order of operations in selection which piece to glue next. I did a dry run of my gluing sequence to ensure that I would not get myself into a bind.
chunk 1
Nope, RAMs are ok, but I'm still stuck
--- Post by jenna64bit ---
I'm not sure, but that can't be good. reseating things would be my thought too, but I guess not? Hopefully the CPU isn't just dead.
--- Post by scavej0n_ ---
jenna64bit said:
I'm not sure, but that can't be good. reseating things would be my thought too, but I guess not? Hopefully the CPU isn't just dead.
Click to expand...
I was thinking the same thing, but I don't know how to reset because this error it's the first thing that appears on the screen so i don't have access to the Manteinance menu, even if i hit Esc when I turn it on.
--- Post by stormy ---
I think you should persevere again with the DIMM slots. I don't know if the sockets are gold plated on Indy? if not, there could be some bad oxidisation. Also try less memory, put in the minimum amount and focus on cleaning just those sockets. Slip some cardboard in/out for some friction to clean.
chunk 1
ly on random access.
I've attached the user manual for this enclosure so it doesn't get lost.
External SCSI Wiebetech ProSATA SS8 using 2x Intel 120gb SCSI drives in RAID 0:
Code:
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name : ssdraid
# Test date : Thu Jul 24 17:59:22 2025
# Test machine : IRIX64 OCTANE 6.5 07202013 IP30
# Test type : XFS data subvolume
# Test path : /mnt/RAID/tmpfile
# Request sizes : min=16384 max=4194304
# Parameters : direct=1 time=10 scale=1.000 delay=0.000
# XFS file size : 1073741824 bytes
#---------------------------------------------------------
# req_size fwd_wt fwd_rd bwd_wt bwd_rd rnd_wt rnd_rd
# (bytes) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s)
#---------------------------------------------------------
16384 18.46 18.00 18.52 18.01 17.72 11.41
32768 24.87 23.77 24.80 23.78 24.24 16.10
65536 29.77 28.08 29.69 28.10 29.45 20.31
131072 33.35 31.21 33.28 31.15 33.14 25.70
262144 35.69 33.22 35.66 33.26 35.64 28.80
524288 36.91 34.26 36.87 34.24 36.92 30.04
1048576 37.51 34.74 37.48 34.71 37.53 31.57
chunk 1
. Until you look up old Alias site for StudioPaint 3D qualification charts..
Where it mentions Indigo2 KILLER Impact..
[...]
Pretty mysterious. What do you think? Maybe that was some SGI prank?
Click to expand...
Well, on the photo showing the red one with the unusual logo, the bottom one looks like a teal Indigo². So maybe they initially wanted to go for red instead of purple.
And the "Indigo2 Killer Impact" moniker would actually fit the logo with its K-like shape and the blood (?) red exterior.
It could still be photoshopped as the positioning of the machines is basically identical to the left photo. Also those white stripes near the bottom are similar if not the same.
--- Post by bitpak ---
Yep. Exactly my thoughts. And the same shot was used in another promo, but with Impact badge.
So it definitely looks like they did a template photo and changed the appearance of the Indigo2 and what was displayed on the screen.
--- Post by stormy ---
Has anyone made the connection to the N64 game Killer Instinct? It's also made by Rare. So perhaps this was some sort of game-dev system inspired by Rare? Killer Impact for Killer Instinct development
chunk 1
d to have an SD card inserted for anything to work.
The SD card: Sandisk Extreme 128GB (this is A2 rated which is supposed to help with small random reads/writes)
The results.
Code:
# diskperf -W -n scsi2sd_10M_Sync -c 1G -t 60 /mnt/testpath
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name : scsi2sd_10M_Sync
# Test date : Sat Dec 14 12:20:45 2019
# Test machine : IRIX isengard 6.5 10070055 IP22
# Test type : XFS data subvolume
# Test path : /mnt/testpath
# Request sizes : min=4096 max=4194304
# Parameters : direct=0 time=60 scale=1.000 delay=0.000
# XFS file size : 1073741824 bytes
#---------------------------------------------------------
# req_size fwd_wt fwd_rd bwd_wt bwd_rd rnd_wt rnd_rd
# (bytes) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s)
#---------------------------------------------------------
4096 1.26 3.31 1.41 3.28 0.09 0.15
8192 1.38 3.61 1.27 3.13 0.17 0.29
16384 1.41 3.61 1.28 3.14 0.34 0.59
32768 1.38 3.62 1.28 3.14 0.68 1.12
65536 4.46 1.19 3.60 3.84 2.99 1.47
131072 4.48 1.57 3.47 3.93 2.61 2.34
262144 4.49 1.93 3.20 3.69 3.39 1.88
chunk 1
" Click "enter command monitor" and type hinv and then put a photo of the results here - that will show you if the had drive is detected or not
--- Post by graphox ---
legodude said:
Press any button, then I assume you are shown a screen with options including "start system." Click "enter command monitor" and type hinv and then put a photo of the results here - that will show you if the had drive is detected or not
Click to expand...
I added some more photos. Like I say, whether the hard drive sled is in or out, it is the same. It is like it is not recognising the hard drive / sled at all.
--- Post by legodude ---
Nice system
You are correct, the hard drive should show up hinv. Do you hear it spin up? Have you double checked the connections between sled and hard drive? Are you sure the sled is fully seated?
--- Post by graphox ---
legodude said:
Nice system
You are correct, the hard drive should show up hinv. Do you hear it spin up? Have you double checked the connections between sled and hard drive? Are you sure the sled is fully seated?
Click to expand...
chunk 1
to giving it a coat of paint.
I have since upgraded the machine with the following modules:
A DG5-8:
And two RM11's: (To get it up to the IR4 spec)
Here's a closeup of an RM11:
The Origin 2000 line of machines, on-which the Onyx2 is based, was in fact a Cray design, and was acquired by SGI when they acquired Cray during the nineties.
One of the key features of Cray machines, was the fact that you could order them in any colour you liked!
So this Cray X-MP served as my inspiration here:
Here are some pics of the bare machine and it's flatted plastics, before paint:
Some pics of the painting process:
I firstly applied a plastic primer:
Then a grey paint primer:
Then finally a coat of hardened white automobile paint. Here's the result, before the plastics were refitted to the machine:
Here are some pics of the machine fitted with its newly painted plastics:
Finally, here's a pic of the machine in operation: (Carrying out the Quake III benchmark!)
--- Post by mamorim01 ---
Well, that looks fantastic!
--- Post by Irinikus ---
mamorim01 said:
Well, that looks fantastic!
chunk 1
s like this PSU is working but hits some over current protection or short protection and it shuts down.
Edit: The one that doesn't do anything is a Lucent and the other is a different manufacturer.
--- Post by stormy ---
Sorry nobody is replying to you, there is not much experience in fixing Octane PSU's. This thread might be helpful for you: https://forums.irixnet.org/thread-4349.html
--- Post by Richard42 ---
I have repaired a couple of Octane PSUs - one was a Lucent model with a bad AC/DC converter. IIRC with that one it wouldn't do anything when the power button was pressed. There is a lot of good info for fixing this problem in this thread:
https://forums.sgi.sh/index.php?threads/octane-psu-repair-click-of-dead.666/
The second one was a Cherokee PSU which shorted internally and blew the fuse because the handle broke off during shipping and the internal screw wedged itself perfectly between two big heatsinks with opposite polarity
ir, I was able to remove the female SCA connector.
In order to keep the pinout correct, you have to flip the placement of the SCA male connector (so it is on the opposite side of the PCB)
The header and molex socket also need to come off and you need to replace the molex connector with a jumper as shown in the CS-electronics version.
I found my lowest-profile SCSI cable and took it over to an Octane.
As you can guess, it did not work. The 68pin connector is just too high profile. The adapter would partially engage, but not enough to make contact on all of the pins.
I was hopeful that even at an angle, there would be enough of a connection. One possibility is to see if I can solder the SCA connector slightly at an angle. Another possibility is to replace the 68pin connector with a right angle version, if it is a few millimeters more compact, that would likely provide enough clearance. At some point it is likely easier/faster/cheaper to simple design a new PCB.
chunk 1
by trixster1979 ---
It should work fine. I used a zuluscsi to mount the install cd to start a miniroot, so there’s no reason irix shouldn’t install fine from an sd card with all the images mounted.
--- Post by Jamieson ---
I've heard that a typical IRIX install process requires ejecting and inserting multiple CDs. Looks like with ZuluSCSI I can assign multiple ISO files to a single SCSI ID, and then with each "eject" command it will cycle through the various ISO files to simulate CDs being inserted. I've not tried this yet, but sounds like a great feature!
--- Post by Elf ---
Indeed; the only thing is you will need to insert and re-insert them in an order that isn't necessarily very straightforward. For example, booting off the Install Tools CD, then adding the contents of each CD to inst starting with the first Foundations CD, and one of the CDs to add afterwards will be the same one that had the Install Tools (the boot CD), then later you will need to insert the CDs again in some order determined by inst to actually install the packages.
chunk 1
Code:
sudo bash
ethtool -e eth0 length 4 offset 0xa4 raw on > 0xa4.bin
ethtool -e eth0 length 96 offset 0x100 raw on > 0x100.bin
Then to program the card.
Code:
ethtool -E eth0 magic 0x669955aa length 1 offset 0xa4 value 0x80
ethtool -E eth0 magic 0x669955aa length 1 offset 0xa5 value 0x10
ethtool -E eth0 magic 0x669955aa length 1 offset 0xa6 value 0x10
ethtool -E eth0 magic 0x669955aa length 1 offset 0xa7 value 0xa9
ethtool -E eth0 magic 0x669955aa length 1 offset 0x100 value 0x82
ethtool -E eth0 magic 0x669955aa length 1 offset 0x101 value 0x20
ethtool -E eth0 magic 0x669955aa length 1 offset 0x102 value 0x00
ethtool -E eth0 magic 0x669955aa length 1 offset 0x103 value 0x53
ethtool -E eth0 magic 0x669955aa length 1 offset 0x104 value 0x47
ethtool -E eth0 magic 0x669955aa length 1 offset 0x105 value 0x49
ethtool -E eth0 magic 0x669955aa length 1 offset 0x106 value 0x20
ethtool -E eth0 magic 0x669955aa length 1 offset 0x107 value 0x47
ethtool -E eth0 magic 0x669955aa length 1 offset 0x108 value 0x69
ethtool -E eth0 magic 0x669955aa length 1 offset 0x109 value 0x67
ethtool -E eth0 magic 0x669955aa length 1 offset 0x10A value 0x61
chunk 1
sk where did you get this from? For the drives, any scsi SCA drives will work. I recommend the HP 300gb SCA drives you can find on ebay. These drives have the long 80 pin single connectors on them.
And for the NL4R. Those are used for sgi Altix 350s / 3000s and do not work with the MIPS origin stuff. The altix stuff can also be a lot of fun to play with if you want to mess with Linux and Itanium. They get power from a "power brick". I guess you could mod it to use AC power.
--- Post by jander31 ---
joshyfishy22 said:
Nice find. Mind I ask where did you get this from? For the drives, any scsi SCA drives will work. I recommend the HP 300gb SCA drives you can find on ebay. These drives have the long 80 pin single connectors on them.
And for the NL4R. Those are used for sgi Altix 350s / 3000s and do not work with the MIPS origin stuff. The altix stuff can also be a lot of fun to play with if you want to mess with Linux and Itanium. They get power from a "power brick". I guess you could mod it to use AC power.
Click to expand...
chunk 1
it or attempted to power it on in case, so I don't know what's installed on it.
Have you seen anything like this before? Or possibly know how this could have ended up in a storage locker in Canada?
--- Post by onre ---
I have no idea what that is, other than a very cool thing to find! There's also a non-zero chance of the hard drive containing rare or unique software.
--- Post by joshyfishy22 ---
Can you please take a picture of the signature? Please image that disk!
On whats inside its def a R5k indy which is a pretty nice machine to run 6.5.22 on. It appears to have the a indy video and cosmo compress options which are nice. Prob also has a 24bit color graphics board.
All together a really nice find! Id personally love a proto indy but currently im trying to watch my spending.
--- Post by SolusRaion ---
Storage locker in Canada? Nekochan had a few canadian members who were into collecting stuff like that, SGI also had a canada office in Toronto and apparently Sasketchawan? I dunno if any of that has to do with THIS though.
--- Post by flexion ---
Nice find! I also have a "Guinness Prototype" Indy but my sticker looks different:
chunk 1
nch before the word Indy you'll see that it's still quite a bit blue.
So while black Indy's have existed do the re-badging, this is a normal blue indy that has sat in direct sunlight for 20+ years.
--- Post by oliverx74 ---
Hi weblacky, thank you very much for letting me know. At least the color still looks cool. Any idea about the superCluster thing? Impressive collection you have. Greetings from Germany.
--- Post by weblacky ---
I've never heard of it but it's fairly evident that it's some software product installed in the operating system. So it ran as part of a larger system which it's now detached from.
The closest thing I could find was references in a paper ( https://www.marac.info/assets/documents/marac_technical_leaflet_11.pdf ) for something that has something to do with alias wavefront's possible participation at the University of Missouri.
This link talks about the clustering of Indy and Onyx's in an older page in the computing center at the University of Missouri that is officially called supercluster: https://meru.cs.missouri.edu/facilities.html
I'm like 90% confident this is it.
--- Post by oliverx74 ---
...including more than 250 SGI Indys...
chunk 1
1 & 2. All referenced from pin 3 on the middle-right(down) of the connector. I don't have a keyboard to confirm that is 100% proper.
--- Post by Roostie02 ---
luminescentsimian said:
I just poked at my (new-to-me) Indigo R4k and got +12 on pin 4 and -12 on pin 6. I did see -4.4 on pin 5 and 2.3V on pins 1 & 2. All referenced from pin 3 on the middle-right(down) of the connector. I don't have a keyboard to confirm that is 100% proper.
Click to expand...
I also have an R4k indigo, can confirm that I get the same values as well.
--- Post by nuclear ---
I would be interested to hear from owners of R3K indigos and also onyx who AFAIK share the same port.
The OP is talking about my keyboard adapter ( http://nuclear.mutantstargoat.com/hw/sgikbd/ ), which requires the negative rail to work. I went by the docs in the keyboard (7) manpage, which clearly specifies the presense of a negative DC rail on pin 6, but the OP sent me a schematic of the R3K indigo which shows something completely different there (an extra bidirectional serial transciever of some sort ...).
chunk 1
= 87ff00, limit = 87ff30
EEPROM state = 10101012
Warning: Found Bad KONA eeprom: 0x10101012
: Not Adding gfx device - gfxpipe
kl_graphics_install: installation failed for /hw/module/1/slot/io4/kona
Walking SCSI Adapter 0 (/hw/module/1/slot/io1), (pci id 0)
1+ 2+ 3+ 4+ 5- 6+ 7- 8- 9- 10- 11- 12- 13- 14- 15- = 5 device(s)
Walking SCSI Adapter 1 (/hw/module/1/slot/io1), (pci id 1)
1- 2- 3- 4- 5- 6- 7- 8- 9- 10- 11- 12- 13- 14- 15- = 0 device(s)
Initializing PROM Device drivers .......... DONE
Cannot open /dev/graphics/textport for output
Cannot open /dev/graphics/textport for output
Checking hardware inventory ............... DONE
**** System Configuration and Diagnostics Summary ****
CONFIG:
No. of NODEs enabled = 2
No. of NODEs disabled = 0
No. of CPUs enabled = 4
No. of CPUs disabled = 0
Mem enabled = 2880 MB
Mem disabled = 0 MB
No. of RTRs enabled = 0
No. of RTRs disabled = 0
DIAG RESULTS:
ALL DIAGS PASSED.
**** End System Configuration and Diagnostics Summary ****
chunk 1
parts that I cleaned with IPA
--- Post by gdog0622 ---
The next heatsink over has -160v DC on it which i suppose both of these voltages could be fine assuming they aren't supposed to be insulated
I think the primary cause for concern is the fact that the fan isn't spinning up and the fact that it can't be turned off. It seems like the communication isn't working but i don't know if it's the board and or the psu as this is my only computer
--- Post by SolusRaion ---
The Sony PSU has a design flaw that prevents it from spinning up until the computer is overheated. You can't rely on that as the issue.
The bigger concern is how are you testing it for post? you gotta have serial or a keyboard and screen connected, at minimum.
The PSU is not ATX design either, don't make that mistake.
--- Post by gdog0622 ---
SolusRaion said:
The Sony PSU has a design flaw that prevents it from spinning up until the computer is overheated. You can't rely on that as the issue.
The bigger concern is how are you testing it for post? you gotta have serial or a keyboard and screen connected, at minimum.
The PSU is not ATX design either, don't make that mistake.
chunk 1
re force on riser to get it to seat, then screw it into the carrier.
--- Post by 0xDEADBEEF ---
I did replace mobo to upgrade my I2 to R10K. It is straightforward, just a lot of screws to remember.
The board slides toward the front a little and then you pick it up, lifting from the front. Install in reverse.
Some screws on the back (around audio) look like they need to be removed to slide out the board but it is not necessary.
I had to loosen up power supply a bit to be able to unplug it from the board.
My card riser plugged in just fine. I just removed and reinstalled it this morning to replace the fan. I dont see any flexing of the mainboard.
The SCSI connector is little tricky to seat correctly, so don't despair if you don't see the drives after reassembling, make sure it is fully plugged in.
chunk 1
ernating lines that are missing (wrong color, white, etc.) and over time the issue can become more apparent until most of the textured image is obscured by these artifacts.
So HOW does this happen?
Well, SGI had limited room to fit the TRAMs onto the boards they install on top of. If you take a look at a Max IMPACT set, you'll see one module on top and one that is on the middle board. Even though the top board has more room if no other option boards are installed, the middle board drives the sizing requirement (of course there are option boards that connect to the top of the Max IMPACT set so you'd run into the same space issue on top). To get around all this, SGI used very thin heatsinks. Not necessarily a bad thing IF there's enough airflow. You don't necessarily need a huge mass of metal to keep something cool. But you do need proper airflow. The heatsink is mounted by way of thermal tape that adheres the metal to each chip. It is very thin and truthfully I have no way of being able to know or even guess just how good the heat transfer properties of this tape happen to be. Additionally, the sink is attached to the board by tightly held on Kapton tape.
chunk 1
or what tests to run would be helpful. Thanks,
Glenn
--- Post by mc68k ---
Same issue here but only with certain monitors (Samsung Syncmaster 19" LCD). Try a different monitor (Sony, Dell LCD...).
--- Post by jenna64bit ---
One thing is to use the screen under good lighting, see if it's really going blank or if the screen's on but the backlight failed.
for black to GND yellow to 3.5v.
Another thing I was interested in was the initial AC filter. I tested the continuity and it all seemed fine. I opened it up and took a picture just for the record:
--- Post by stormy ---
I want to measure the connectors that go from HV > LV boards. So I plugged my load resistors in to pins 15 & 16 (5v & GND) on the left connector, then pins 13 & 15 (12v & GND) on the right connector. My 5v load resistor is 2R2K and my 12v is 10R. I also connected a hard disk to the Molex for extra load & connected my home made graphics cable terminator.
These are the measure points, I put arrows on the PCB where the connector points are:
Here is a photo of the HV side:
Here is a photo of the LV side:
Photos of my load setup:
Photo of the PCB dismantled for taking the measurements:
Of course I have checked the fuses, and just for the record here are some resistors on the HV side that get hot (and show by the PCB discoloration:
Result of testing so far:
Absolutely nothing on the output of the HV>LV connectors. But I did notice those resistors are getting hot on the HV side still.
chunk 1
skin. At the moment, I am more scared of breaking the skins in the process than I am bothered by the CD (I can't recall the last time I used it).
Is this worth fixing, or should I just leave it be?
--- Post by ReVolt ---
The plastic gear falls off because it's cracked (my o2). Evidently the nylon shrinks over time , then the stress eventually cracks it. If you put it back on the crack becomes evident. A cracked gear that hasn't fallen off results in a noisy tray (my other o2). I tried super gluing the crack then reaming the shrunken center hole slightly larger but the superglue didn't want to bond and the crack re-opened. If it worked I was going to use locktite or epoxy to help hold it on the shaft. If you don't need the CD-ROM maybe just leave it alone.
telackey said:
My R5k O2's CD tray just started misbehaving. The tray itself moves freely (I can pull it out or push it back in manually with little effort) and when I restart the machine, it makes a pretty terrible noise for a few seconds. In the startup sequence it reports the drive is "not ready".
chunk 1
He doesn't like destroying history.
--- Post by RaptorDesu ---
SolusRaion said:
Uhh they're close in size
Click to expand...
SolusRaion said:
I will contact my colleague out there. Runs a computer recycling business out of Northern California sometimes he finds rare stuff and puts it aside. He doesn't like destroying history.
Click to expand...
Thank you! I am also interested in the other desk sides aswell. The challenge series etc. I’ve wanted a desk side forever. It’s the ultimate SGI piece, plus all of the desk sides look so cool
chunk 1
. There is a cable that connect the top PCB with the middle one, easy to remove. The white external plug is easy to use a pair of needle pliers to push the connectors (don't unplug it from the PCB).
Disconnect the Power Cable input connector from the second board (Mark or label where the cables go, color base, easy) and remove it from the enclosure. Is hold by 2 screws. This will make easy the removal of the second PCB. Remove the connector that connect the secondary board to the third lower PCB and remove the board.
The last PCB is hold by 4 screws. Disconnect the Fan cable and is easy to feed it between the heatsink. You will have to push in another of the white external plug the same way you did on the first board, don't try to disconnect it from the PCB
Second - Recap:
List of Capacitor from Mouser.com
Mouser # QTY
75-517D476M025JA6AE3 6 710-861221484008 6 667-EEU-FC0J682S 6 647-UPV1H4R7MFD1TD 1 647-UVK1E101MDD 2 667-EEU-FM1V681B 1 647-UPJ1V102MHD6 9 647-UPM1V222MHD1AA 2 647-UBW1V221MPD1TD 1 667-EEU-EB1J100S 2
Replace All Capacitors in all 3 PCB. Note: theirs is one capacitor on the little AC/DC Control board in the secondary or middle PCB
chunk 2
e and Tezro Rack have 3 slots available, the IO9 card (bus 1, slot 1) requires that the bus 1 slot 2 card be 66 MHz
(2) Origin 2000 / Onyx 2 Use the same Bridge ASIC - IO6
Maximum Transfer Rates
Bus Speed (MHz 4 or 8 bytes / transaction (32/64 bit) Data Rate (Megabytes/Second) 33 4 (32 bit) 133 MB/s 33 8 (64 bit) 266 MB/s 66 4 (32 bit) 266 MB/s 66 8 (64 bit) 532 MB/s 100 4 (32 bit) 400 MB/s 100 8 (64 bit) 800 MB/s 133 4 (32 bit) 532 MB/s 133 8 (64 bit) 1064 MB/s
PCI Version Highlights
1.0: 5V, 32 and 64-bit @ 33 MHz
2.0: Added 3.3V
2.1: Added 66 MHz
2.3: Removed 5V Only (allows for Universal)
References
https://en.wikipedia.org/wiki/Conventional_PCI
https://en.wikipedia.org/wiki/PCI-X
Octane: OCTANE Technical Report N/A 1997
Fuel: Silicon Graphics® Fuel™ Visual Workstation Hardware User's Guide 007-4480-001
Tezro: Silicon Graphics® Tezro™ Visual Workstation Hardware User’s Guide: Rackmount Configuration 007-4643-003
Tezro: Silicon Graphics® Tezro™ Visual Workstation Hardware User’s Guide: Tower Configuration 007-4564-001
Origin 200: Origin™ 200 and Origin 200 GIGAchannel™ Owner’s Guide 007-3708-002
chunk 2
or.
9. Configure the PROM emulator.
Connect an USB cable, type setup, select RM7000C. If the default settings are fine with you, simply choose 4. default RM7000C 600MHz tertiary cache on .
Overclocking.
Only two things need to be done, adjust the VCORE so that the system is stable at the higher clocks and configure the PROM emulator for the new settings.
This is what I used (sample size of 1, your mileage may vary):
600MHz: 1.2V core, R50 0R, R46 DNP
700MHz: 1.4V core, R50 750R, R46 4.74kR
800MHz: 2.0V core, R50 3kR, R46 4.74kR
2.0V might seem a lot, as there is a 800mV VCORE bump. However, these CPUs run really cool, even at 2.0V VCORE and 800MHz.
Example PROM emulator config for 800MHz:
Code:
chunk 2
of both 3.3V and 5V devices.
Installation procedure:
-locate PROM device
-desolder PROM device
-solder FFC in place
-connect FFC and place the board where you think it's best
R5k "booted" with the PROM emulator:
Example of interactive config:
Code:
========================================
O2 CPU PROM EMULATOR FW. REV. A00
CPU: R5000
Bitstream Profile: default R5000 180/200MHz 512kB secondary cache
Bitstream: 256 bits
Mode: Polled (all sends)
Type 'setup' + Enter for setup menu
Type 'status' + Enter for status
Type 'info' + Enter for info
Type 'boot' + Enter for USB bootloader
Type 'reboot' + Enter to reboot MCU
========================================
setup
1. R5000
2. RM5271
3. RM7000
4. RM7000A
5. RM7000B
6. RM7000C
7. RM7900 (RM7965 Mode bits)
8. SR71010A
7
1. default RM7900 800MHz tertiary cache off
2. default RM7900 800MHz tertiary cache on
3. default RM7900 900MHz tertiary cache off
4. default RM7900 900MHz tertiary cache on
5. custom
5
[PROM] Existing RM7900 custom bitstream:
chunk 2
with the BigEndian pin)
Bits 9:10 — Non-Block Write mode
bits9..10 = 10b = 2
Meaning: Pipelined writes
Bit 11 — TmrIntEn (timer interrupt on Int*[5])
bit11 = 0
Meaning: Timer interrupt enabled
Bit 12 — Secondary cache enable
bit12 = 1
Meaning: Secondary cache enabled
Bits 13:14 — DrvOut (output driver strength / slew)
bits13..14 = 10b
Meaning: 100% drive strength
Bit 15 - reserved
bit15 = 0
Bits 16:17 — Secondary cache size
bits16..17 = 00b
Meaning: 512 KB secondary cache size
Bits 18–255 reserved (and set to 0), except 20 33 37 (which are set to 1), as intended according to R5k errata.
-SysAD runs at 90MHz
-External cache runs at 90MHz
If anyone wants the full dump from the logic analyzer, let me know and I'll upload it somewhere.
--- Post by Tech&Music ---
sdz said:
-external cache is actually disabled in the bitstream, likely it is enabled later by the PROM (the PROM on the MB, that the CPU executes).
Click to expand...
This surprises me, because it's not what I observed in my RM7000 swap experiments.
chunk 2
asure!
--- Post by khral ---
Ooh, this would be a good starting point for 3D printed O2 skin recreation/replacement in future!
As O2 skin is brittle and often get damage during shipping these day.
--- Post by Irinikus ---
I did a little bit more work on this today, it doesn't seem like much, but it took hours!
--- Post by KayBee ---
This is really the Lords work. Such a great idea. Thank you Irinikus!
--- Post by Irinikus ---
More work tonight with an accompanying cup of coffee and streamed music!
Here are some of the steps I'm going through:
Strategically select faces consisting of triangles and delete them.
Select the edge vertices and create an new surface surrounded by four vertices
Reorganise the surface.
--- Post by Irinikus ---
This was tonights work:
--- Post by flexion ---
very nice! is this from the STL mesh that gijoe77 shared some days ago?
I had this on my todo list as well, to turn it into a 3D printed miniature O2 SD card holder or something like that.
UPDATE: LOL yes I didn't read all of the fine print.. it's the STL posted by gijoe77
--- Post by Jacques ---
Amazing work and also thanks to gijoe77 for sharing the stl file!
chunk 2
n the O2 will boot and run that installation as expected. I can read and write files.
If I add a hard drive in sled 2, this is detected by 'hinv', and shows as an umounted disk in the File Manager.
So next I put the hard drive in sled 1, renamed the SD image file to HD2.img, and put the ZuluSCSI in sled 2. The system boots as normal from the hard drive, but neither 'hinv' or the File Manager detect anything with SCSI ID 2. Turning SCSI termination on or off on the Zulu makes no difference.
I have turned on 'debug log' on the ZuluSCSI card, and will attach the files. In essence, the first 50 lines are similar. In sled 2, there are no entries after this. In sled 1 the file continues with a lot of 'DBG' entries.
Any ideas I can try to fix this? Thanks for any help!
--- Post by stormy ---
Hi Phil,
Just letting you know that I successfully had my zulu sca in the second bay of my o2 (when I cloned my root hdd to it) without any issue. I used the mount that they provided. Must be some slight tolerance issue happening somewhere.
--- Post by philden ---
stormy said:
Hi Phil,
chunk 2
convince the GBE/EVIL to stop outputting the composite sync signal, but I have no clue how to do that at the moment.
The O2 uses an ADV7120KS140 DAC. It is located near the VGA connector, here:
There is a datasheet available for the ADV7120, however, it does not at all match the QFP variant found on the O2. It might be a special P/N made for SGI.
The QFP variant on the O2 does match however the PLCC version in the datasheet, like this:
There are a couple of ways to disable sync on green:
3A (easiest approach and can be easily undone).
Lift up the ISYNC pin (pin 31 of the QFP package).
3B (somewhat reversible but doesn't require a soldering iron).
ISYNC pin is connected directly to the GREEN channel output of the DAC. If you look closely at the photo, there is a trace that connects pin 32 and 31). This trace needs to be cut.
3C. Lift up the !SYNC pin (pin 10) and connect it to ground (grounding might not actually be needed,it worked fine on my end with it floating, but the datasheet does not mention any internal biasing for this pin. Your mileage may vary).
chunk 2
le gently lifting the IC up with tweezers, and then do the same for the other side:
Now, using my not at all cursed TSOP32 to DIP adapter, I proceed to dump the IC with a TL866 programmer:
And it worked, at least the flash IC isn't completely dead. Now, to get a PROM image and write to the flash.
I could desolder and dump the flash from the two other working O2 motherboards I have, but I'd like to avoid that.
My working O2 has 6.5.30 installed, and under /usr/cpu/firmware/ there's ip32prom.image (4.18) that can be used to flash the PROM with flashinst (if the system is working of course).
I scp-ed this file to a Linux box. Now, this may be a raw file, to be written byte by byte to the flash, or something else. Always good to make a diff first, even if what I dumped from the flash IC is maybe corrupted and maybe a different version.
And indeed, there is an extra header from 0x00 to 0xFF compared to the raw flash dump. Besides that, they are quite similar. No extra stuff at the end of the file.
So, just write the ip32rom.image to the flash IC, with an offset from 0x100.
chunk 2
sting! I wish I had this info before I picked up the PSU from the tech who gave up on it.
I'm going to try a different guy in my neighborhood and point him in the right direction with these parts.
I have no real ability to fix/test this myself as I'm not any kind of electrical engineer. I only have a dangerous level of soldering skill and I don't trust myself to not blow something up with this PSU.
--- Post by 3DChris ---
Here's what the tech took a picture of. Not sure exactly how it's mounted by this photo.
--- Post by weblacky ---
Yeah, that's what I gave you... but you'll still need to have the dimensions checked before you put in an order for anything as it's obviously a tight fit and your replacement needs to fit in the same space with the same lead spacing. Assuming that's even your issue.
chunk 2
on run at JLCPCB. Just upload the GERBER zip file, BOM file and CPL file. They currently have everything in stock except CDCVF2510APW and SN74ALVCH16721DGG. These can be found at Mouser/Digikey etc.
Important PCB specs:
-thickness 1.2mm
-finish: ENIG
-gold fingers (beveling not needed)
-stackup (for JLC) JLC06121H-3313A (ideally) or JLC06121H-3313.
The exact RAM part number I used is IS42S16400N-7TL, but one could also use:
IS42S16400N-6TL
IS42S16400N-6TLI
IS42S16400N-7TLI
IS42S16400J-6TL
IS42S16400J-6TLI
IS42S16400J-7TL
IS42S16400J-7TLI
Other RAM ICs could be used instead, as long as they're organized as 1M x 16bits x 4 banks (64Mb) and are in a 54-pin TSOP II package.
--- Post by Tech&Music ---
Awesome, when I get back to tinkering on my O2, making a batch of these for it is definitely on the list of things to do
--- Post by Karpour ---
Fantastic! I got completely ripped off by memory4less a while ago. Ordered (cheap!) Kingston O2 RAM, they sent some worthless HP server RAM instead, then ghosted me and relisted the O2 RAM for 5x the price..
If you're ever making a batch of these, I'm 100% interested.
chunk 2
d, he'd have nothing against doing it. Also as a bonus, I do think he'd be able to make these cases from metallic materials, which would surely be more durable than the plastic material used by SGI.
My goal with this post is basically to start it as a sort of poll just to see how many people would be interested in such replica cases, to hopefully inspire Ordyne with it, so that he might consider doing a batch of these cases as well.
I'd appreciate if anyone who would be at least interested in the idea give any kind of response, just so Ordyne can see it.
Thanks!
--- Post by flexion ---
I think most people would want a replacement 'case' for the O2 first ..for reasons
--- Post by stormy ---
Yeah... Indigo 2 is rather durable. Perhaps replacement front-parts might be useful for some people. Besides this, Amiga cases work economically because there are hundreds/thousands of people who'd buy them. In SGI-land you won't find many people needing an Indigo 2 case. o2 is another story entirely though - you'd find many, many many SGI users who would buy an o2 case. As Flexion said.
chunk 2
all components bundle) a few months ago. Still waiting to install it when I have time. Comes with detailed instructions and the shipping was very quick. I would not wait if they are still available.
--- Post by Jacques ---
Just to let you all know Nick Campbell over at Niktec still has spares for the 1600SW displays, and he definitely still has CCFL kits if you need one. He has been super helpful.
In my case a replacement lamp kit would have set me back about $140-$150 due to international shipping, import and VAT. The kits retail for $49. It’s a bit too much for me to spend that for a display I only use infrequently.
Drop Nick a line if you need parts for the 1600SW
http://www.niktec.com/
[email protected]
--- Post by bjjames ---
And if I remember correctly, he shipped it via FedEx and only took 2 days or so.
--- Post by Woof ---
Jacques said:
In my case a replacement lamp kit would have set me back about $140-$150 due to international shipping, import and VAT.
Click to expand...
chunk 2
r, ground, or lack of enable signal. Chips have have a chip select line that tells them to pay attention or not, and often there's another chip that tells them to do this, some form of multiplexer.
My gut tells me that you either have a poor power connection to the chip or the enable signal never comes to the chip from the thing that controls it. If you look up the data sheet for the SRAM chip you'll find the CS line which should be the chip select line. Use a multimeter and find where that leg goes on the other SRAM chips. Because you'll probably find that either the multiplexer is damaged or you don't have a connection on that chip enable pin/leg for just U4, but the other ones do. So use the other ones to track down the Multiplexer (for that bank), likely that's where you're fix needs to be. Either a physical trace/solder joint cracking at the Multiplex to U4 CS line/pin or the Multiplex itself, since the rest of the bank seems to work.
--- Post by legodude ---
Thanks for the comments. I don't see a multiplexer on the PCB. I think the smaller chips are resistor packs and the other IC is an octal flip flop, plus the two 8pin packages which I haven't really investigated.
chunk 2
fically designed for the unit was highly appreciated and worked perfectly.
Benchmarks
SD Card used: Official Raspberry Pi 256GB Class 10 SD card
ZuluSCSI Wide-SCA Fujitsu 10K RPM 300GB Disk
Here we can see the excellent performance offered by the ZuluSCSI Wide-SCA. We can see that it truly shines in random write/read benchmarks vs the traditional disk, just comparing the smaller byte-sizes the Zulu completely destroys the Fujitsu disk by over 200% in raw performance figures. The traditional disk manages to claw itself back in sequential transfers and in larger byte-size transfers, but when 'using' your SGI on an every-day basis, the smaller byte-transfer speeds make the biggest difference in OS responsiveness. Even at the large-byte transfers we see the ZuluSCSI Wide-SCA match the spinning disk, saturating the SCSI bus at approximately 33mb/s for reads. The only area where the Zulu performs less than the spinning disk is in the writes, which are still at a respectable speed at approximately 20mb/s. It is important to remember that these performance figures are heavily dependant on the quality of the SD card! Not only the quality, but also how the SD card is prepared.
chunk 2
Pico-based BlueSCSI V2 was publicly announced, to much adulation and fanfare, around seven weeks after we began sales of the original ZuluSCSI RP2040, in late 2022. This is not a simple coincidence.
Since the initial fork, the BlueSCSI V2 team has certainly added other useful features, some of which we have chosen to merge into the ZuluSCSI code base. Multiple third parties have privately and independently chosen to share with me that this decision, which is our right under the GPLv3, infuriated BlueSCSI project leads. Hypocritical much?
Because the ZuluSCSI firmware was built around a subset of the existing SCSI2SD firmware (command-handling code), which was GPLv3 licensed, the ZuluSCSI firmware was, as required by the license, also released under the GPLv3. A common argument I've seen tossed around by people with little to no understanding of how the mechanics of many open-source licenses work is "well if you didn't want other people to use it, you shouldn't have released it as open-source software" but I personally find that to be an amusingly oversimplified analysis, and one which arguably borders on being intellectually lazy.
chunk 2
omebody that had done this exact thing. Make a little noise and start burning and yet the system kept running just fine (see attached photo) for a minute or so more before it was finally turned off.
Most of the time you can just replace the failed capacitor(s) and get another power supply and you should be fine. There is the off chance of the power supply was fine and the capacitor just went on its own, but I don't normally see that. The tantalum caps are very prone to failure (especially with advanced age) if there is excessive ripple (dirty DC power) coming out of the PSU. It's their one weakness really. They don't have the filtering tolerance of a MLCC or an electrolytic cap. But when fed correct power, that's clean, they are extremely long lived and durable.
Replacing the capacitor is pretty easy, they're all usually the same or similar values and there's lots of pictures online of the Indy motherboard to get the values off of (I've provided a link on this post below): https://bukosek.si/hardware/collection/sgi-indy/img/indy_motherboard_front.jpg
chunk 2
ber - i don't know).
- the MAC address, in reverse order (i.e. 0x56, 0x34, 0x12, 0x69, 0x00, 0x08 for 08:00:69:12:34:56) in the next six bytes.
--- Post by weblacky ---
jackal said:
Hi folks! New Octane2 owner here. Arrived without a NIC button on the frontplane so I can't use the network for lack of a MAC NIC. Gather that these are just iButtons so should be fairly trivial to program.
https://wiki.preterhuman.net/Number_In_a_Can seems to provide good information what is expected to be there. Do we think this is the totality of what would need to be written? Do we have an existing dump of the contents of a frontplane button? At $4 a pop for a DS1982 this isn't an expensive experiment, but at the same time I'd love to have something to compare against before I try to write the one-time-programmable device.
I think I have someone who's programming one for me already, but all the same I'd love to know in case I need to do it myself in future.
Click to expand...
Too much work, please contact Douglas Mashek @ http://www.mashek.com/index.php
Or
Ian Mapleson @ http://sgidepot.co.uk/sgi.html (If you're outside USA)
chunk 2
It naturally floats at +5V (standby), meaning that disconnected from the motherboard, the power supply runs and supplies regular power. The motherboard grounds out this pin to stop the power supply.
The temperature sensor appears to be a thermistor. I have not yet characterized it but will do so in a later follow up. It appears to control the fan speed, dramatically so for Sony models.
Many people also seem to be unaware that the Indy does have a reset / reboot switch. This switch is the small nub beneath the power switch.
Pin # Wire Color Function 1 N/C 2 Brown Temperature Sensor Control Voltage (0-5V) 3 Red / White Run (Ground to stop) 4 Orange Power good signal 5 N/C 6 N/C 7 N/C 8 N/C 9 Gray Power switch (other leg to Switch Common) 10 White Volume Up switch (other leg to Switch Common) 11 Blue / White Volume Down switch (other leg to Switch Common) 12 Periwinkle Reset switch (other leg to Switch Common) 13 Black Switch Common 14 Red LED Common (Anode) 15 Violet Red Status LED (Cathode) 16 Violet / White Green Status LED (Cathode) 17 Orange / White Speaker (terminal 1) 18 Green / White Speaker (terminal 2) 19 N/C 20 N/C
chunk 2
but ZuluSCSI here.. had the new ZuluSCSI Blaster in the mail today, old firmware on it.
I installed the Blaster in the Indigo2 R10k Impact using the same SD as used in the Zulu 2040 model before.
No zuluscsi.ini on the SD (means EnableSCSI2 is enabled by default). Booted up, ran diskperf, pretty good results! Yay!
Then decided to install latest firmware 2025-10-30. Still no zuluscsi.ini. Indigo2 no longer boots.. complains about Filesystem "/" XFS internal error etc.
Tried to boot again with ini file and EnableSCSI2=0 --> works, but slightly slower diskperf.. similar result as with the 2040 model.
Downgraded blaster to firmware 2025-09-04 (random pick), set EnableSCSI2=1 again. System was able to boot again, faster diskperf results (all in the 8MB/s) range.
--- Post by stormy ---
flexion said:
Not BlueSCSI but ZuluSCSI here.. had the new ZuluSCSI Blaster in the mail today, old firmware on it.
I installed the Blaster in the Indigo2 R10k Impact using the same SD as used in the Zulu 2040 model before.
No zuluscsi.ini on the SD (means EnableSCSI2 is enabled by default). Booted up, ran diskperf, pretty good results! Yay!
chunk 2
y activating CPUs again. That's probably not going to fix it, but maybe this, and some POD debug flags, lead to other hints about what caused the CPUs to be disabled.
Click to expand...
Hi, thanks for the suggestion. The problem with this approach is that the problematic node seems to hang the machine when it's installed; I can't get to a prompt. Is there a way to get it to give me control, so I can enter POD mode?
-Dave
--- Post by weblacky ---
Sure, stop booting normally. Assuming you don't actually have a real hardware problem. The issue is likely the way you're entering/booting PROM, if this is all a software issue.
From the L1 console immediately at system AC power, before PROM boot try:
turn off auto power on off with: "autopower off"
Stay in the L1 and issue a "debug 0x10d"
That will stop diags and dump into POD forcibly at future PROM boots, then you can try resetting stuff.
use "serial all" to check your DIMM recognition (not too do bad memory, just present or not)
Then do a manual "pwr up" to boot PROM with above debug changes.
chunk 2
so it sees them at boot? hinv -vm apparently builds its inventory on boot so that looks like it doesn't include the modules that were powered down.
I could post the output but don't want to flood.
--- Post by Elf ---
Welcome to the User Group
I think we have at least one or two people that are familiar with NUMAlink'ed Origin 300/350s. I will ping them and see if they can at least offer some basic advice. Also, don't be shy about pasting output for troubleshooting purposes. Feel free to inline it as a code block or attach text files to the post.
--- Post by CiaoTime ---
Odd stuff! There's no battery backup for L1 on board - but if the system was soft powered down, L1 will continue to run in the background, if that's what you're asking. L1 will always be running as long as the system has some input power on it.
If you're at the L1 prompt in serial, the command to start up all bricks in the system is as follows:
* pwr up
chunk 2
so simple but so painful as broken connections on the midplane?
Any thoughts and feedback will be greatly appreciated. I can post any pictures or terminal output anyone might deem helpful.
Thanks!
--- Post by mgchristensen ---
Additional info: I have been following the "resetenv" procedure found at wiki.preterhuman.net/Onyx2_diagnostics.
--- Post by Elf ---
I basically agree with the speculation about the midplane; I wish I could say something more helpful but it's definitely one of those things that would have to be in front of you to examine
It might be worth trying some basics like contact cleaner, looking for broken or bent pins, and so on. Past that, not that I would suggest going out and getting one, but it might be one of those things where a SCSI analyzer would be very handy to look at things from both an electrical and protocol angle.
chunk 2
modem adapter. 9600 baud is standard.
--- Post by 3DChris ---
I bought a USB to Serial adapter (male end) and a female to female serial extension cable. Is this not going to work? Or will I be OK?
--- Post by legodude ---
I would also pick up a M-F null modem adapter. It reverses transmit and receive lines. You will probably need it. (some USB-serial adapters are wired 'null', so the adapter would not be needed)
--- Post by 3DChris ---
I tried to connect my PC to the Octane via the serial cable and USB/Serial adaptor. I tried Putty and didn't see any readout on the console window. I think it's because I didn't have a null modem cable. I've picked up an adapter that's M-F and I'll try it out again tonight.
Is there any documentation about how to use the console?
--- Post by 3DChris ---
So I've got the cables all hooked up using the Null Modem adapter. Putty is open and I'm not seeing any output. Any ideas what's going on?
--- Post by legodude ---
You plugged the serial cable into port 1 on the octane? I assume you set the baud rate to 9600. I would also go into serial settings and ensure 8/1/none/none (flow control).
chunk 2
2.97/ 3.63 20% 2.64/ 3.96 3.29
PIMM0 5V aux Enabled 10% 4.50/ 5.50 20% 4.00/ 6.00 5.12
XIO 12V bias Enabled 10% 10.80/ 13.20 20% 9.60/ 14.40 12.06
XIO 5V Enabled 10% 4.50/ 5.50 20% 4.00/ 6.00 5.23
XIO 2.5V Enabled 10% 2.25/ 2.75 20% 2.00/ 3.00 2.47
XIO 3.3V aux Enabled 10% 2.97/ 3.63 20% 2.64/ 3.96 3.30
Description State Warning RPM Current RPM
-------------- ---------- ----------- -----------
FAN 0 EXHAUST Enabled 920 1193
FAN 1 HD Enabled 1560 2157
FAN 2 PCI Enabled 1120 1573
FAN 3 XIO 1 Enabled 1600 2185
FAN 4 XIO 2 Enabled 1600 2103
FAN 5 PS Enabled 1600 2003
Advisory Critical Fault Current
Description State Temp Temp Temp Temp
-------------- ---------- --------- --------- --------- ---------
NODE 0 Enabled 60C/140F 65C/149F 70C/158F 27C/ 80F
NODE 1 Enabled 60C/140F 65C/149F 70C/158F 28C/ 82F
NODE 2 Enabled 60C/140F 65C/149F 70C/158F 27C/ 80F
PIMM Enabled 60C/140F 65C/149F 70C/158F 29C/ 84F
ODYSSEY Enabled 60C/140F 65C/149F 70C/158F 27C/ 80F
BEDROCK Enabled 60C/140F 65C/149F 70C/158F 28C/ 82F
There were some strange values between "PIMM0 12V bias" and "PIMM0 1.5V".
And I also got "ALERT: Unknown PSC: 9"
Code:
chunk 2
obby knife. You also have to be careful about the order of operations in selection which piece to glue next. I did a dry run of my gluing sequence to ensure that I would not get myself into a bind.
After I got the case glued, it was still quite fragile. With the barest of handling, I could hear small cracks so I knew something else had to be done. The best solution that I came up with was to back the cracks with ABS. I thought about ordering a thin sheet of ~1/16" plastic and cutting it up, but then I realized I could simply print some ABS backing strips up on my 3D printer, which also had the advantage of being able to print a corner piece:
This _dramatically_ increased the strength, to the point where I no longer felt scared to handle it.
With the shield back in place it looks pretty good if I say so myself.
I realized after all of this that I never actually took a great after shot of the top.
I still would not put a monitor on top of it.
--- Post by SolusRaion ---
Good work; something that may restore **more strength** yet give it a better chance is using a true plastic welder system like this gadget:
https://www.amazon.com/dp/B096RPQN58
s anyone made the connection to the N64 game Killer Instinct? It's also made by Rare. So perhaps this was some sort of game-dev system inspired by Rare? Killer Impact for Killer Instinct development
--- Post by RageX ---
Killer Impact was a marketing term for a R10k @ 175mhz system with a SolidIMPACT graphics card:
NB: if you hear the description, "Killer IMPACT", this refers to a Solid IMPACT system which has a 175MHz R10000 instead of a 195MHz CPU, ie. Killer IMPACT was a marketing term born out of the lower cost CPU.
O2/Indigo2 Comparison...
--- Post by stormy ---
@RageX I know Ian Mapleson wrote that, but he also probably did not make the connection since he wasn't much of a console gamer (to my knowledge) Do you see the K logo on the 'Killer Impact' indigo? It's very similar to the K logo from Killer Instinct, the Rare game on N64. So I do highly suggest that the Killer Impact idea came from the company Rare who were using Indigo's for N64 development. It was probably used as part of their 'co-marketing' between SGI and Nintendo, to try and bring the 'hype' to both platforms simultaneously. Here's the K logo on the game:
chunk 2
13 0.17 0.29
16384 1.41 3.61 1.28 3.14 0.34 0.59
32768 1.38 3.62 1.28 3.14 0.68 1.12
65536 4.46 1.19 3.60 3.84 2.99 1.47
131072 4.48 1.57 3.47 3.93 2.61 2.34
262144 4.49 1.93 3.20 3.69 3.39 1.88
524288 4.49 2.15 2.95 3.51 2.98 2.19
1048576 4.50 2.19 2.94 3.47 3.24 1.20
Dismal. Comparatively there is a 300GB/10K drive that does this on the same bus (not at the same time of course)
Code:
# diskperf -W -n 300G_10K_SGI_Indy -c 128M -t 10 /tmp/testpath
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name : 300G_10K_SGI_Indy
# Test date : Sat Dec 14 13:53:04 2019
# Test machine : IRIX isengard 6.5 10070055 IP22
# Test type : XFS data subvolume
# Test path : /tmp/testpath
# Request sizes : min=4096 max=4194304
# Parameters : direct=0 time=10 scale=1.000 delay=0.000
# XFS file size : 134217728 bytes
#---------------------------------------------------------
# req_size fwd_wt fwd_rd bwd_wt bwd_rd rnd_wt rnd_rd
# (bytes) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s)
#---------------------------------------------------------
4096 16.22 13.13 15.82 4.09 0.01 17.52
chunk 2
, the hard drive should show up hinv. Do you hear it spin up? Have you double checked the connections between sled and hard drive? Are you sure the sled is fully seated?
Click to expand...
I do not hear it spin up, I will open it up tomorrow and see what I can see.
--- Post by legodude ---
If you have trouble getting the drive detected, I would try with a ZuluSCSI or other drive (if you have one) to ensure the scsi bus/sled are working
chunk 2
in operation: (Carrying out the Quake III benchmark!)
--- Post by mamorim01 ---
Well, that looks fantastic!
--- Post by Irinikus ---
mamorim01 said:
Well, that looks fantastic!
Click to expand...
Thanks Man!!!
--- Post by foetz ---
you're aware of the phrase "never beige"?
--- Post by Jacques ---
I painted my fist AMD K6-2 PC the same colour as the Indigo systems, my friends all had beige PCs, mine was special
There are some pics online of a red/orange O2 and a white one, both look super!
--- Post by ghost180sx ---
That looks absolutely fantastic! Does the high gloss white keep it cooler in sunny South Africa? Kidding, I'm sure it dosen't change any of the thermals.
It looks like that machine could have been made yesterday.
--- Post by jrw ---
AWESOME paint job so I have a ORIGIN 2000 and I want to paint it its ORIGINAL color what type of paint and the color code for it?
chunk 2
Cherokee PSU which shorted internally and blew the fuse because the handle broke off during shipping and the internal screw wedged itself perfectly between two big heatsinks with opposite polarity
You can test the power supplies outside of the computer by turning them on by pulling the Inhibit line low, but they need to have loads on their outputs or they will automatically shut down within a very short time (on the order of 0.1 seconds). I don't know how much load they need to see because I've never successfully tested this way.
chunk 2
onnector with a right angle version, if it is a few millimeters more compact, that would likely provide enough clearance. At some point it is likely easier/faster/cheaper to simple design a new PCB.
--- Post by joshyfishy22 ---
Love this work! I have a ton of dead SCA scsi drives that I don't throw away because I want to harvest the SCA port for making such adapter. One of the several todo list items is to make a SCA to 50pin adapter for a scsi floppy drive so I can put it in my octane which I plan to release the kicad drawings so anyone else can edit it.
--- Post by aperezbios ---
I encountered the same problem. This is our solution, inspired by this post It passes 5V from the SCA connector through to the SCSI termination pins on both the 68 pin and female 50 pin connectors. Only one diode must be soldered down, or if you enjoy living dangerously, a piece of conductive material
The remaining circuitry is not necessary unless you need/want to terminate the upper 8 bits when using the 50 pin narrow connector. The board can be assembled with or without the 68 pin and 50 pin socket connectors, depending on the need/use case.
I expect to have 250 of these PCBs in a week or so.
chunk 2
s to add afterwards will be the same one that had the Install Tools (the boot CD), then later you will need to insert the CDs again in some order determined by inst to actually install the packages.
--- Post by Jamieson ---
According to the log file on the SD card ZuluSCSI seems to be OK with the two IRIX 6.2 CD iso files and the blank hard drive image I've loaded. My Indy however is not finding any CD-ROM drives. hinv reports 7 SCSI disks SCSI(0)disk(1) through SCSI(0)disk(7) which is odd since I have only 3 image files on the SD card. Any tricks or hints to try here?
--- Post by Jamieson ---
Backing off the ZuluSCSI performance settings (disable SCSI-2, disable synchronous 10MB, etc.) makes it start working and makes the SCSI error messages go away. I don't have an external SCSI terminator on my Indy, that could also be part of the problem. I have one on order.
--- Post by Elf ---
If one device appears multiple times on the SCSI bus it typically seems to be a termination issue, at least in my experience. I think the Indy SCSI bus should work okay without a terminator on the external port though?
ix stuff can also be a lot of fun to play with if you want to mess with Linux and Itanium. They get power from a "power brick". I guess you could mod it to use AC power.
Click to expand...
I got it from some guy in Connecticut, he had a lot of SGI stuff from New York University's old systems. I took his last Origin, but he has a bunch of NL4Rs and some SGI blades up for grabs. Do the NL4Rs have Itaniums inside, or is it something different?
As for the drives, it doesn't have to be Ultra160? I can use Ultra320 drives and still be fine?
I appreciate the assistance!
--- Post by joshyfishy22 ---
Oh its that guy on ebay. I had emaild him asking if he had any other system and he said no. Glad that someone in the group got it
For the NL4R its a pretty empty box if you crack it open. All it really has is the Router ASIC that acts, well as a router for the Numalink Fabric (and a usb hub). If you can find some Altix 350 bricks you can make a pretty neat system. I warn you tho. Its addictive as hell. Once you have one you will want more. Also what color doors did you get on it? the yellow accents or just normal grey?
chunk 2
unno if any of that has to do with THIS though.
--- Post by flexion ---
Nice find! I also have a "Guinness Prototype" Indy but my sticker looks different:
chunk 2
Missouri that is officially called supercluster: https://meru.cs.missouri.edu/facilities.html
I'm like 90% confident this is it.
--- Post by oliverx74 ---
...including more than 250 SGI Indys...
Impressive!
--- Post by 0xDEADBEEF ---
The white background cloth looks somewhat pink too, I am not sure about lighting and white balance on these pictures/camera.
Anways, I never heard of green ones.
I have few regular blues, one Tandem black and one white (Siemens Nixdorf sold them AFAIK).
--- Post by oliverx74 ---
Never heard of a black or white ones...but found some glimpse now:
https://gainos.org/~elf/sgi/nekonomicon/static/e7916ec4-4484-4b4d-98fc-27b90e039d86.png
https://miro.medium.com/v2/resize:fit:800/format:webp/0*5ACr-kD-WG75d2rx.jpg
Thank you for letting me know.
chunk 2
esense of a negative DC rail on pin 6, but the OP sent me a schematic of the R3K indigo which shows something completely different there (an extra bidirectional serial transciever of some sort ...).
I also have an R4K indigo and my adapter works fine, because it has the negative rail as expected. But now I'm extremely curious if maybe the R3K indigos don't have it, and if any other machines sharing the same keyb/mouse port lack the negative rail also...
Edit: to be clear it doesn't matter if it's -8V as the manpage states, or -12V, as long as there is a negative rail of sufficient voltage present (within reason). I think anything under -6 or -7V should work.
--- Post by megaimg ---
Please, anyone with a R3K that can confirm the voltage....
--- Post by megaimg ---
Just checking if anyone with a Indigo 3K has check the voltages....I build 5 of this adapter but I unable yet to test...
chunk 2
ed = 0
Mem enabled = 2880 MB
Mem disabled = 0 MB
No. of RTRs enabled = 0
No. of RTRs disabled = 0
DIAG RESULTS:
ALL DIAGS PASSED.
**** End System Configuration and Diagnostics Summary ****
I booted in single user mode and tried /usr/gfx/startgfx. It started, gfxinfo recognised all the boards (IR2E), irsaudit went through all 104 tests without any errors. But i wasn't able to reflash the eeprom
Code:
# ./ireeprom -w -f /usr/gfx/ucode/KONA/tport.bin -F
==== Pipe 0 ====
Reading data from image...
Writing to EEPROM...
........
EEPROM code and data load complete...
Writing EEPROM header...
EEPROM header load complete...
Comparing EEPROM contents with image...
Error reading back EEPROM contents
EEPROM write failed
After that ireeprom -i told me, the rom was bad and a high negative number as revision.
I tried all the things I know and finally switched out the GE16-4. After the switch everything went normal. Until today. I tried to start the Onyx2 and got the same error as last week.
Does anybody know this error and a possible solution?
Edit:
chunk 2
the issue.
The bigger concern is how are you testing it for post? you gotta have serial or a keyboard and screen connected, at minimum.
The PSU is not ATX design either, don't make that mistake.
Click to expand...
Yes I realized that about the psu after reading how the sony is off at low enough temperature
For post testing I have a random dell ps/2 keyboard and have my dell ultrasharp 1800fp connected through the 13w3 to vga cable with the dip switches
This monitor should do SoG so I have switch 6 turned to the on position
I have also since moved the ram to have four sticks in bank one as well and swapped the reset and power button but it made no difference
chunk 2
I have no way of being able to know or even guess just how good the heat transfer properties of this tape happen to be. Additionally, the sink is attached to the board by tightly held on Kapton tape. THIS is where we start to run into compounding problems.
Over time, by way of heating and cooling cycles, the board begins to warp. It's already bent near the short edges due to how tightly the Kapton tape was applied. The repeated temperature cycles stress the two most outer chips, eventually leading to solder joint failure whereby the legs of the chip detach from the pads and no longer make solid contact. This happens to only a few at a time which is why the problem is insidious: it starts by showing itself little by little, restart by restart, until it builds up enough that it's no longer occasional or easily ignored.
So how do we solve this issue?
ot (and show by the PCB discoloration:
Result of testing so far:
Absolutely nothing on the output of the HV>LV connectors. But I did notice those resistors are getting hot on the HV side still.
--- Post by stormy ---
Any suggestions on my next steps appreciated. I assume the problem must be on the HV side after these tests? Thanks.
ps - Cheers for all your details about these psu's on the forum @Elf
--- Post by stormy ---
I am thinking it may be worth replacing the AVS1AC (datasheet attached)
There are also 2x MOC 8101 optocouplers I am thinking of replacing (datasheet attached)
Thoughts?
--- Post by Elf ---
No problem! The discoloration does seem slightly abnormal at least from the ones I have taken apart, and as far as I can recall. Unfortunately I don't have too much concrete advice to offer in terms of how to fix these, but it may help to start looking at the supply and drawing out a topology from it, which would aid in troubleshooting and seeing what piece might be malfunctioning.
chunk 2
t out or push it back in manually with little effort) and when I restart the machine, it makes a pretty terrible noise for a few seconds. In the startup sequence it reports the drive is "not ready".
I suspect this is the common problem where the little white plastic gear has fallen off its spindle. I am kicking myself for having opened the tray at all...
If the problem is what I think it is, it doesn't sound too hard to fix, but it means taking off the skin. At the moment, I am more scared of breaking the skins in the process than I am bothered by the CD (I can't recall the last time I used it).
Is this worth fixing, or should I just leave it be?
Click to expand...
--- Post by WMSGI ---
I was having the same issue, with the white plastic cog, I super glued the cog but it did not hold long enough.
I ended up buying a replacement drive with same model number on Ebay for $10. The only thing I am trying to figure out is how the eject button functions as there is a space between it and the CD's eject button. Was there a spring or piece that goes in-between both?
--- Post by ReVolt ---
I thought about doing that but figured they would all have cracked or fragile gears.
chunk 2
6 9 647-UPM1V222MHD1AA 2 647-UBW1V221MPD1TD 1 667-EEU-EB1J100S 2
Replace All Capacitors in all 3 PCB. Note: theirs is one capacitor on the little AC/DC Control board in the secondary or middle PCB
Photo 1 - Bottom or third PCB board Recapped
Photo 2 - Middle or Second PCB board Recapped
Sorry, lost or forgot to take picture of the Top or first PCB board
After assembly and testing, no luck.... So removed this time the top board only, but left everything connected to the other boards of the PSU. I plug in the power, and I was able to verify that the click and bussing sound was coming from the secondary or middle PCB. Specific to one area.
So let start testing components. So I remove the AC/DC Control board and the complete top heatsink with all the MOSFET Transistors and components (You need to disorder all the components, this big heatsink has to be pull in one piece. After testing with a multimeter, found two parts that I was not happy with the results.
TOP292YAI - AC/DC Converters
67F095 - Thermostats
So, decided to get replacement parts from Mouser:
chunk 3
7-4643-003
Tezro: Silicon Graphics® Tezro™ Visual Workstation Hardware User’s Guide: Tower Configuration 007-4564-001
Origin 200: Origin™ 200 and Origin 200 GIGAchannel™ Owner’s Guide 007-3708-002
Origin 300: SGI® Origin® 300 User’s Guide 007-4365-002
Origin 300: PCI Expansion Module User’s Guide (5.0-V Support and/or 3.3-V Support) 007-4499-002
Origin 350: SGI® Origin® 350 Server System User’s Guide 007-4566-001
Origin 3000: SGI™ Origin 3000 Series Owner’s Guide 007-4240-002
Origin 3000: SGI™ Origin 3000 Series Technical Configuration Owner's Guide 007-4311-002
Origin 3900: SGI® Origin® 3900 Server User’s Guide 007-4653-001
Please let me know, of anything that isn't right and I'll update it here. Sorry but I will need official references, I want this to be an authoritative source.
chunk 3
R46 4.74kR
2.0V might seem a lot, as there is a 800mV VCORE bump. However, these CPUs run really cool, even at 2.0V VCORE and 800MHz.
Example PROM emulator config for 800MHz:
Code:
========================================
O2 CPU PROM EMULATOR FW. REV. A00
CPU: RM7000C
Bitstream Profile: custom
Bitstream settings: WriteBackRate: DDDD, Multiplier: x7, Endianness: BE, pipelined non-block writes, TmrIntEn: ON, Tertiary cache: ON, DRVOut: 100%, TCACHE RAM: Dual-cycle deselect, UserCfgID: 01, Mult mode: integer, JTLB: 48 dual-entry, On-chip secondary cache: ON, OOO reads: OFF
Bitstream: 256 bits
Mode: Polled (all sends)
Type 'setup' + Enter for setup menu
Type 'status' + Enter for status
Type 'info' + Enter for info
Type 'boot' + Enter for USB bootloader
Type 'reboot' + Enter to reboot MCU
========================================
setup
1. R5000
2. RM5271
3. RM7000
4. RM7000A
5. RM7000B
6. RM7000C
7. RM7900 (RM7965 Mode bits)
8. SR71010A
6
1. default RM7000C 500MHz tertiary cache off
2. default RM7000C 500MHz tertiary cache on
3. default RM7000C 600MHz tertiary cache off
4. default RM7000C 600MHz tertiary cache on
5. custom
5
ikely it is enabled later by the PROM (the PROM on the MB, that the CPU executes).
Click to expand...
This surprises me, because it's not what I observed in my RM7000 swap experiments.
With no CPU Xilinx PROM present, and thus it effectively setting everything to zeros, L3 cache (which bit 12 sets) remained disabled.
My (very rudimentary and limited) understanding of the R5000 cache routine from the leaked IP32PROM code also seems to point towards this, especially this comment at the end of the routine code (which I believe is referring to the IP32PROM in this context):
Code:
/* PROM NEVER TURN ON R5000 2ND CACHE ANYWAY - */
I would expect that bit 12 would have been enabled by the O2 in the case of the RM7000 with no CPU PROM present.
Maybe there's something else on these PGA R5k boards that overrides this, much like the motherboard endian jumper presumably overrides bit 8?
It would make sense if that's the case, as there were both SC and PC variants of this module.
Handling it like that would mean not needing to keep track of two sets of Xilinx PROMs, one programmed with bit 12 on, the other with it off.
chunk 3
something like that.
UPDATE: LOL yes I didn't read all of the fine print.. it's the STL posted by gijoe77
--- Post by Jacques ---
Amazing work and also thanks to gijoe77 for sharing the stl file!
--- Post by Grim.Black ---
Where can you find the STL?
--- Post by gijoe77 ---
Grim.Black said:
Where can you find the STL?
Click to expand...
here is the original https://www.mediafire.com/file/nr7xz3r48nimjx5/moose.7z/file
--- Post by Grim.Black ---
gijoe77 said:
here is the original https://www.mediafire.com/file/nr7xz3r48nimjx5/moose.7z/file
Click to expand...
Thank you!
--- Post by Grim.Black ---
I thought I would help contribute to a good cause.
--- Post by gijoe77 ---
who here has a 3D printer? sure would love to see this printed LOL
--- Post by Irinikus ---
Work obligations unfortunately pulled me away from this for the past few days! I'll get back on it soon!
--- Post by kaigan ---
gijoe77 said:
who here has a 3D printer? sure would love to see this printed LOL
Click to expand...
chunk 3
ed my root hdd to it) without any issue. I used the mount that they provided. Must be some slight tolerance issue happening somewhere.
--- Post by philden ---
stormy said:
Hi Phil,
Just letting you know that I successfully had my zulu sca in the second bay of my o2 (when I cloned my root hdd to it) without any issue. I used the mount that they provided. Must be some slight tolerance issue happening somewhere.
Click to expand...
Thanks, stormy, I'll make some more accurate measurements and share them with Rabbit Hole.
Further tests show that I can see the Zulu drive now, but mkfs fails. I suspect the sled does need to be securely held in place to make good enough contact.
--- Post by IvanSiG ---
Update: Had the SCSI ID set to 1 - clashing with another drive. Works now, but a bit below reported speeds - sandisk extreme pro microsd (v30 a2) similar read cadence but significantly (~30-40%) lower write cadence.
I also tried 256G Sony Tough ( SF-M UHS-II U3 V60 SDXCRead 277MB/s Write 150MB/s ) but that was about 10-20% slower than sandisk.
Termination should be off if anybody comes wandering.
----
chunk 3
nnect it to ground (grounding might not actually be needed,it worked fine on my end with it floating, but the datasheet does not mention any internal biasing for this pin. Your mileage may vary).
By doing 3A or 3B or 3C, the O2 will output standard VGA signal, instead of sync on green. No VGA cable modifications are needed (in fact, it won't work if the hsync and vsync pins are removed).
Here is how the O2 looks with 3A/3B/3C, a standard VGA cable, and a monitor that before displayed a green tint:
chunk 3
0xFF compared to the raw flash dump. Besides that, they are quite similar. No extra stuff at the end of the file.
So, just write the ip32rom.image to the flash IC, with an offset from 0x100.
And good news, it verified successfully, so the flash IC is OK (well, maybe it should be replaced in the future if something similar happens).
Soldered the flash back on the MB, soldered the socket, plugged in the Dallas IC and then plugged in the MB in the chasis with only the CPU installed, and, blinking amber light!
Good, it should be blinking as I haven't installed RAM yet. The fact that it's blinking means that the PROM was executed!
Inserted some RAM, and:
--- Post by sdz ---
(yes, I don't have a SoG VGA monitor).
Also, if anyone is curious how the ASICs look like under the heatsinks (I wasn't able to find any photos), at least for this specific MB ( 030-1038-004 REV B):
The GBE is EVIL!
--- Post by ruckusman ---
That missing solder on the inductor supposed to feed the oscillator is a really good catch.
Help clarify something for me - I've been running the ip32prom.rev4.18.bin through Gxemul in recent days, knowing that it's missing something at the beginning.
chunk 3
red (cheap!) Kingston O2 RAM, they sent some worthless HP server RAM instead, then ghosted me and relisted the O2 RAM for 5x the price..
If you're ever making a batch of these, I'm 100% interested.
--- Post by Trippynet ---
Me too, I'd love a set for my O2. So if anyone is thinking of making a decent sized batch of them, happy to chip in!
chunk 3
irely though - you'd find many, many many SGI users who would buy an o2 case. As Flexion said.
chunk 3
ost by Woof ---
Jacques said:
In my case a replacement lamp kit would have set me back about $140-$150 due to international shipping, import and VAT.
Click to expand...
In your case it might be worth looking at US domestic shipping then forwarding via Shipito or other services. I do this quite often for US-based spares, then pick the cheaper shipping options that go via the local postal services. You'll more than likely still end up paying VAT, but the carrier fees are usually much lower with your own country's postal service (an example being, in Switzerland I'd pay nothing at all because it's under the Swiss Post's threshold; over the border at home with La Poste would probably cost 10 Euros for VAT and processing fees, if prepaid from the tracking number).
As for Shipito's fees, I just forwarded a couple of Onyx4 PCI cards (from 3ddoc) plus other small bits for 33 USD.
chunk 3
comments. I don't see a multiplexer on the PCB. I think the smaller chips are resistor packs and the other IC is an octal flip flop, plus the two 8pin packages which I haven't really investigated.
I did some probing with the multimeter. Ground, VCC, and address lines all seem okay, as do some other control signals. CS line is shared with the chip on the left side of the PCB, so that seems good to me as well. I'm probing leg-leg so that should take into account soldering deficits as well.
--- Post by weblacky ---
One trick I'll divulge to you, when you probe a chip leg to leg don't touch the leg. This can give a false positive reading from the downward pressure. One way you locate bad solder joints is to make sure that you're not putting any force on the board that would cause flexing but also don't put your test lead on the solder joint which could momentarily push it together to complete the circuit. Make sure you're always probing just away from the solder joint on the pad area of the track so hopefully you catch any separation that way.
chunk 3
ed at approximately 20mb/s. It is important to remember that these performance figures are heavily dependant on the quality of the SD card! Not only the quality, but also how the SD card is prepared. More on this in the next section.
Importance of SD card authenticity and preparation
Using this ZuluSCSI Wide-SCA has actually brought something to my attention - the prevalence of FAKE SD cards on the market. I previously used Sandisk 300mb/s and 200mb/s SD cards in other SCSI emulators and did not think twice, but when trying my cards in the ZuluSCSI Wide-SCA it became apparent that there was a serious problem - the speeds I achieved in benchmarks were highly compromised! At first I was confused, until I started to uncover the fact that my SD cards were FAKE. I had purchased them on Amazon and previously had no idea, they seemed genuine to me. I do not want to clutter this benchmark thread with images unrelated to the real performance achieved by using authentic cards, but I will leave a 'FakeSD.png' in the attached images of this thread, so you can see the difference in performance.
chunk 3
to use it, you shouldn't have released it as open-source software" but I personally find that to be an amusingly oversimplified analysis, and one which arguably borders on being intellectually lazy.
BlueSCSI Pico/V2 costs less because they are manufacturing and selling JLC-manufactured and assembled boards, and do not have to incur the actual development costs, because we do that for them. Additionally, the two core BlueSCSI maintainers directly receive remittances/royalties for every assembled and kit BlueSCSI sold through their approved "makers" (AKA resellers). They are running a business, have registered business LLC entities, and yet have repeatedly claimed it's "not for profit", simply because their hardware designs are also open source.
Since November of 2023, nearly two years ago, an OSHW-licensed ZuluSCSI Pico hardware design , released under the OSHWA-approved CERN OHL-Strict V2 license, has been publicly available. This is an Open Source Hardware Alliance-certified design . The original BlueSCSI Pico/V2 hardware design explicitly prevented commercial use by non-approved third parties.
chunk 3
's lots of pictures online of the Indy motherboard to get the values off of (I've provided a link on this post below): https://bukosek.si/hardware/collection/sgi-indy/img/indy_motherboard_front.jpg
The affected capacitor (for me) was C52, see both photos for comparison. I can't guarantee it's the exact same capacitor for you. But this is what you'd be looking for. I used high-end desoldering tweezers to simply remove this and replace it in two minutes. But if you don't have that kind of equipment you may have to get creative.
The heat should've discolored the capacitor. It may not be as bad as the picture that I provided because the previous owner just let it go as they were wondering what that smell was. That's why I always recommend that people start an Indy with its cover off when they first test start it because this can happen and you'll see where the smoke is coming from.
chunk 3
in future.
Click to expand...
Too much work, please contact Douglas Mashek @ http://www.mashek.com/index.php
Or
Ian Mapleson @ http://sgidepot.co.uk/sgi.html (If you're outside USA)
And just buy one. There have been hundreds of thousands of scrapped SGI octane's and I'm sure either of these guys has a spare "number in a can" button for you that you can use. It was the removable module that you're supposed to take with you when you change octane systems to keep your software licenses intact, that's why they made it removable.
Nobody's bothered to figure out how to make one because there's just so many of them, it's not worth it.
Hopefully you can buy one for like $35 bucks or something....
--- Post by jackal ---
Good point, I had just assumed it would be difficult to source but it sounds like that's a good option. Thanks!
miod thanks for the info as well. I'd be lying if I said I didn't still want to try to clone one, but it'll definitely be on the backburner now.
--- Post by Jacques ---
I may still have one floating around from when I had some donor Octanes. I could check?
chunk 3
14 Red LED Common (Anode) 15 Violet Red Status LED (Cathode) 16 Violet / White Green Status LED (Cathode) 17 Orange / White Speaker (terminal 1) 18 Green / White Speaker (terminal 2) 19 N/C 20 N/C
To aid in Indy power supply testing, I have made a small breakout board. I may release or sell this design (if there is interest) in a further update. More Indy PSU information to follow!
--- Post by Elf ---
Corrected the part about the reset switch being the system status indicator LED. It is actually the small nub below the power switch. Whoops! Not sure why I remembered it that way.
--- Post by Elf ---
Here is some information about the performance of Indy power supplies, based on an arbitrary sample of one Sony and one Nidec. However, just based on previous observations these seem to be fairly representative of their kinds. I will break this up amongst multiple posts due to attachment limits.
First, some specifications on the Sony , and then some measurement information:
Rail Rating +3.3V 7A +5V 25A +5V standby 0.02A +12V 4.5A -12V 0.75A
chunk 3
Indigo2 R10k Impact using the same SD as used in the Zulu 2040 model before.
No zuluscsi.ini on the SD (means EnableSCSI2 is enabled by default). Booted up, ran diskperf, pretty good results! Yay!
Then decided to install latest firmware 2025-10-30. Still no zuluscsi.ini. Indigo2 no longer boots.. complains about Filesystem "/" XFS internal error etc.
Tried to boot again with ini file and EnableSCSI2=0 --> works, but slightly slower diskperf.. similar result as with the 2040 model.
Downgraded blaster to firmware 2025-09-04 (random pick), set EnableSCSI2=1 again. System was able to boot again, faster diskperf results (all in the 8MB/s) range.
Click to expand...
It seems like whatever the regression was, it is the same between Zulu and Bluescsi. Do you think you could report it as an issue on the Zulu github please flexion?
chunk 3
s, then you can try resetting stuff.
use "serial all" to check your DIMM recognition (not too do bad memory, just present or not)
Then do a manual "pwr up" to boot PROM with above debug changes.
If you get it working, issue "debug 0" to go back to normal boot (from L1). And you can set auto power back to ON, with "autopower on".
--- Post by mcguire ---
weblacky said:
Sure, stop booting normally. Assuming you don't actually have a real hardware problem. The issue is likely the way you're entering/booting PROM, if this is all a software issue.
From the L1 console immediately at system AC power, before PROM boot try:
turn off auto power on off with: "autopower off"
Stay in the L1 and issue a "debug 0x10d"
That will stop diags and dump into POD forcibly at future PROM boots, then you can try resetting stuff.
use "serial all" to check your DIMM recognition (not too do bad memory, just present or not)
Then do a manual "pwr up" to boot PROM with above debug changes.
If you get it working, issue "debug 0" to go back to normal boot (from L1). And you can set auto power back to ON, with "autopower on".
Click to expand...
chunk 3
e asking. L1 will always be running as long as the system has some input power on it.
If you're at the L1 prompt in serial, the command to start up all bricks in the system is as follows:
* pwr up
The asterisk is critical: it's the keystroke that tells the main CPU brick to power up every brick that's linked up to it, and without it, only one of the four bricks will come up on reboot. All the bricks in the system should be plugged in and showing the 'Powered Down' state before this command is run. Don't try pressing the power buttons on the front!
Let me know if that's any help!
--- Post by HAL ---
Hi,
first of all I wonder how the O300 bricks are connected to each other ? Is it a cluster setup with 4 bricks where all each of them boots
Irix or are they connected through those thick cables (numalink) with only 1 brick booting and the others provide their resources to a
single system image ?
The available resources are shown in the "hinv" (type hinv -v in a shell) ; so if the hinv only shows 2 or 4 cpus, then you will have to reboot
the bootable brick so it can discover the other bricks and add their resources to the system (this applies to a numalink'ed setup).
chunk 3
that, not that I would suggest going out and getting one, but it might be one of those things where a SCSI analyzer would be very handy to look at things from both an electrical and protocol angle.
--- Post by joshyfishy22 ---
Sorry for necroing, But im quite interested about what is causing the issue. Im going to be getting an onyx2 from kaigan which sometimes has issues with seeing the internal scsi devices and I was wondering if you found a solution? He had bought up the theory that it was a power issue since its a quad 400 with 2 rm10s which specs far exceeds the 120v he was giving it. Might be the psu limiting the power? not sure if that makes sense or not.
--- Post by joshyfishy22 ---
I think I figured it out. The internal scsi controller is on the io6g and carries the bus over the white connectors to the midplane. I had the same issue but spraying some contact cleaner into the white connector and reseating it fixed the scsi errors and now the internal scsi bus works! Felt like sharing if anyone else has this issue.
chunk 3
--- Post by legodude ---
You plugged the serial cable into port 1 on the octane? I assume you set the baud rate to 9600. I would also go into serial settings and ensure 8/1/none/none (flow control).
--- Post by 3DChris ---
I just checked everything again. Plugged into Serial port 1 on the back of the Octane. Serial cable connected to the null modem adapter connected to the serial to usb adapter. Putty is set to 9600, 8, 1, none, none. Listening on COM5 (usb serial connection). I'm getting a black window with a green cursor at the start. No text. Nothing.
I'm getting video output on the SGI. The XIO 1Gb/s network switch is all lit up and blinking with solid lights on "AB" on the back of it. Front of the system has 3 green lights. Upper left single light, lower left and lower right pair. the other 4 aren't lit up.
Red light on the front of the system. Keyboard has no lights on and is not responsive to any num lock, or caps lock lights. No mouse curser on screen either.
Monitor says, "running power on diagnostics". That's all it's been doing at this point.
chunk 3
C/ 80F
BEDROCK Enabled 60C/140F 65C/149F 70C/158F 28C/ 82F
There were some strange values between "PIMM0 12V bias" and "PIMM0 1.5V".
And I also got "ALERT: Unknown PSC: 9"
Code:
No keyboard found, skipping keyboard test
No mouse found, skipping mouse test
Missing PS/2 device(s) AND console set to "g"
PS/2 Keyboard & Mouse diagnostics passed with a possible problem
Graphics diagnostics
Odyssey board #0 found on nasid 0
Running Odyssey xtalk sanity diag...
Board version 1 - Buzz revision 2B
On board sdram size: 128 Mb
Cas latency: CAS 3
4 banks by sdram module
Running Odyssey Buzz registers diag...
Device passed diagnostics
Installing PROM Device drivers ............
Base I/O Ethernet set to /dev/ethernet/ef0
Installing Graphics Console...
graphics install: searching for pipe 0
Walking SCSI Adapter 0, (pci id 1)
Walking SCSI Adapter 1, (pci id 1)
chunk 3
sRaion ---
Good work; something that may restore **more strength** yet give it a better chance is using a true plastic welder system like this gadget:
https://www.amazon.com/dp/B096RPQN58
Used it for repair of car bumpers.
--- Post by RetroHoarder ---
Mine just arrived like this. Heartbreaking
chunk 3
------------------------------
16384 25.69 24.85 19.83 8.04 9.23 4.28
32768 30.92 29.31 26.14 14.67 17.07 7.36
65536 33.89 31.74 30.93 14.80 27.47 11.58
131072 36.04 33.47 34.08 19.08 34.01 16.37
262144 37.23 34.57 36.35 21.46 36.25 20.50
524288 38.07 35.06 33.98 22.38 33.21 23.34
1048576 38.29 35.09 36.02 24.44 36.09 25.09
2097152 38.44 35.35 36.38 29.97 36.88 29.32
4194304 37.65 32.53 37.74 31.90 37.86 32.19
--- Post by legodude ---
Nice work
I'm impressed with how well the Seagate 15k held up in comparison
chunk 3
ed as part of their 'co-marketing' between SGI and Nintendo, to try and bring the 'hype' to both platforms simultaneously. Here's the K logo on the game:
chunk 3
q_size fwd_wt fwd_rd bwd_wt bwd_rd rnd_wt rnd_rd
# (bytes) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s)
#---------------------------------------------------------
4096 16.22 13.13 15.82 4.09 0.01 17.52
8192 17.00 1.30 13.63 5.66 0.00 20.44
16384 13.77 13.41 20.61 4.20 0.76 24.40
32768 14.03 13.44 21.23 4.25 2.12 24.35
65536 15.78 12.97 17.80 4.08 1.26 28.79
131072 16.84 13.27 17.07 3.18 12.16 27.01
262144 13.70 11.72 16.02 4.54 17.24 25.63
524288 12.88 15.86 16.86 5.83 14.97 24.19
1048576 14.46 12.13 15.55 10.01 11.39 23.87
2097152 14.23 12.73 16.99 11.34 13.97 24.01
4194304 14.07 10.86 13.46 14.61 16.69 18.73
Conclusion: I will probably have to deal with the noise.
--- Post by Elf ---
Interesting; I had always assumed that with the updated v6 design (no longer using SPI mode to write to the SD card) the limiting factor was the 10MB/s SCSI-II bus. I wonder where the bottleneck is?
--- Post by stormy ---
Could you please list the firmware version of the scsi2sd v6, there have been quite a few updates in the last few months. There may have been some improvements.
chunk 3
the 50 pin narrow connector. The board can be assembled with or without the 68 pin and 50 pin socket connectors, depending on the need/use case.
I expect to have 250 of these PCBs in a week or so.
--- Post by legodude ---
Alex, that's fantastic
I can't wait until you have a version for your FW adapter
--- Post by aperezbios ---
@legodude Thanks! The first batch of these PCBs are now in transit to us. If you'd like, I'd be happy to send you one for the cost of shipping.
--- Post by aperezbios ---
legodude said:
Alex, that's fantastic. I can't wait until you have a version for your FW adapter
Click to expand...
The SCA80 to IDC50F version of this adapter is now available on the Rabbit Hole Computing web shop.
The PCB was designed in such a way that it can either convert from SCA to 68-pin 16-bit wide SCSI, or SCA to 50 pin SCSI, dependin on how it's assembled. The only necessary active component is a diode through which the +5V from the SCA connector through to the SCSI TERMPWR pins on both the 68 and 50 pin SCSI connectors, therefore allowing you to power the attached ZuluSCSI or derivative/clone SCSI emulator to it.
chunk 3
s multiple times on the SCSI bus it typically seems to be a termination issue, at least in my experience. I think the Indy SCSI bus should work okay without a terminator on the external port though?
--- Post by Jamieson ---
It was also my impression that Indy doesn't need a terminator on the external port. The ZuluSCSI is the only thing on the bus and it has termination enabled. I'm still trying out various settings in the ini file. There is SCSI mode 1 or 2, sync or async, 5MBps or 10MBps rates. Also a "SelectionDelay" variable that seems to have an impact on the Indy's SCSI controller.
I found some premade mame images with IRIX 5.3 and 6.5 and after converting them from CHD to raw format, these boot on the ZuluSCSI in my Indy.
--- Post by delucks ---
I have also used a ZuluSCSI rev1.1 to install a Challenge S. The ZuluSCSI is the only item on my SCSI chain (connected via the upper drive's connector) and it doesn't need an external terminator. I'm using SCSI2 mode with async transfer (MaxSyncSpeed = 0), either 5MBps or 10MBps synchronous mode results in a disk error doing any operations on the CDs or virtual hard drive.
ricks you can make a pretty neat system. I warn you tho. Its addictive as hell. Once you have one you will want more. Also what color doors did you get on it? the yellow accents or just normal grey?
The Ultra 320 drives also work well. Really anything with an SCA connector on it will work. I use HP Ultra 320 300gb drives in my Onyx 350 and assorted other bricks for storage.
Do you know if he still has those altix 450s in the picture on the ebay listing? Same with the Numalink cables too? Every time I see that picture I get sad that they prob all got scrapped.
--- Post by jander31 ---
joshyfishy22 said:
Oh its that guy on ebay. I had emaild him asking if he had any other system and he said no. Glad that someone in the group got it
For the NL4R its a pretty empty box if you crack it open. All it really has is the Router ASIC that acts, well as a router for the Numalink Fabric (and a usb hub). If you can find some Altix 350 bricks you can make a pretty neat system. I warn you tho. Its addictive as hell. Once you have one you will want more. Also what color doors did you get on it? the yellow accents or just normal grey?
chunk 3
, anyone with a R3K that can confirm the voltage....
--- Post by megaimg ---
Just checking if anyone with a Indigo 3K has check the voltages....I build 5 of this adapter but I unable yet to test...
--- Post by nuclear ---
I have some news regarding this issue. I was contacted recently by a couple of people verifying that the R3000 indigos indeed lack the necessary -8v at the port. I came up with a couple of experiments for them to try, how to hack the board ot maybe attempt to derive the -5v in a different way, and apparently experiment #2 actually works! Here's the instructions:
What this does is remove the regulator, and instead use its accompanying capacitors to smooth out the voltage present on the transmit line ("transmit" from the viewpoint of the workstation), which is usually idling at -5v when it's not sending commands to the keyboard.
Very little current is drawn from this line, since it only goes to the opamp for level translating and inverting the signals going from the adapter to the workstation, so I don't expect there to be any danger of damaging something with this hack.
chunk 3
ed out the GE16-4. After the switch everything went normal. Until today. I tried to start the Onyx2 and got the same error as last week.
Does anybody know this error and a possible solution?
Edit:
After booting in single user mode, i got a bad eeprom, after ireeprom -c a good one, but gfx don't show. I can't explain this behaviour.
--- Post by joshyfishy22 ---
I have read the thread on irixnet and was wondering if there has been any progress in getting the pipe up and running?
chunk 3
oblem is insidious: it starts by showing itself little by little, restart by restart, until it builds up enough that it's no longer occasional or easily ignored.
So how do we solve this issue?
There are likely many ways to resolve this. I'm going to outline the method I took, realizing that there may be better methods still. Ultimately, the solution I ran with was to remove the heatsinks from each board along with the thermal tape, carefully inspect every solder joint, repair those that were broken, and reassemble the units with better thermal interface material and some custom 3D printed pieces to even out the mounting pressure.
You can see from the previous image that the TRAM is composed of three separate chips. Each one is densely populated with pins that are exceptionally small and fragile. If you have experience working with SMD components then you will already be all too familiar with the delicate care needed to work on these chips.
chunk 3
6 Mbytes
Secondary unified instruction/data cache size: 1 Mbyte on Processor 0
Instruction cache size: 8 Kbytes
Data cache size: 8 Kbytes
Integral SCSI controller 0: Version WD33C93B, revision C
Disk drive: unit 1 on SCSI controller 0
On-board serial ports: 2
On-board bi-directional parallel port
Graphics board: GR2-XZ
Integral Ethernet: ec0, version 1
Iris Audio Processor: revision 10
IRIS 7#
IRIS 7# uname -a
IRIX IRIS 6.5 10070055 IP20
--- Post by flexion ---
Hi!
SCSI2SD should run fine in this machine. I also use one in my Iris Indigo.
This also looks suspicious: "# XFS file size : 0 bytes"
I don't remember if scsi2sd writes a log file somewhere to the SD card... probably not. ZuluSCSI does, and I switched to zulu for all my other machines, which is way more convenient.
maybe check the scsi2sd settings again or post here for comparison?
--- Post by altstar ---
Hi,
Worked a few things out. The "# XFS file size : 0 bytes" and the pwrite/pread errors only occur on the first run. Afterwards, with the test file created, there are no further errors.
I have also tried to turn on the SCSI 2 support on the SCSI2SD V6 but this has changed little.
chunk 3
fer in terms of how to fix these, but it may help to start looking at the supply and drawing out a topology from it, which would aid in troubleshooting and seeing what piece might be malfunctioning.
--- Post by weblacky ---
Well, I have a thermal imager, so I cheat. Normally I used a 300W current limiting light bulb setup for draw indication. Usually you either have a non-starting, constantly restarting (pulsing bulb), or a start followed by a protection mechanism engaging.
I use a thermal imager to stare (briefly) at the PSU PCBs while powered, shows shorted Diodes and FETs very well. If it's a resistor issue, that's very different. If you want to troubleshoot a resistor issue, desolder one-end of each resistor and recheck its value against markings, replace if out of spec.
I do not normally testing PSUs powered (I have a lot of power-off testing gear), but assuming you have a current limiting setup made from a light bulb with enough wattage to allow normal startup, it's great way of doing a cheap voltage injection-style hunting.
--- Post by stormy ---
Update, I am getting 7.7v AC and 5v AC from the double thick wires going from HV to LV.
chunk 3
ween it and the CD's eject button. Was there a spring or piece that goes in-between both?
--- Post by ReVolt ---
I thought about doing that but figured they would all have cracked or fragile gears.
There are two plastic pieces in front of the CD-ROM. One is a black internal (I'll call it a bracket to distinguish it) and the other is the colored bezel that clips on the front of the tray and ejects with it. The bezel's button has a little pointed nub that sticks through a hole in the black bracket. The black bracket then has a linkage/extension that transfers the button press to the drive's button. The linkage is part of the bracket, except it's missing on one of mine (surely it crumbled like these love to do).
--- Post by ghost180sx ---
Wasn't there an STL file to reprint the drive's gear?
--- Post by WMSGI ---
It would be great if anyone can repost the link. thx
chunk 4
R71010A
6
1. default RM7000C 500MHz tertiary cache off
2. default RM7000C 500MHz tertiary cache on
3. default RM7000C 600MHz tertiary cache off
4. default RM7000C 600MHz tertiary cache on
5. custom
5
[PROM] Existing RM7000C custom bitstream:
0000010110101010100000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
1. Write-back data rate
0. DDDD (default)
1. DDxDDx
2. DDxxDDxx
3. DxDxDxDx
4. DDxxxDDxxx
5. DDxxxxDDxxxx
6. DxxDxxDxxDxx
7. DDxxxxxxDDxxxxxx
8. DxxxDxxxDxxxDxxx
0
2. SysClock to Pclock Multiplier
0. Multiply by 2/x
1. Multiply by 3/x
2. Multiply by 4/x
3. Multiply by 5/2.5
4. Multiply by 6/x (default)
5. Multiply by 7/3.5
6. Multiply by 8/x
7. Multiply by 9/4.5
6
3. EndBit
0. little-endian
1. big-endian (default)
1
4. Non-block write control
0. R4000 compatible non-block writes
2. pipelined non-block writes (default)
3. non-block write re-issue
2
5. Timer Interrupt Enable/Disable
0. Enable timer interrupt on IP[5] (default)
1. Disable timer interrupt on IP[5]
0
6. External tertiary cache
, as there were both SC and PC variants of this module.
Handling it like that would mean not needing to keep track of two sets of Xilinx PROMs, one programmed with bit 12 on, the other with it off.
--- Post by sdz ---
I have double checked, and bit 12 is definitely set to 0 on the R5k 180MHz CPU PROM.
According to the datasheet, bit 12 doesn't have an override pin, only bit 8 has one.
The IP32 PROM might just behave differently when a RM7000 is installed (for the RM7000 the cache size isn't even set by the PROM bitstream).
Also, if no PROM is installed, at least for the R5k PGA I have at hand, all those bits might be all zeroes, or ones, or random. There is no guarantee that without a PROM IC installed it will read all zeroes, as the ModeIn pin is high impedance and there is no external biasing.
The PGA R5k without a PROM installed is completely dead.
@Tech&Music cache is indeed enabled on the 180MHz R5k module, I made a mistake when decoding, first post is updated.
--- Post by sdz ---
2. R5k 200MHz 1MB external cache
Raw bitstream:
chunk 4
the past few days! I'll get back on it soon!
--- Post by kaigan ---
gijoe77 said:
who here has a 3D printer? sure would love to see this printed LOL
Click to expand...
Looking at the size of my O2, I'd think that a lot of standard FDM printers should be able to print the main body in one piece. I have a larger format one (500mm^3 build volume) and I'll give this a go once the final model is ready.
--- Post by Irinikus ---
A good initial test would be to produce something similar to Dodoid's mini IRIS Indigo, as once the model's complete, it can be scaled to any size you want. (This would allow for it to be thoroughly checked out before moving forward with possible full-scale production)
It's going to take allot of work to get it to the required fidelity!!! (So it will take some time!)
I would prefer the use of a power deposition, or sintering machine for this purpose!!!! (The filament machines produce a messy output!)
--- Post by Irinikus ---
Obviously the goal here is to produce a fully functional set of full sized plastics, but it will also be cool to release miniatures was well, besides I already have this little model up my sleeve!
chunk 4
ence.
I also tried 256G Sony Tough ( SF-M UHS-II U3 V60 SDXCRead 277MB/s Write 150MB/s ) but that was about 10-20% slower than sandisk.
Termination should be off if anybody comes wandering.
----
I've got mine today and can't get anything out of it. Best I could do is to get debug logs which show my SD, files and configuration are fine and there is some scsi negotiation but the disks are not shown in hinv. Neither of the two slots work. Will try another sled now but not holding my breath.
Should termination be on? I've tried both without success, but would be good to know for sure.
--- Post by legodude ---
Did you try benchmarks with debug turned off?
--- Post by stormy ---
@IvanSiG FYI when I got my Zulu-wides, I quickly found out two important things:
1. Make sure your Sandisks are not counterfeit (it's quite hard to tell! But almost ALL of mine were counterfeit!)
- I bought official Raspberry Pi SD cards directly from PiHut to solve this and to make sure I got something official. The new Pi SD cards are highly regarded for running operating systems on, they also support native command queuing. This made a massive difference.
chunk 4
he oscillator is a really good catch.
Help clarify something for me - I've been running the ip32prom.rev4.18.bin through Gxemul in recent days, knowing that it's missing something at the beginning.
Now from what I know the ip32prom.rev4.18.bin that is floating around, it is usually obtained by using the dump command, which clearly doesn't capture what should be the whole contents of that PROM chip so it can boot, whereas the ip32prom.image does have the code necessary to boot successfully.
Speculating, but that second non-booting main board may have been accidentally flashed with ip32prom.rev4.18.bin by someone thinking that they were upgrading the PROM to 4.18.
--- Post by sdz ---
Those extra bytes at the start of ip32prom.image don't get written to the flash IC. Most likely they are there so that the flashing tool can idendify what it's actually flashing.
I don't think the flashing tool will let you flash a PROM image without that header. I can make more tests after I add a test socket (for the flash IC) to an O2 MB, so that I can easily recover it.
chunk 4
y cost 10 Euros for VAT and processing fees, if prepaid from the tracking number).
As for Shipito's fees, I just forwarded a couple of Onyx4 PCI cards (from 3ddoc) plus other small bits for 33 USD.
--- Post by bbellomo ---
Hi fellow SGI 1600W fans. I have a related question and hope I'm posting in the right spot, as I'm new here. When I boot up my unit, connected via Multi Link, it displays a "Backlight Fail" warning - I assume replacing the lamps would fix this? But I am also getting a "Main Cntrl Reg Fail" warning. Afterward it displays the DVI input, but flickers on and off repeatedly. Tried new 12V power supplies - no help. Is this Main Cntrl Reg Fail related to the lamps also (and will be fixed by replacing lamps?) or some other issue I need to tackle? Any insights would be so appreciated. Thank you!!
chunk 4
uld momentarily push it together to complete the circuit. Make sure you're always probing just away from the solder joint on the pad area of the track so hopefully you catch any separation that way.
Also make sure that you are performing both readings for ohms and a reading in diode mode when performing your tests. What I would do is also compare bank to bank readings. That is if you assume positionally that U4 as a doppelgänger in the other bank, use ohms mode and diode mode to measure all the pins of the suspect chip and compare those readings to its doppelgänger in the other bank. You would assume incredibly similar to same values. One of the great things about troubleshooting circuits that have replication in them is that multiple channels or multiple grouping of things often have duplicate designs in the same circuit with the same parts that are the same vintage from the same supplier. So you can compare parts of the circuit with itself and any differences can lead you down a new path.
chunk 4
d with images unrelated to the real performance achieved by using authentic cards, but I will leave a 'FakeSD.png' in the attached images of this thread, so you can see the difference in performance. Overall: The ZuluSCSI Wide-SCA will expose any fake SD cards you may have, it demands the highest quality SD cards without compromise!
In terms of preparation I am talking about formatting the SD card using the official SD-card formatter by the SD Association . When I first heard of this I initially rolled my eyes thinking it would have no effect, but time-after-time it has been shown that doing a full format with --overwrite will significantly improve the performance of the SD card when used in high-speed devices like the ZuluSCSI Wide-SCA. Make sure to properly prepare your card, use the --overwrite option.
Where to buy
Official price on Rabbit Hole Computing website as of Dec 2025: $129
ZuluSCSI - A hardware SCSI HDD & CD-ROM emulator
chunk 4
been publicly available. This is an Open Source Hardware Alliance-certified design . The original BlueSCSI Pico/V2 hardware design explicitly prevented commercial use by non-approved third parties.
On September 9th, 2024, ~ten months after I chose to release a version of the ZuluSCSI hardware design under the aforementioned license, the BlueSCSI V2 team chose to follow suit, re-licensing their hardware designs from the original Creative Commons Non-Commercial-ShareAlike 4.0 ( CC BY-NC-SA 4.0 ) license to the same more-permissive CERN OHL-S V2 license that we'd previously chosen to use.
Finally, it's important to know that the ZuluSCSI firmware began life as a fork of the original BlueSCSI V1 firmware, which seems to have been what originally ticked off the BlueSCSI maintainer back in April of 2022. By his own admission, only ~30 lines of the original BlueSCSI V1 source code remained by the time we released the very first ZuluSCSI V1, which significantly outperformed the original BlueSCSI V1. One can only assume that this was seen as an existential threat.
chunk 4
g what that smell was. That's why I always recommend that people start an Indy with its cover off when they first test start it because this can happen and you'll see where the smoke is coming from.
Be aware that I would recommend you not use hot air in this section as the three silver looking components next to C52 (marked U35, U36, & U38) are an obsolete form of resettable polyfuse that's no longer available. I have a small stash of them but they have a tendency to fail if exposed to heat for desoldering them or soldering them in wrong. So if you heat the whole region those three silver components right next to that cap could be ruined which will disconnect major parts of the motherboard circuit. I recommend you use two soldering irons, one on each end, to try to successfully get the cap off the board or buy a really cheap set of ceramic heating desoldering tweezers for like $20 that you only need to use once.
If you can take pictures and post them we might be able to see something in the pictures to help you out, you'll need really good lighting though to get good pictures.
Good Luck.
chunk 4
didn't still want to try to clone one, but it'll definitely be on the backburner now.
--- Post by Jacques ---
I may still have one floating around from when I had some donor Octanes. I could check?
--- Post by jackal ---
I think I just snagged one, but absolutely thanks for the offer <3
--- Post by bplaa.yai ---
Welcome @miod , good to see veterans here !
--- Post by jackal ---
Everything above being valid, it does look like the software to write the NIC is actually obtainium...
Index of /pub/archive/ftp.sgi.com/sgi/suppliers/octane-nic
But the old programmer is expensive and it's still easier to source a replacement. All the same, good to know it's there if someone needs it.
--- Post by chulofiasco ---
i can program buttons.
chunk 4
ongst multiple posts due to attachment limits.
First, some specifications on the Sony , and then some measurement information:
Rail Rating +3.3V 7A +5V 25A +5V standby 0.02A +12V 4.5A -12V 0.75A
Electrically the Sony seems to be the better supply versus the Nidec, but it is still not great by modern standards as can be seen by its performance under various load conditions:
Load / State Power Factor Watts (True power) 3V3 rail
volts/ripple 5V rail
volts/ripple 12V rail
volts/ripple -12V rail
volts/ripple Soft power-off -0.4854 3.267W 0/0 0/0 0/0 0/0 No-load -0.4608 6.174W 3.328V, 124mVpp 5.28758V, 84mVpp 12.5171V, 80mVpp ~ -12V, 70mVpp 5V @ 2A load -0.5053 17.807W 3.316V, 156mVpp 5.13511V, 114mVpp 12.5067V, 158mVpp ~ -12V, 134mVpp 5V @ 10A load -0.6112 64.69W 3.271V, 274mVpp 4.88171V, 128mVpp 12.4618V, 196mVpp ~ -12V, 164mVpp
chunk 4
Click to expand...
It seems like whatever the regression was, it is the same between Zulu and Bluescsi. Do you think you could report it as an issue on the Zulu github please flexion?
--- Post by aperezbios ---
I've decided to create a new thread which goes into some detail in an attempt to explain the nature of the relationship between the ZuluSCSI and BlueSCSI Pico/V2 firmware. The BlueSCSI V2 firmware is a derivative fork of the original ZuluSCSI RP2040 code base. Please feel free to participate in a respectful and civilized manner, if anyone has any questions on that front. Please keep this original thread on-topic.
chunk 4
OM with above debug changes.
If you get it working, issue "debug 0" to go back to normal boot (from L1). And you can set auto power back to ON, with "autopower on".
Click to expand...
Hi Weblacky, thanks for the suggestion. Do you mean connecting to the MSC?
-Dave
--- Post by mcguire ---
Reawakening this old thread with a report of success. We were building out new exhibits and I saw the '2400, which has always been one of my favorite machines due to some personal connections, sitting on the floor looking sad. I was about to rally the troops to roll it back to the warehouse when I decided to take another crack at it. I did a lot of reading in various places, in particular the "purple book", some old posts from the redoubtable jan jaap and a post on the Higher Intellect wiki.
The machine is an Origin 2000, rack config with an MMSC, two modules, eight dual 400MHz R12K nodes, 32GB of RAM. It has been mine for about twenty years but had originally been installed at NASA Goddard Space Flight Center in Greenbelt, Maryland, USA. It now resides at the Large Scale Systems Museum in Pittsburgh, PA, where it is now an operational and available exhibit system.
chunk 4
if the hinv only shows 2 or 4 cpus, then you will have to reboot
the bootable brick so it can discover the other bricks and add their resources to the system (this applies to a numalink'ed setup).
--- Post by nondem ---
First THANKS to all of you for the replies!
Here is the current hinv output:
vortex 1# hinv -vm
Location: /hw/module/001c02/node
IP59_4CPU Board: barcode NSG072 part 030-1989-003 rev -B
Location: /hw/module/001c02/IXbrick/xtalk/15
2U_INT_53 Board: barcode NST935 part 030-1809-006 rev -B
Location: /hw/module/001c02/IXbrick/xtalk/15/pci-x/0/1/ioc4
IO9 Board: barcode NSW748 part 030-1771-005 rev -B
4 1.0 GHZ IP35 Processors
CPU: MIPS R16000 Processor Chip Revision: 3.0
FPU: MIPS R16010 Floating Point Chip Revision: 3.0
CPU 0 at Module 001c02/Slot 0/Slice A: 1.0 Ghz MIPS R16000 Processor Chip (enabled)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 1 at Module 001c02/Slot 0/Slice B: 1.0 Ghz MIPS R16000 Processor Chip (enabled)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 2 at Module 001c02/Slot 0/Slice C: 1.0 Ghz MIPS R16000 Processor Chip (enabled)
chunk 4
as no lights on and is not responsive to any num lock, or caps lock lights. No mouse curser on screen either.
Monitor says, "running power on diagnostics". That's all it's been doing at this point.
--- Post by 3DChris ---
Ugh... now the main rear fan has failed, and the system shut itself off due to overheating. I'll need to replace that before I do anything else at this point.
--- Post by bitpak ---
I'm not an expert but I would try to start it without hard drives and see if it gets to the PROM menu.
One time I had a similar problem with my Octane and it turned out the SCSI drive was dead.
Reseating the memory modules and starting with reduced memory might help as well.
The other thing might be the dead RTC battery ( https://forums.irixnet.org/thread-4297.html )
--- Post by 3DChris ---
I'll look into this. First I need to replace the dead fan in the power supply. Any suggestions for a high quality replacement that isn't going to sound like a turbine?
The RTC battery link you provided has 2 options. I'm assuming I should get the fully assembled option with the pins. Does the Dallas battery get installed in a socket, or is it soldered to the board?
chunk 4
............
Base I/O Ethernet set to /dev/ethernet/ef0
Installing Graphics Console...
graphics install: searching for pipe 0
Walking SCSI Adapter 0, (pci id 1)
Walking SCSI Adapter 1, (pci id 1)
Initializing PROM Device drivers .......... DONE
Cannot connect to keyboard -- check the cable.
Cannot open /dev/input/ioc3pckm0 for input
Cannot connect to keyboard -- check the cable.
Cannot open /dev/input/ioc3pckm0 for input
Checking hardware inventory ...............
WARNING: hardware inventory is invalid. Reinitializing...
Writing 3 records... DONE
Updated new configuration. Wrote 3 records.
**** System Configuration and Diagnostics Summary ****
CONFIG:
No. of NODEs enabled = 1
No. of NODEs disabled = 0
No. of CPUs enabled = 1
No. of CPUs disabled = 0
Mem enabled = 512 MB
Mem disabled = 0 MB
No. of RTRs enabled = 0
No. of RTRs disabled = 0
DIAG RESULTS:
ALL DIAGS PASSED.
**** End System Configuration and Diagnostics Summary ****
*** Module 001c01 CPU configuration values mismatch.
The CPU configuration values from board EEPROM/PSC did not match
on 1 module(s). Please reflash the PROM image on the above listed module(s).
Everything looked good.
chunk 4
ottleneck is?
--- Post by stormy ---
Could you please list the firmware version of the scsi2sd v6, there have been quite a few updates in the last few months. There may have been some improvements.
--- Post by nintendoeats ---
I ran the same test, and my results are ~2x better on average (some are around the same, some are almost 4x). I have done no experimentation to see how I might maximize performance, these are just some settings that work. Playing with these settings is something that I want to do soon.
While I did use an external terminator for this test, my system works fine without one when when using SCSI2SD. I did need to use a slightly older firmware to work with my system, which is mentioned somewhere on the SCSI2SD website. 6.3.0 might work, but I haven't installed it yet.
System: Indy R4400SC/150 - 128MB RAM - XL24 - SCS2SD v6
SD card: SanDisk 128GB Extreme Pro SDXC UHS-I/U3 V30 (SDSDXXY-128G-GN4IN)
Firmware: 6.2.5
Settings:
Code:
chunk 4
+5V from the SCA connector through to the SCSI TERMPWR pins on both the 68 and 50 pin SCSI connectors, therefore allowing you to power the attached ZuluSCSI or derivative/clone SCSI emulator to it.
The PCB was designed in such a way that it can either convert from SCA to 68-pin 16-bit wide SCSI, or SCA to 50 pin SCSI (or all three), depending on how it's assembled. The only necessary active component is a diode through which the +5V from the SCA connector through to the SCSI TERMPWR pins on both the 68 and 50 pin SCSI connectors, therefore allowing you to power the attached ZuluSCSI or derivative/clone SCSI emulator to it.
These are hand-assembled (for now) as well as hand-tested, and the price reflects that. The TE 1734099-8 SCA connectors aren't cheap either, and cost us nearly $9 each. I purchased 180 of them at a cost of $8.75 each, which is the equivalent of € 7.62 each, at this moment in time. The 50 pin IDC female connector ( SFH11-PBPC-D25-RA-BK is manufactured by Sullins, and is not low-grade Chinesium.
chunk 4
ternal terminator. I'm using SCSI2 mode with async transfer (MaxSyncSpeed = 0), either 5MBps or 10MBps synchronous mode results in a disk error doing any operations on the CDs or virtual hard drive.
I've had success using raw CD images by configuring the virtual optical drive with the IMG0 field pointing to the efs file. I can't figure out a software eject mechanism from the Installer prompt (no eject command is available from the shell either), so the feature of using multiple images in the optical drive isn't usable until the system is installed. To work around that, I configured each image with its own optical drive during the installation.
--- Post by Jinroh ---
Very cool to hear this usable on an Indy. How is performance with Zulu? it seems cheaper and more available than the SCSI2SD v6, but dunno if I should check this out or just a 15K SCSI drive.
--- Post by delucks ---
Jinroh said:
How is performance with Zulu?
Click to expand...
ricks you can make a pretty neat system. I warn you tho. Its addictive as hell. Once you have one you will want more. Also what color doors did you get on it? the yellow accents or just normal grey?
The Ultra 320 drives also work well. Really anything with an SCA connector on it will work. I use HP Ultra 320 300gb drives in my Onyx 350 and assorted other bricks for storage.
Do you know if he still has those altix 450s in the picture on the ebay listing? Same with the Numalink cables too? Every time I see that picture I get sad that they prob all got scrapped.
Click to expand...
When I visited his house (I drove all the way from Maryland), he didn't have anything aside from a bunch of NL4Rs and some odd looking SGI blades. He also had an Xserve Xeon, which I got for $40. No Altix 450s, aren't those large mini-fridge sized units? I tried googling the Altix 450, and they look huge. No cables either as far as I know; he told me a lot of cables got sold, in addition to most of the "normal" SGI stuff.
chunk 4
ce it only goes to the opamp for level translating and inverting the signals going from the adapter to the workstation, so I don't expect there to be any danger of damaging something with this hack.
I intend to incorporate this into a future revision of the board, but I can't promise when I'll get around to it.
If anyone else tries this, please let us know if it works for you.
Edit: full write-up with details: http://nuclear.mutantstargoat.com/hw/sgikbd/indigo_r3000_hack.html
--- Post by nuclear ---
I just released rev3 of the sgikbd board (sgikbd release v1.2), which includes the R3K indigo compatibility hack, selectable by jumper. Head over to the project website for details: http://nuclear.mutantstargoat.com/hw/sgikbd
chunk 4
pins that are exceptionally small and fragile. If you have experience working with SMD components then you will already be all too familiar with the delicate care needed to work on these chips.
As you can see in the GIF, the failure mode presented is fairly straightforward. The pins eventually fail and detach from the board. Thankfully this failure is clean and does not cause damage to the pad or leg that cannot be repaired.
Repair was done slowly and carefully, a few legs at a time. I ended up repairing three boards in total. Of the three, all issues with failed joints were located on either the left or right chips.
Once I had this issue sorted out and had confirmed that I had three boards with good connections and no other issues (continuity checking, etc.) I needed to figure out how best to replace the thermal interface material with something I new was going to work well. This isn't to say that SGI's material was inferior. I just simply had no way to know exactly what it was. I also felt that due to how thin it was (~0.01mm) there was a little bit of room to improve the spacing and pressure issues that caused the boards to warp and bend in the first place.
chunk 4
ors only occur on the first run. Afterwards, with the test file created, there are no further errors.
I have also tried to turn on the SCSI 2 support on the SCSI2SD V6 but this has changed little.
IRIS 13# diskperf -W -D -r 4k -m 4m testfile
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name : Unspecified
# Test date : Sat Jan 28 21:44:02 1995
# Test machine : IRIX IRIS 6.5 10070055 IP20
# Test type : XFS data subvolume
# Test path : testfile
# Request sizes : min=4096 max=4194304
# Parameters : direct=1 time=10 scale=1.000 delay=0.000
# XFS file size : 37748736 bytes
#---------------------------------------------------------
# req_size fwd_wt fwd_rd bwd_wt bwd_rd rnd_wt rnd_rd
# (bytes) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s)
#---------------------------------------------------------
4096 1.29 1.90 1.31 1.89 1.34 1.88
8192 2.00 2.51 2.13 2.53 2.00 2.46
16384 2.81 3.02 2.92 3.04 2.79 3.00
32768 3.23 3.20 3.24 3.20 3.23 3.18
65536 3.53 3.47 3.53 3.48 3.53 3.47
131072 3.59 3.61 3.58 3.64 3.71 3.62
262144 3.58 3.72 3.56 3.72 3.53 3.72
chunk 4
allow normal startup, it's great way of doing a cheap voltage injection-style hunting.
--- Post by stormy ---
Update, I am getting 7.7v AC and 5v AC from the double thick wires going from HV to LV.
--- Post by ghost180sx ---
mc68k said:
Any luck?
Click to expand...
This is an extremely old thread. If you have a PSU that you are having trouble with and want some insight, I suggest you start a new thread.
--- Post by stormy ---
@mc68k Might as well update this thread after so long: Yes it works now, I stupidly ended up re-capping the entire thing (which made no difference) I then gave it to my friend. He literally just re-flowed the solder around any hot components, like transistors or things connected to heatsinks, it then sprang to life.
So TLDR; if you have trouble with these PSU's, try reflowing any components that get hot. Cracked solder joints are a very likely issue.
--- Post by SolusRaion ---
That makes sense. I've been working on some old CRTs as a recently and cracked solder joints are a huge issue. The most notable way to see if that's the case with those is to use the Fonzie method on them
chunk 4
rely it crumbled like these love to do).
--- Post by ghost180sx ---
Wasn't there an STL file to reprint the drive's gear?
--- Post by WMSGI ---
It would be great if anyone can repost the link. thx
--- Post by tng1 ---
had the same issue with the O2 CD ROM drive gear and eventually found an ebay seller who had the dimensions close enough to replace it (5.6mm by 4mm by 1.98mm) i had been searching for ( 6mm by 4mm, 2mm), for some reason this size was difficult to find it was tight on the spindle as is 1.98mm i filed a tiny amount from the centre of the gear and it fit perfectly, hope it helps
https://www.ebay.co.uk/itm/166818139726?var=466479577586
--- Post by ReVolt ---
Thanks for posting this. I ordered some because I have two o2 drives needing it now and a third that will eventually.
My motor shaft measures 0.08" and I happened to have a 0.0785" reamer. Somehow this resulted in a slip fit that would spin on the shaft. It probably would be fine if complemented with epoxy or Loctite. I reamed it by hand so it probably wasn't straight and resulted in an oversized hole or my shaft measurement was wrong. I'll re-measure when I do the next one.
41)
0. 00 (default)
1. 01
2. 10
3. 11
0
20. PLLDis (bit43)
0. PLL enabled (default)
1. PLL disabled
0
21. DivMa2Core (bit44)
0. Divide by 1 (default)
1. Divide by 2
0
22. MulFundCore[4:0] (bits49:45)
0..15 => multiply by 2..17 (default 6)
6
23. DivXCore[4:0] (bits54:50)
31. Divide by 1 (recommended) (default 31)
31
[PROM] RM7900 custom bitstream saved.
========================================
O2 CPU PROM EMULATOR FW. REV. A00
CPU: RM7900
Bitstream Profile: custom
Bitstream settings: Endianness: BE, SysAD: 64-bit, Overlap: OFF, WriteProt: pipelined writes, DatRate: DDDD, ECACHE: ON, ECBurst: DCD, DRVOut: 100%, Ratio: 2:1, TmrInt: ON, Timer1X: normal, SysCfgID: 1, OCache: ON, OTagClr: ON, ParChk: ON, JTLB: 48-entry, MIPS64: OFF, CkPdAlgn: 0, PLL: ON, Div2: OFF, Mul: x8, DivX: 1
Bitstream: 256 bits
Mode: Polled (all sends)
Type 'setup' + Enter for setup menu
Type 'status' + Enter for status
Type 'info' + Enter for info
Type 'boot' + Enter for USB bootloader
Type 'reboot' + Enter to reboot MCU
========================================
Code:
chunk 5
ad.
@Tech&Music cache is indeed enabled on the 180MHz R5k module, I made a mistake when decoding, first post is updated.
--- Post by sdz ---
2. R5k 200MHz 1MB external cache
Raw bitstream:
0000000010101010100010000000000001000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Meaning:
Bit 0 - reserved
bit0 = 0
Bits 1:4 — XmitDatPat (block-write data pattern)
bits1..4 = 0000b = 0
Meaning: DDDD (no interleaving)
Bits 5:7 — SysCkRatio (PClock = SysClock × multiplier)
bits5..7 = 000b = 0
Meaning: Multiply by 2
Bit 8 — EndBit (endianness, OR’d with BigEndian pin)
bit8 = 1
Meaning: Big-endian (OR'd with the BigEndian pin)
Bits 9:10 — Non-Block Write mode
bits9..10 = 10b = 2
Meaning: Pipelined writes
Bit 11 — TmrIntEn (timer interrupt on Int*[5])
bit11 = 0
Meaning: Timer interrupt enabled
Bit 12 — Secondary cache enable
bit12 = 1
Meaning: Secondary cache enabled
Bits 13:14 — DrvOut (output driver strength / slew)
bits13..14 = 10b
Meaning: 100% drive strength
Bit 15 - reserved
chunk 5
iously the goal here is to produce a fully functional set of full sized plastics, but it will also be cool to release miniatures was well, besides I already have this little model up my sleeve!
It will be awesome to add a complete O2 to it!
--- Post by Irinikus ---
This is the type of 3D printer I'd like to get, but I'm about to buy an Onyx desk side, so this will have to wait!!!!!
It goes for +- $6,990, which seems pretty steep until you see the quality of its prints!!!!
In future I want to start manufacturing desktop loudspeakers, using my own wave-guide technology and I will only start this project once I have a proper 3D printer, and this looks to be the printer for the job!
The SINTERIT LISA:
Just take a look at the resolution that this thing can print in!!!
--- Post by Irinikus ---
The Indy case is a model that I scratch built, so there's no STL file freely available for it. Once I've managed to 3D print it to properly verify it, I will allow it to be hosted on an FTP, but definitely not in an STL format, as the STL format sucks, the O2.STL clearly shows this!
chunk 5
ve this and to make sure I got something official. The new Pi SD cards are highly regarded for running operating systems on, they also support native command queuing. This made a massive difference.
2. Use the official SD card formatter tool, and format with --overwrite enabled: https://www.sdcard.org/downloads/formatter/
- You may not believe this (I didn't at first) but doing a full overwrite format (it will take an hour or so!) doing a format using this tool will increase the performance of an SD card in a ZuluSCSI massively. Even the other day I recommended this to a person who was struggling with performance on their SGI Indy, they didn't quite believe me at first but after doing it they literally got twice the performance!
chunk 5
I don't think the flashing tool will let you flash a PROM image without that header. I can make more tests after I add a test socket (for the flash IC) to an O2 MB, so that I can easily recover it.
--- Post by ruckusman ---
I think you're correct about them being instruction for flash - a sanity check, version check and perhaps functional check of various pin states.
It's tnteresting, because I was looking specifically at the opening ~32 bytes of the ip32prom.rev4.18.bin and using Gxemul, if I step through from 0x00000000
First output Gxemul gives is a TLBL exception - this could be incorrect BTW, or my misinterpretation of what Gxemul is actually doing.
Code:
[ exception TLBL vaddr=0x0000000000000000 pc=0x0000000000000000 ]
ffffffff80000180: 3c1abfc8 lui k0,0xbfc8
GXemul>
ffffffff80000184: 375a8888 ori k0,k0,0x8888
GXemul>
ffffffff80000188: 03400008 jr k0 <[ARCBIOS entry]+0x888>
The arcbios entry (not implemented BTW) I thought was also interesting.
There's also two 16K boot blocks on the Atmel chip.
I think some interesting stuff happens there.
chunk 5
your card, use the --overwrite option.
Where to buy
Official price on Rabbit Hole Computing website as of Dec 2025: $129
ZuluSCSI - A hardware SCSI HDD & CD-ROM emulator
##### Where to Buy ZuluSCSI #### United States * [Rabbit Hole Computing (Northern California)](https://shop.rabbitholecomputing.com/collections/zuluscsi) - Direct from the source * [SamplerZone.com (Tennessee)](https://samplerzone.com/collections/zuluscsi) - Specializes in Musical Samplers *...
zuluscsi.com
My recommendation: I can highly recommend the ZuluSCSI Wide-SCA. It is the perfect upgrade from using vintage spinning disks. Not only does it provide the levels of speed we require on our platform, but it also provides the excellent usability that comes with a ZuluSCSI product ie; easy management of disk images, making system backups a breeze. This also includes the ability to mount CD-ROM images which is extremely useful.
chunk 5
1 source code remained by the time we released the very first ZuluSCSI V1, which significantly outperformed the original BlueSCSI V1. One can only assume that this was seen as an existential threat.
BlueSCSI V2 has every right to exist, and end users have every right to use it, however they should do so with full awareness of who performed and financed the actual effort. The original BlueSCSI fork went out of its way to seemingly-intentionally obfuscate the true origins of the code , and only after they were publicly called out about it did they claim to have made "a bad merge which lost history" and restore the stripped attribution.
I've been loosely involved with and a fan of open-source software for nearly thirty years, and have used GPLv3-licensed software almost daily since the early 2000s.
chunk 5
need to use once.
If you can take pictures and post them we might be able to see something in the pictures to help you out, you'll need really good lighting though to get good pictures.
Good Luck.
--- Post by trembl ---
Thank you for the very detailed and helpful comments. A closer olfactorial inspection made it clear, that the smell was coming from one of the capacitors on the motherboard! Off to order the replacement capacitors - and trying to get another PSU! I'll make sure to document my journey in getting the Indy to work!
--- Post by SolusRaion ---
Don't replace the PSU, if it's bad, repair it. These systems aren't disposable
--- Post by trembl ---
That's the plan! I saw some forum members offering refurbished PSUs, but could not find a list for replacement parts (yet). If anyone has a parts list for the Indy Sony PSU, it would be great. I am also happy to work on the PSU, document and share any info I can find.
--- Post by weblacky ---
trembl said:
chunk 5
Vpp 5V @ 2A load -0.5053 17.807W 3.316V, 156mVpp 5.13511V, 114mVpp 12.5067V, 158mVpp ~ -12V, 134mVpp 5V @ 10A load -0.6112 64.69W 3.271V, 274mVpp 4.88171V, 128mVpp 12.4618V, 196mVpp ~ -12V, 164mVpp
After some previous experiences loading down all rails with resistors, or trying to load down the 3.3 or 12V rails first, I settled on a testing methodology of just using a programmable DC load to load down the 5V rail in constant current mode. This seems to keep the supply happy, as loading down other rails without loading down 5V seems to stress it. Additionally it was too cumbersome to keep attaching power resistors on the other rails and I only have one programmable load. So, while this is not an optimum methodology and likely leads to higher ripple figures on the unloaded rails, it still seems to give a reasonable representation of power supply performance.
Sony: Test rig & Soft power-off state
Sony: No-load
Sony: +5V @ 2A state
--- Post by Elf ---
Sony: +5V @ 10A state
--- Post by Elf ---
Now, some specifications on the Nidec , followed by the same type of measurements.
Rail Rating +3.3V 7A +5V 25A +5V standby 0.001 A +12V 4.5A -12V 0.75A
chunk 5
lled at NASA Goddard Space Flight Center in Greenbelt, Maryland, USA. It now resides at the Large Scale Systems Museum in Pittsburgh, PA, where it is now an operational and available exhibit system.
It took nearly a week of work, but now it's back up and running in its full configuration. My approach was to break it down to the simplest configuration (one module, one node) and build it up from there, piece by piece, not moving forward until each problem was fully resolved. Broadly, the major issues were:
- a piece of schmutz that somehow made it onto one node's compression connector
- swapped upper/lower cables on the MMSC
- "not quite dead" Dallas chips "sometimes" retaining config information
- uncleared error logs
- poor seating of router boards in top chassis (probably due to movement)
- corrupt PROM on a node board
- dirty SIMM contacts on another node board
All of these factors together basically made the machine a big frustrating mess to troubleshoot, but I worked through it and was rewarded with:
>> hinv
System SGI-IP27
16 400 MHz IP27 Processors
Main memory size: 32768 Mbytes
...
chunk 5
1.0 Ghz MIPS R16000 Processor Chip (enabled)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 2 at Module 001c02/Slot 0/Slice C: 1.0 Ghz MIPS R16000 Processor Chip (enabled)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 3 at Module 001c02/Slot 0/Slice D: 1.0 Ghz MIPS R16000 Processor Chip (enabled)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
Main memory size: 4096 Mbytes
Instruction cache size: 32 Kbytes
Data cache size: 32 Kbytes
Secondary unified instruction/data cache size: 16 Mbytes
Memory at Module 001c02/Slot 0: 4096 MB (enabled)
Bank 0 contains 512 MB (Premium) DIMMS (enabled)
Bank 1 contains 512 MB (Premium) DIMMS (enabled)
Bank 2 contains 512 MB (Premium) DIMMS (enabled)
Bank 3 contains 512 MB (Premium) DIMMS (enabled)
Bank 4 contains 512 MB (Premium) DIMMS (enabled)
Bank 5 contains 512 MB (Premium) DIMMS (enabled)
Bank 6 contains 512 MB (Premium) DIMMS (enabled)
Bank 7 contains 512 MB (Premium) DIMMS (enabled)
Integral SCSI controller 2: Version IDE (ATA/ATAPI) IOC4
CDROM: unit 0 on SCSI controller 2
Integral SCSI controller 0: Version QL12160, low voltage differential
chunk 5
he RTC battery link you provided has 2 options. I'm assuming I should get the fully assembled option with the pins. Does the Dallas battery get installed in a socket, or is it soldered to the board?
--- Post by mapesdhs ---
3DChris said:
I'll look into this. First I need to replace the dead fan in the power supply. Any suggestions for a high quality replacement that isn't going to sound like a turbine?
Click to expand...
If you get stuck on the fan, happy to send you a free replacement of the same existing type, I have several doing nothing. Just cover the shipping.
Ian.
--- Post by 3DChris ---
Thanks for the offer! I managed to find an Enermax fan (uctbp12p-c) from a water block. Seems to move a lot of air at full speed ~ 2300 RPM. I've got a number of these kicking around, so if one fails, I've got backups.
Just waiting for the replacement RTC chip. Ordered the fully assembled variant. Not sure when it's shipping though.
chunk 5
iguration values mismatch.
The CPU configuration values from board EEPROM/PSC did not match
on 1 module(s). Please reflash the PROM image on the above listed module(s).
Everything looked good.
I tried with keyboard and mouse but got no graphics from the DVI port (analog or digital).
I enabled debug mode in L1 with "debug 0x10d" and got to "POD SysCt Cac" prompt.
Code:
A 000 001c01: POD SysCt Cac> clearalllogs
A 000 001c01: *** This must be run only after NUMAlink discovery is complete.
A 000 001c01: *** This will clear all previous log variables such as:
A 000 001c01: *** moduleids, nodeids, etc. for all nodes.
A 000 001c01: Clear all logs? [n] y
A 000 001c01: Checking 1 entries for promlogs
A 000 001c01: .DONE
A 000 001c01: All PROM logs cleared!
A 000 001c01: POD SysCt Cac> initalllogs
A 000 001c01: *** This must be run only after NUMAlink discovery is complete.
A 000 001c01: *** This will clear all previous log variables such as:
A 000 001c01: *** moduleids, nodeids, etc. for all nodes.
A 000 001c01: Clear all logs environment variables, and aliases ? [n] y
A 000 001c01: Checking 1 entries for promlogs
A 000 001c01: .DONE
an the SCSI2SD v6, but dunno if I should check this out or just a 15K SCSI drive.
--- Post by delucks ---
Jinroh said:
How is performance with Zulu?
Click to expand...
I did a quick test on the adapter with dd copying one sector at a time, which got about 2.8MB/s. If you have suggestions for other disk benchmarking methods I'll try them too. I'm curious to see comparable results for a spinning drive; neither of the ones that came with my Challenge are working.
Code:
[sgugshell delucks@challenge benchmarks]$ dd if=/dev/zero of=test0 bs=4k count=100000 && sync; rm test0
100000+0 records in
100000+0 records out
409600000 bytes (410 MB, 391 MiB) copied, 143.89 s, 2.8 MB/s
[sgugshell delucks@challenge benchmarks]$ dd if=/dev/zero of=test0 bs=4k count=100000 && sync; rm test0
100000+0 records in
100000+0 records out
409600000 bytes (410 MB, 391 MiB) copied, 145.094 s, 2.8 MB/s
[sgugshell delucks@challenge benchmarks]$ dd if=/dev/zero of=test0 bs=4k count=200000 && sync; rm test0
200000+0 records in
200000+0 records out
819200000 bytes (819 MB, 781 MiB) copied, 300.421 s, 2.7 MB/s
--- Post by Elf ---
delucks said:
ge mini-fridge sized units? I tried googling the Altix 450, and they look huge. No cables either as far as I know; he told me a lot of cables got sold, in addition to most of the "normal" SGI stuff.
I'd love to have some sort of visualization unit at some point, like an Onyx4. Any idea what PCI cards are supported by the Origin 300? Would be cool to have a graphics module, or an additional ethernet module. I probably won't ever be able to use the Numalink feature, as I don't see myself coming across another SGI unit anytime soon. I intend on getting the Origin 300 hosting *something,* and interfacing that within my website.
I might just get an Ultra160, the manual mentioned it. I'm afraid of incompatibility. I gotta check what I have at home though, I feel like I have some spare IBM SCA-type drives.
As for the NL4R, it has yellow accents underneath the grey.
Any idea how well an air-gapped network between the Origin and a Sun Blade 2000 will function? I wanted to make a tiny network with the Origin, my Sun Blade 2000, and Sun SPARCserver 5.
Edit:
I think it's 80-pin?
chunk 5
t it was. I also felt that due to how thin it was (~0.01mm) there was a little bit of room to improve the spacing and pressure issues that caused the boards to warp and bend in the first place.
Enter Fujipoly's 17 W/mK thermal pad! This was the absolute best material I could find in 0.5mm thickness. I know there are other items out there such as graphite pads, or even thermal paste, but these pads solved what I assessed to be part of the issue with the design.
These sheets are 50x60mm, providing four 25mm square pads once cut up. I ended up using two packets for three TRAMs in total.
The TRAMs are a hair over 27mm in size so 25mm pads were a perfect fit for the intended purpose.
Installed and ready for the heatsink to be reapplied!
After installing the heatsink I went ahead and installed the support clips I designed for the heatsink.
chunk 5
0 2.46
16384 2.81 3.02 2.92 3.04 2.79 3.00
32768 3.23 3.20 3.24 3.20 3.23 3.18
65536 3.53 3.47 3.53 3.48 3.53 3.47
131072 3.59 3.61 3.58 3.64 3.71 3.62
262144 3.58 3.72 3.56 3.72 3.53 3.72
524288 3.71 3.63 3.68 3.63 3.66 3.63
1048576 3.70 3.64 3.69 3.64 3.70 3.63
2097152 3.68 3.65 3.70 3.65 3.67 3.65
4194304 3.77 3.80 3.79 3.82 3.81 3.76
IRIS 14#
The SD card I'm using should have no issue with delivering way more than 10MB/s. Is the zuluSCSI (significantly) faster than the SCSI2SD V6?
--- Post by flexion ---
I actually had the same errors on the first run. Never noticed this before :-/
My results on Indigo2 R10k with ZuluSCSI
flexion@indigo2-purple ~ % diskperf -W -D -c 128M -t 5 /tmp/testfile
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name : ZuluSCSI
# Test date : Fri Jan 31 04:53:22 2025
# Test machine : IRIX64 indigo2-purple 6.5 10070055 IP28
# Test type : XFS data subvolume
# Test path : /tmp/testfile
# Request sizes : min=16384 max=4194304
# Parameters : direct=1 time=5 scale=1.000 delay=0.000
# XFS file size : 134217728 bytes
chunk 5
s a recently and cracked solder joints are a huge issue. The most notable way to see if that's the case with those is to use the Fonzie method on them
chunk 5
if complemented with epoxy or Loctite. I reamed it by hand so it probably wasn't straight and resulted in an oversized hole or my shaft measurement was wrong. I'll re-measure when I do the next one.
Anyhow, I prefer a mechanical press-fit so I reamed one maybe 90-95% through and was barely able to press fit the remaining small section with my finger. Before pressing it on I put a tiny dab of super glue to assist the slip fit section.
It seems solid and operates smooth. This is something I've been dwelling over how to fix. My 3d printers aren't good enough quality to produce such small features accurately. I though about trying resin casting but I've never done it before. These brass gears are a permanent, simple, and inexpensive solution!
I even found the screws from when I disassembled it almost a year ago!
chunk 6
ntry
0
12. On-chip secondary cache control
0. Disable
1. Enable (default)
1
13. Two outstanding reads with out-of-order return
0. Disable (default)
1. Enable
0
[PROM] RM7000C custom bitstream saved.
========================================
O2 CPU PROM EMULATOR FW. REV. A00
CPU: RM7000C
Bitstream Profile: custom
Bitstream settings: WriteBackRate: DDDD, Multiplier: x8, Endianness: BE, pipelined non-block writes, TmrIntEn: ON, Tertiary cache: ON, DRVOut: 100%, TCACHE RAM: Dual-cycle deselect, UserCfgID: 01, Mult mode: integer, JTLB: 48 dual-entry, On-chip secondary cache: ON, OOO reads: OFF
Bitstream: 256 bits
Mode: Polled (all sends)
Type 'setup' + Enter for setup menu
Type 'status' + Enter for status
Type 'info' + Enter for info
Type 'boot' + Enter for USB bootloader
Type 'reboot' + Enter to reboot MCU
========================================
And here it is, 800MHz CPU in the SGI O2:
I have stress tested it for a couple of hours, no issues.
chunk 6
tatus' + Enter for status
Type 'info' + Enter for info
Type 'boot' + Enter for USB bootloader
Type 'reboot' + Enter to reboot MCU
========================================
Code:
========================================
O2 CPU PROM EMULATOR FW. REV. A00
CPU: RM7900
Bitstream Profile: custom
Bitstream settings: Endianness: BE, SysAD: 64-bit, Overlap: OFF, WriteProt: pipelined writes, DatRate: DDDD, ECACHE: ON, ECBurst: DCD, DRVOut: 100%, Ratio: 2:1, TmrInt: ON, Timer1X: normal, SysCfgID: 1, OCache: ON, OTagClr: ON, ParChk: ON, JTLB: 48-entry, MIPS64: OFF, CkPdAlgn: 0, PLL: ON, Div2: OFF, Mul: x8, DivX: 1
Bitstream: 256 bits
Mode: Polled (all sends)
Type 'setup' + Enter for setup menu
Type 'status' + Enter for status
Type 'info' + Enter for info
Type 'boot' + Enter for USB bootloader
Type 'reboot' + Enter to reboot MCU
========================================
setup
1. R5000
2. RM5271
3. RM7000
4. RM7000A
5. RM7000B
6. RM7000C
7. RM7900 (RM7965 Mode bits)
8. SR71010A
2
1. default RM5271 300MHz secondary cache off
2. default RM5271 300MHz secondary cache on
3. default RM5271 350MHz secondary cache off
4. default RM5271 350MHz secondary cache on
chunk 6
Bit 12 — Secondary cache enable
bit12 = 1
Meaning: Secondary cache enabled
Bits 13:14 — DrvOut (output driver strength / slew)
bits13..14 = 10b
Meaning: 100% drive strength
Bit 15 - reserved
bit15 = 0
Bits 16:17 — Secondary cache size
bits16..17 = 01b
Meaning: 1024 KB secondary cache size
Bits 18–255 reserved (and set to 0), except 20 33 37 (which are set to 1), as intended according to R5k errata.
-SysAD runs at 100MHz
-External cache runs at 100MHz
--- Post by sdz ---
3. R10k 150MHz 1MB
While the R5k/R7k CPUs load the configuration directly from the PROM (CPU clocks the PROM and reads the data), on R10k/R12k CPU configuration is done through the SysAD bus.
When the system starts, the SysAD bus is strapped accordingly, after which the CPU reads the config from the bus.
The CRIME 1.5 spec document mentions that CRIME reads the PROM present on the CPU module, and straps the SysAD bus:
Will come back to this (CRIME strapping the SysAD bus).
Looking at the CPU module, sure enough, there is a PROM IC (second photo, bottom side, the SOIC-8 IC with a sticker on it).
chunk 6
e for it. Once I've managed to 3D print it to properly verify it, I will allow it to be hosted on an FTP, but definitely not in an STL format, as the STL format sucks, the O2.STL clearly shows this!
--- Post by flexion ---
I tried to see how a miniature 3d print would look like, but the unmodified original STL has way too many 'open vertices' errors to print it properly. It's full of holes on the outside. So the skin has to be reworked anyways, even for a miniature version like an rpi enclosure or SD card holder. Thanks Irinikus for working on this! really cool!
--- Post by Irinikus ---
It would be best to print the model piece by piece, once all of the pieces are reconstructed. I’ll put some time in on this, this weekend.
--- Post by Irinikus ---
More work done tonight:
--- Post by Irinikus ---
I now know where this .stl originally came from!!! (The Chrome skins Demo!!!)
I was hoping that the Inventor .iv file would be of a high fidelity, but alas!!!
--- Post by Irinikus ---
@def13 from IRIX Network suggested to me that I try Quad Remesher on this model instead of doing things manually, and here are the results!
chunk 6
RCBIOS entry]+0x888>
The arcbios entry (not implemented BTW) I thought was also interesting.
There's also two 16K boot blocks on the Atmel chip.
I think some interesting stuff happens there.
BTW I'm in the process of designing a test socket to read and flash the PROM IC in situ also - RM7900 upgrade related; Idea I had several years ago - the NVME, and your work has inspired me to get it done
--- Post by sdz ---
RM7900 upgrade sure would be nice . There is that 4.13 leaked PROM that might help.
The (other) PROM on the CPU module side should be pretty easy to figure out.
--- Post by ruckusman ---
Patch SG0003530: O2 PROM rollup 4.11 1259999908 IRIX 6.3 Patches for RM5200 Support March 1999
That one interests me the most as it added another CPU to the PROM
There's a full suite of patches on the discord that Jan-jaap and jrra kindly provided - it's in there
https://discord.com/channels/524976640468713497/531292086125854720/1315661955117355118
https://discord.com/channels/524976640468713497/531292086125854720/1315738205584228393
chunk 6
lent usability that comes with a ZuluSCSI product ie; easy management of disk images, making system backups a breeze. This also includes the ability to mount CD-ROM images which is extremely useful.
--- Post by stormy ---
As an addition, a fellow forum member posted his Zulu image with a fully set-up and configured o2 IRIX 6.5.30 image. Archive.org removed it unfortunately, but he re-uploaded here to Google drive . I cannot vouch for anything of course, this is not my project, but it might help others who struggle with IRIX installation. This is a great example of the flexibility that is provided by ZuluSCSI.
--- Post by weblacky ---
Did you use a ini config file? If so could you please post the options/settings you used for the O2?
--- Post by stormy ---
weblacky said:
Did you use a ini config file? If so could you please post the options/settings you used for the O2?
Click to expand...
An .ini isn't required (I was told on good authority by the creator) the firmware in the Wide-SCA automatically sets itself up at the maximum rates. I did all my testing without an .ini.
--- Post by aperezbios ---
stormy said:
chunk 6
estore the stripped attribution.
I've been loosely involved with and a fan of open-source software for nearly thirty years, and have used GPLv3-licensed software almost daily since the early 2000s.
Finally, I should also mention that prior to publicly releasing the ZuluSCSI firmware, I privately e-mailed and offered to submit a pull request to the BlueSCSI maintainer so they could incorporate our significant improvements to their code base, and this offer was rejected outright, in a relatively hostile and immature manner. All of this could have been avoided had a more-objective approach been taken.
Thank you for your attention to this matter.
chunk 6
If anyone has a parts list for the Indy Sony PSU, it would be great. I am also happy to work on the PSU, document and share any info I can find.
--- Post by weblacky ---
trembl said:
That's the plan! I saw some forum members offering refurbished PSUs, but could not find a list for replacement parts (yet). If anyone has a parts list for the Indy Sony PSU, it would be great. I am also happy to work on the PSU, document and share any info I can find.
Click to expand...
There might be a listing somewhere, but I purposely do not work on the Sony's as information in this forum has proven that they are prone to allowing the Indy to overheat in several scenarios. Until someone who has electrical engineering talents can alter the fan PWM curve (via circuitry), it's likely going to remain that way. I've never been in a Sony, I exclusively do Nidec for Indys.
chunk 6
Sony: +5V @ 10A state
--- Post by Elf ---
Now, some specifications on the Nidec , followed by the same type of measurements.
Rail Rating +3.3V 7A +5V 25A +5V standby 0.001 A +12V 4.5A -12V 0.75A
As you can see, the power supply rails are all rated the same between the Sony and the Nidec, except for +5Vsb standby power. This (along with the low rating) implies to me that nothing substantial is powered on the motherboard during standby. Most likely some extremely minimal logic in combination with the front panel power button, but certainly not any part of the processor or likely not even a microcontroller.
Load / State Power factor Watts (True power) 3V3 rail
volts/ripple 5V rail
volts/ripple 12V rail
volts/ripple -12V rail
volts/ripple Soft power-off -0.4236 3.559W 0/0 0/0 0/0 0/0 No-load -0.6633 17.309W 2.806V, 202mVpp 5.05336V, 144mVpp 8.3252V, 308mVpp ~ -12V, 224mVpp 5V @ 2A load -0.6943 34.324W 3.350V, 200mVpp 5.03092V, 162mVpp 11.9587V, 154mVpp ~ -12V, 194mVpp 5V @ 10A load -0.7202 86.26W 3.309V, 266mVpp 4.93535V, 340mVpp 11.9165V, 374mVpp ~ -12V, 452mVpp
Nidec: Test rig & Soft power-off state
Nidec: No-load
Nidec: +5V @ 2A state
chunk 6
lly made the machine a big frustrating mess to troubleshoot, but I worked through it and was rewarded with:
>> hinv
System SGI-IP27
16 400 MHz IP27 Processors
Main memory size: 32768 Mbytes
...
I then used the amazing Love installer to get 6.5.30 onto the machine. Today I'll be installing random software on it and cleaning up the cabling.
-Dave McGuire, LSSM
--- Post by 3ddoc ---
been along time, but here goes:
go into pod mode
clearallogs
initalllogs
clear
reset
if that doesn't work, reset memory and try again
if that doesn't work its likely scrap
good luck
--- Post by mcguire ---
3ddoc said:
been along time, but here goes:
go into pod mode
clearallogs
initalllogs
clear
reset
if that doesn't work, reset memory and try again
if that doesn't work its likely scrap
good luck
Click to expand...
Yeah so, I got it all working, as I did mention in a subsequent post.
Nothing is ever scrap at LSSM. We fix everything.
-Dave
chunk 6
512 MB (Premium) DIMMS (enabled)
Integral SCSI controller 2: Version IDE (ATA/ATAPI) IOC4
CDROM: unit 0 on SCSI controller 2
Integral SCSI controller 0: Version QL12160, low voltage differential
Disk drive: unit 1 on SCSI controller 0 (unit 1)
Integral SCSI controller 1: Version QL12160, low voltage differential
IOC3/IOC4 serial port: tty3
IOC3/IOC4 serial port: tty4
IOC3/IOC4 serial port: tty5
IOC3/IOC4 serial port: tty6
Integral Gigabit Ethernet: tg0, module 001c02, PCI bus 1 slot 4
PCI Adapter ID (vendor 0x10a9, device 0x100a) PCI slot 1
PCI Adapter ID (vendor 0x1077, device 0x1216) PCI slot 3
PCI Adapter ID (vendor 0x14e4, device 0x1645) PCI slot 4
IOC4 firmware revision 83
IOC3/IOC4 external interrupts: 1
HUB in Module 001c02/Slot 0: Revision 2 Speed 200.00 Mhz (enabled)
IP35prom in Module 001c02/Slot n0: Revision 6.210
--- Post by CiaoTime ---
I spat up a little bit of coffee this morning when I read that hinv output, hahah.
nondem said:
IP59_4CPU Board: barcode NSG072 part 030-1989-003 rev -B
Click to expand...
chunk 6
PM. I've got a number of these kicking around, so if one fails, I've got backups.
Just waiting for the replacement RTC chip. Ordered the fully assembled variant. Not sure when it's shipping though.
--- Post by 3DChris ---
Update on the situation... I'm not having any luck really. I replaced the Dallas battery and it didn't help. I tried swapping out the system board with a dual 400 board I have. Same problem. I tried removing the graphics section of the system and only having the serial connection to my PC connected with no mouse/keyboard. I'm not seeing anything working on my console window, but the system isn't giving a red light anymore. I tried removing some memory down to just the first two sticks... The Console then gives me errors about expecting memory, but seeing a different result. So at least I know the console connection is "working". But I can't get further into the system. Doesn't really "boot up" I suppose? I've tried removing the HDD as well. Same result.
chunk 6
as:
A 000 001c01: *** moduleids, nodeids, etc. for all nodes.
A 000 001c01: Clear all logs environment variables, and aliases ? [n] y
A 000 001c01: Checking 1 entries for promlogs
A 000 001c01: .DONE
A 000 001c01: All PROM logs cleared!
A 000 001c01: POD SysCt Cac> flush
I set "debug 0" in L1 and reseted the system.
Still no graphics and I got the CPU configuration mismatch errors as before.
System info in Command Monitor:
Code:
>> hinv -v
IP35 Node Board, Module 001c01
ASIC BEDROCK Rev 2, 200 MHz, (nasid 0)
Processor A: 600 MHz R16000 Rev 2.1
Secondary Cache 4MB 300MHz Tap 0xa , (cpu 0)
R16010FPC Rev 2.1
Memory on board, 512 MBytes (Standard)
Bank 0, 256 MBytes (Standard) <-- (Software Bank 0)
Bank 1, 256 MBytes (Standard)
IBRICK Bridge, Module 001c01
ASIC BRIDGE Rev 2, (widget 14)
IBRICK Bridge, Module 001c01
ASIC BRIDGE Rev 2, (widget 15)
adapter PCI (SCSI interface) Rev 6
(pci id 1)
adapter IOC3 Rev 1
(pci id 4)
controller multi function SuperIO
controller Ethernet Rev 1
adapter USB (OHCI interface)
(pci id 5)
ASIC XBOW Rev 2, on CBrick, Module 001c01
ODYSSEY Graphics Board, Module 001c01
chunk 6
56 0.34 0.70
16384 2.74 6.11 2.85 4.59 0.63 1.38
32768 2.76 6.06 2.83 4.73 1.31 2.56
65536 5.92 5.25 5.43 4.27 4.36 4.91
131072 5.00 5.86 5.44 4.87 4.13 5.79
262144 5.57 6.67 5.58 5.51 4.85 5.91
524288 5.49 6.98 5.48 5.49 5.34 5.89
1048576 5.73 7.16 5.66 6.22 4.52 4.07
2097152 5.54 6.65 5.59 6.42 4.69 7.42
4194304 5.58 6.76 5.72 6.59 5.39 6.19
--- Post by nintendoeats ---
I have been trying to get results with SCSI 2 enabled. I'm finding there is a lot of run-to-run variance. I'm guessing this is because the SD card is basically a mini-computer with a mind of its own. Enabling SCSI2 was generally faster (over 1MB/s sometimes), but no specific operation was consistent across a few runs.
--- Post by Elf ---
Interesting results; I wonder how much the performance varies by SD card. Random write being so slow until the block size gets bigger sort of suggests big block sizes internal to the card. I wonder why random reads are so slow on smaller block sizes though...
--- Post by callahan ---
TL;DR: After further tests, I've found that SCSI2SD v6's max performance is slower than a high-end 10,000RPM SCSI drive, but it still often outperforms such drives in normal usage.
chunk 6
of=test0 bs=4k count=200000 && sync; rm test0
200000+0 records in
200000+0 records out
819200000 bytes (819 MB, 781 MiB) copied, 300.421 s, 2.7 MB/s
--- Post by Elf ---
delucks said:
If you have suggestions for other disk benchmarking methods I'll try them too
Click to expand...
Take a peek at this thread, it might give some ideas and allow side by side comparison to SCSI2SD
SCSI2SD v6 performance report
The host: a R5K/180 Indy. Note: the Indy and scsi2sd required a terminator on the external scsi port. I don't normally leave one there, but the system would hang and crash without it. The adapter: SCSI2SD v6. SCSI2 turned on. Parity turned on. Set to 10MB/sync. 2GB allocated in the...
forums.sgi.sh
--- Post by liquidkoshman ---
Hey,
I'm doing exactly the same thing now half a year later - trying to install IRIX on an Indy via ZuluSCSI.
For me reading of IMGs (install CDs etc.) seems ok but on write attempts I get errors - typically these revolve around drive geometry - sectors x heads vs size don't seem to align.
l an air-gapped network between the Origin and a Sun Blade 2000 will function? I wanted to make a tiny network with the Origin, my Sun Blade 2000, and Sun SPARCserver 5.
Edit:
I think it's 80-pin?
--- Post by joshyfishy22 ---
Finding cards that will work with these systems is pretty difficult due to the specific cards that the drivers want. There should be a list around of compatable pci cards. For graphics you would either need a Origin 350 and put a v12 in it. Or you would need a G-brick, V-brick, or Onyx4 GN brick. All are hard to come by and EXPENSIVE.
Iv never had drive incompatability with any drive iv thrown at it. You should be fine with any SCA drive
That NL4R looks pretty nice! I always loved the yellow of the altix line.
--- Post by flexion ---
when you install a compatible LSI Logic PCI-x SAS/SATA controller, you can even attach SSD drives.
--- Post by RubyManning ---
Try a 36GB or 73GB SCSI drive; IRIX installs smoothly.
--- Post by jander31 ---
I appreciate all of the responses! I ended up picking a 10K RPM 73GB IBM-rebranded Seagate 80-pin SCSI drive.
A couple additional questions for now:
chunk 6
it for the intended purpose.
Installed and ready for the heatsink to be reapplied!
After installing the heatsink I went ahead and installed the support clips I designed for the heatsink.
In order to provide better structural support and more evenly spread the pressure of the Kapton tape securing the heatsink, I devised a very simple 3D printed piece that clips onto the edge of the PCB and provides a stop for the heatsink, limiting maximum downward travel all the way around the board. The piece is sized .1mm smaller than the height of the gap with the new thermal pads and heatsink installed, thereby leaving a small amount of room for compression and travel, but keeping the board almost entirely flat along the bottom. Seriously, I cannot emphasize how much of a bend there is in the stock board. I left the boards separate from their heatsinks, upside down, for a week in order to release some of the bend they had. This helped, but installing this new setup made them completely flat.
You can see in the above image how the clips provide additional support near the corners where joint failure appeared to be most common.
chunk 6
st type : XFS data subvolume
# Test path : /tmp/testfile
# Request sizes : min=16384 max=4194304
# Parameters : direct=1 time=5 scale=1.000 delay=0.000
# XFS file size : 134217728 bytes
#---------------------------------------------------------
# req_size fwd_wt fwd_rd bwd_wt bwd_rd rnd_wt rnd_rd
# (bytes) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s)
#---------------------------------------------------------
16384 2.00 4.97 2.51 5.25 2.22 4.42
32768 1.17 6.82 3.49 6.93 3.59 6.60
65536 3.78 7.65 4.56 7.74 3.96 7.29
131072 4.97 7.82 5.04 8.20 5.09 7.92
262144 5.96 8.27 5.89 8.42 5.94 8.35
524288 6.39 8.04 6.16 8.58 3.01 8.54
1048576 4.13 8.06 6.70 8.52 6.68 8.62
2097152 6.83 8.24 6.79 7.87 6.77 8.23
4194304 7.07 8.35 7.04 8.37 5.61 8.47
--- Post by flexion ---
and results with another Indigo2 R10 but SCSI2SD
flexion@indigo2-purple2 ~ % diskperf -W -D -c 128M -t 5 /tmp/testfile
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name : SCSI2SD
# Test date : Fri Jan 31 05:08:13 2025
# Test machine : IRIX64 indigo2-purple 6.5 10070055 IP28
chunk 6
about trying resin casting but I've never done it before. These brass gears are a permanent, simple, and inexpensive solution!
I even found the screws from when I disassembled it almost a year ago!
--- Post by stormy ---
Another option: You can put either a BlueSCSI / AzulSCSI in the cd-rom bay. It's a great option for these reasons: Not many people even have SGI software on CD to use in their o2's, and when they find something they want it's usually a download from Archive.org. With the above mentioned solutions, you literally just copy the ISO to the SD card and bob's your uncle. So it's far more convenient than keeping the optical drive in my opinion.
SysAD bus:
Will come back to this (CRIME strapping the SysAD bus).
Looking at the CPU module, sure enough, there is a PROM IC (second photo, bottom side, the SOIC-8 IC with a sticker on it).
The R10k SysAD mode bits can be found here: https://techpubs.jurassic.nl/library/manuals/2000/007-2490-001/sgi_html/t5.Ver.2.0.book_166.html
Only SysAD[31:0] bits are actually used, while [63:32] are reserved.
I dumped the PROM using a logic analyzer, and it read a whooping 221111 bits from it. Quite different from the expected 32 bits of CPU config.
The PROM IC itself is 262144 bits.
Now, looking at what was read from the PROM IC, it all looked like valid data. Quite different to what I expected, something like 32 actual config bits followed maybe but a bunch of zeroes or ones (the R5k modules also read a lot of bits, as they never stop the PROM clock, but all those bits are zero).
Looking at the board, there are no other memory ICs present. There are also no resistors straps placed directly on the SysAD bus (like the newer carriers for R12k CPUs, those don't have a PROM at all, they to have a lot of resistors straps).
chunk 7
of a high fidelity, but alas!!!
--- Post by Irinikus ---
@def13 from IRIX Network suggested to me that I try Quad Remesher on this model instead of doing things manually, and here are the results!
--- Post by Irinikus ---
@Shiunbird, to answer the question that you asked me in the Youtube comments, as to whether you could use Quad Remesher only on a selection of vertices to save time.
I selected the following vertices on the front face of the model and applied Quad Remesher:
--- Post by Irinikus ---
This evening I worked on the right hand side of the model as well as the lower right hand edge.
Here's how it originally looked:
--- Post by Irinikus ---
Today I finished up the bottom edge: (It took most of the day to complete!)
--- Post by Irinikus ---
Some more work on this, with the aid of Red Bull!
--- Post by Irinikus ---
A little bit more work on this today: (I'm working on it progressively as I get the chance.)
--- Post by Irinikus ---
I put a few good hours into this model today!
Nothing like 3D modelling with a good cup of coffee!
--- Post by Irinikus ---
I managed to get some more work done on this model today: (Still a very long way to go!!!)
chunk 7
ed - it's in there
https://discord.com/channels/524976640468713497/531292086125854720/1315661955117355118
https://discord.com/channels/524976640468713497/531292086125854720/1315738205584228393
It took me some time to read correctly the 32 bit boot time mode setup string from Chicago Joe 600Mhz mod - it's read out little endian - because the CPU isn't yet set to big endian - that caught me out - byte flipping made the values sensible and legal.
Now I've got the RM7965 data sheet, with luck the Xylinx PROM part is doable, as I perhaps know what I am doing as far as the RM7900 boot time mode setup string goes.
I need to cross compare between the RM7000C boot time mode setup and RM7900 values, I don't think the 600Mhz one would work for the RM7900.
--- Post by sdz ---
Thanks for linking those patches!
Good observation about the endianess! Would have likely been bitten by that too.
I will be making a PROM emulator of sorts, that replaces the Xilinx part, and is reprogrammable (one can change values live with an USB cable connected).
--- Post by ruckusman ---
sdz said:
Thanks for linking those patches!
chunk 7
uthority by the creator) the firmware in the Wide-SCA automatically sets itself up at the maximum rates. I did all my testing without an .ini.
--- Post by aperezbios ---
stormy said:
An .ini isn't required (I was told on good authority by the creator) the firmware in the Wide-SCA automatically sets itself up at the maximum rates. I did all my testing without an .ini.
Click to expand...
Correct, in nearly all cases you absolutely do not need to customize anything. All of the commented-out values in zuluscsi.ini are the defaults. In circumstances where you need to spoof specific device and vendor strings, you can do that on an either global or SCSI ID-specific basis, using the ini file.
--- Post by flexion ---
Got mine today. Fortunately I had ordered two zulu boards, because the SCSI controller didn't recognize any drives on the first board I tried.
When I had put the same SD card into the second zulu board, everything worked fine.
here are my results: (left: zulu | right: spinning rust)
--- Post by stormy ---
Nice results there @flexion what SD card did you use?
chunk 7
offer was rejected outright, in a relatively hostile and immature manner. All of this could have been avoided had a more-objective approach been taken.
Thank you for your attention to this matter.
--- Post by ka1axy ---
Recently bought and installed a ZuluSCSI. It did require a little digging to figure out how to configure the SD card, and there's some misinformation out there about not being able to read the card after formatting it. I set up two CDROM files and three HDD files. All devices were recognised by the Iris Indigo at their assigned SCSI device IDs, and formatted like real HDDs. Once I got Irix 6.5.22 installed (Reanimator and RasPi) on the virtual drives, the system seems to work just fine. I was able to write, compile and run (thanks to whoever posted the license.dat file for the compiler!) a "hello world!" program.
I just pulled the SD card and made a "dd" image of it on my Linux system, so I can create another card if this one dies. ZuluSCSI SD cards formatted with FAT are fully readable by Linux (though the actual disk image files ON the card are probably not...didn't try) and the dd copy completed without errors.
chunk 7
. Until someone who has electrical engineering talents can alter the fan PWM curve (via circuitry), it's likely going to remain that way. I've never been in a Sony, I exclusively do Nidec for Indys.
However I can easily warn you that assuming the Sony is built like the Nidec, it might use previous generation PCB technology which is essentially gigantic solder tracks coated in a very delicate resist. The tracks are incredibly prone to lifting unless you use professional equipment. This is especially true of the filter capacitors in the Nidec. Those capacitors use vias that have been artificially inserted through the single layer board, those vias very easily come out with the capacitor terminals unless you not only use low melt solder but you dwell enough time to rock them out slowly.
The Sony's do have some positives but until somebody figures out how to even just shift the fan curve properly, it's not worth my time.
chunk 7
load -0.7202 86.26W 3.309V, 266mVpp 4.93535V, 340mVpp 11.9165V, 374mVpp ~ -12V, 452mVpp
Nidec: Test rig & Soft power-off state
Nidec: No-load
Nidec: +5V @ 2A state
--- Post by Elf ---
Nidec: +5V @ 10A state
Now we go back to the Sony for some rail sequencing information:
Sony: No-load Rail Sequencing
Sony: 5V @ 2A loaded Rail Sequencing
I thought about trying to grab rail sequencing information with full load (or with the supply attached to a working Indy) however as you can see, putting a load on the +5V rail did not affect much.
The power supply turns on relatively slowly in the following order:
Start order Finish order Rail Ramp time 1 4 +5V 16.81576ms 2 3 -12V 10.78516ms 3 1 3.3V 8.13464ms 4 2 +12V 9.1609ms
As you can see, at least for these particular samples, the Nidec holds regulation better under load versus the Sony but is also a much noisier supply. Is it because the capacitors are going? No idea, but it is not the only Nidec I have that behaves that way. The no-load ripple of the 12V rail certainly stands out!
chunk 7
ttle bit of coffee this morning when I read that hinv output, hahah.
nondem said:
IP59_4CPU Board: barcode NSG072 part 030-1989-003 rev -B
Click to expand...
What you have there is an Origin 350, not a 300 - with the exceptionally rare IP59 board. Each of the processors on it have double the cache of the lesser models, and run 200mhz faster - it's the fastest mainboard that SGI had ever made! Very desirable. Sounds like you've got a beautiful system to work with - at least for that first brick.
--- Post by HAL ---
ok,
your hinv shows the resources of 1 brick, so in case you have a numalink'ed setup of 4 bricks you will have to make a reboot in order to add the resources of the remaining 3 bricks to the setup. Make a reboot and already during the POST you will see it is running discovery and will hope-
fully detect the other bricks.
The fact that you have an O350 4x1ghz means also that your setup is not 20 years old - that very machine was released around 2004.
--- Post by nondem ---
HAL said:
ok,
chunk 7
ferent result. So at least I know the console connection is "working". But I can't get further into the system. Doesn't really "boot up" I suppose? I've tried removing the HDD as well. Same result.
Seems like I've tried every permutation and combination of system boards, CPU swaps, Memory exchanges, HDD exchanges, Graphics in/out etc... Can't get it to give me any output without getting a red light on the front, or a white light with no output.
I'm currently in the middle of a move and I've put this project on hold for now. I'm sure there will be some informative ideas, but I can't tackle them until at least a few months.
--- Post by 3DChris ---
So after almost a year I've successfully moved into my new place and am trying to get the system back up and running.
chunk 7
(pci id 4)
controller multi function SuperIO
controller Ethernet Rev 1
adapter USB (OHCI interface)
(pci id 5)
ASIC XBOW Rev 2, on CBrick, Module 001c01
ODYSSEY Graphics Board, Module 001c01
I tried booting again with mouse and keyboard:
Code:
BASEIO PROM Monitor SGI Version 6.201 built 08:56:46 AM Jun 2, 2004 (BE64)
1 CPUs on 1 nodes found.
Automatic update of PROM environment disabled
PS/2 Keyboard & Mouse diagnostics
Found mouse on port 0
Found keyboard on port 1
PS/2 Keyboard & Mouse diagnostics passed
Graphics diagnostics
Odyssey board #0 found on nasid 0
Running Odyssey xtalk sanity diag...
Board version 1 - Buzz revision 2B
On board sdram size: 128 Mb
Cas latency: CAS 3
4 banks by sdram module
Running Odyssey Buzz registers diag...
Device passed diagnostics
Installing PROM Device drivers ............
Base I/O Ethernet set to /dev/ethernet/ef0
Installing Graphics Console...
graphics install: searching for pipe 0
Walking SCSI Adapter 0, (pci id 1)
1+ Device Vendor Product: IBM-ESXS ST336732LC FN
2- 3- 4- 5- 6- 7- 8- 9- 10- 11- 12- 13- 14- 15- = 1 device(s)
chunk 7
by callahan ---
TL;DR: After further tests, I've found that SCSI2SD v6's max performance is slower than a high-end 10,000RPM SCSI drive, but it still often outperforms such drives in normal usage.
I decided to do some benchmarks using my own hardware. My test system:
SGI Indy, 180Mhz R5K, 256MB RAM
Two identically imaged drives with Irix 6.5.22 and a smattering of Nekoware and demos (each drive was tested when it was the only drive on the bus, primarily because I can't get my SCSI2SD to work with another drive.)
-- SCSI2SD v6 w/ Transcend 64GB High performance SD card. More on my SCSI2SD settings below.
-- Fujitsu MAJ3182MP UW-160 10,000RPM SCSI disk (68 pin interface w/ a 68-50 pin adapter).
chunk 7
dy via ZuluSCSI.
For me reading of IMGs (install CDs etc.) seems ok but on write attempts I get errors - typically these revolve around drive geometry - sectors x heads vs size don't seem to align.
I've yet to try turning off SCSI2 and I will also see if different card and fresh format might help things. Also check if I have the latest firmware.
Also has anybody tried the INITIATOR mode? this looks awesome on paper - allows you to automatically image any SCSI disks found on the same system (driver I guess) as files on the SD card. I tried this to image the original SCSI drive that came with my Indy and it seems to work but I face the geometry errors there when trying to boot from it.
--- Post by flexion ---
liquidkoshman said:
Also has anybody tried the INITIATOR mode? this looks awesome on paper - allows you to automatically image any SCSI disks found on the same system (driver I guess) as files on the SD card.
Click to expand...
I've successfully used initiator mode to clone from a SCSI2SD to Zulu on Indigo2 IMPACT
No problems with ZuluSCSI so far, I'm using pretty much default settings (SCSI2).
chunk 7
0
ethtool -E eth0 magic 0x669955aa length 1 offset 0x153 value 0x00
ethtool -E eth0 magic 0x669955aa length 1 offset 0x154 value 0x00
ethtool -E eth0 magic 0x669955aa length 1 offset 0x155 value 0x00
ethtool -E eth0 magic 0x669955aa length 1 offset 0x156 value 0x00
ethtool -E eth0 magic 0x669955aa length 1 offset 0x157 value 0x00
ethtool -E eth0 magic 0x669955aa length 1 offset 0x158 value 0x00
ethtool -E eth0 magic 0x669955aa length 1 offset 0x159 value 0x00
ethtool -E eth0 magic 0x669955aa length 1 offset 0x15A value 0x00
ethtool -E eth0 magic 0x669955aa length 1 offset 0x15B value 0x00
ethtool -E eth0 magic 0x669955aa length 1 offset 0x15C value 0x00
ethtool -E eth0 magic 0x669955aa length 1 offset 0x15D value 0x00
ethtool -E eth0 magic 0x669955aa length 1 offset 0x15E value 0x00
ethtool -E eth0 magic 0x669955aa length 1 offset 0x15F value 0x00
Installing in a SGI Fuel running IRIX 6.5.30 automatically recognized the card and assigned it tg1.
If you find this helpful, please reply! Thanks.
Sources:
Nekonomicon - SGI P/N 9210289 ~ 3Com 3C996B-T Gigabit Network Card
chunk 7
RIX installs smoothly.
--- Post by jander31 ---
I appreciate all of the responses! I ended up picking a 10K RPM 73GB IBM-rebranded Seagate 80-pin SCSI drive.
A couple additional questions for now:
Will the Origin 300 support an IRIS Gigabit PCI-X card? There's two part numbers, 9470434 and 9210169. The latter is fiber optic, which I'd love to experiment with. I was looking at this thread , but I couldn't understand what was going on; what do 2, 6, 12, and X mean?
What was the "average" use case of an Origin 300? Some guy on Facebook said he did presales for SGI, and one hosting company ran backup software on their Origin 300s. What else were Origin 300s used for?
Thank you again!
Edit: The manuals for each of the Gigabit cards mentioned the Origin 200, Onyx2, Origin 2000, and the Octane. I assume the cards won't be compatible with the Origin 300?
--- Post by joshyfishy22 ---
Ya those gigabit pcix cards should work. Iv never tried them myself in a origin 300 but they should work if they are the special sgi ones. And for the numbers. Thats the amount of pci slots that system has. And the X is a checkmark for what it is.
chunk 7
ing this new setup made them completely flat.
You can see in the above image how the clips provide additional support near the corners where joint failure appeared to be most common.
Kapton tape applied and keeping the clips secured (though they fit snugly enough to hold just fine by themselves) and the heatsink mounted with a small bit of additional pressure.
I added one more bit of Kapton tape near the right front side in order to keep things more even.
Alright, so that's the first problem solved! TRAM modules stripped down, cleaned up, joints resoldered, new TIM installed, and new clips to help keep the pressure applied much more even. Since we have the second part to get to, I'll go ahead and mention now that the TRAMs installed with zero issues and worked with no issues. I had the beginnings of failing TRAMs and now I can be comfortable in knowing that they are fixed! (Really the TRAMs were a bit worse than the previous photos show. I repaired around 35 joints between all three boards)
chunk 7
---
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name : SCSI2SD
# Test date : Fri Jan 31 05:08:13 2025
# Test machine : IRIX64 indigo2-purple 6.5 10070055 IP28
# Test type : XFS data subvolume
# Test path : /tmp/testfile
# Request sizes : min=16384 max=4194304
# Parameters : direct=1 time=5 scale=1.000 delay=0.000
# XFS file size : 134217728 bytes
#---------------------------------------------------------
# req_size fwd_wt fwd_rd bwd_wt bwd_rd rnd_wt rnd_rd
# (bytes) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s)
#---------------------------------------------------------
16384 2.57 6.18 2.33 6.22 2.13 5.93
32768 3.14 7.28 3.31 7.30 3.22 7.09
65536 3.27 7.93 3.55 7.96 2.48 7.82
131072 3.54 8.35 3.61 8.34 2.98 8.30
262144 3.52 8.39 3.41 8.39 1.04 8.35
524288 2.17 8.15 3.38 8.34 2.19 8.33
1048576 3.24 8.34 3.48 8.37 2.70 8.35
2097152 2.75 8.34 3.37 8.35 3.59 8.34
4194304 2.35 8.48 3.13 8.45 3.58 8.51
Both SD cards are rather cheap with low specs
chunk 8
(default)
3. Non-block write-reissue
2
5. TmrIntEn
0. Timer Interrupt Enabled (default)
1. Timer Interrupt Disabled
0
6. Secondary cache present
0. Not Present
1. Present (default)
1
7. DrvOut
0. 67%
1. 50% (slowest)
2. 100% (default)
3. 83%
2
8. Secondary cache RAM type
0. Dual Cycle Deselect SRAMs (default)
1. Single Cycle Deselect SRAMs
0
9. User configuration identifiers (Config[21..20])
0. 00
1. 01
2. 10
3. 11
0
10. Multiply mode (bit20)
0. Integer Multiplier (default)
1. Half-integer Multiplier
1
[PROM] RM5271 custom bitstream saved.
========================================
O2 CPU PROM EMULATOR FW. REV. A00
CPU: RM5271
Bitstream Profile: custom
Bitstream settings: WriteBackRate: DDDD, Multiplier: x4.5, Endianness: BE, pipelined non-block writes, TmrIntEn: ON, Secondary cache: ON, DRVOut: 100%, SRAM type: Dual Cycle Deselect SRAMs, UserCfgID: 00, Mult mode: half-integer
Bitstream: 256 bits
Mode: Polled (all sends)
Type 'setup' + Enter for setup menu
Type 'status' + Enter for status
Type 'info' + Enter for info
Type 'boot' + Enter for USB bootloader
Type 'reboot' + Enter to reboot MCU
========================================
chunk 8
mory ICs present. There are also no resistors straps placed directly on the SysAD bus (like the newer carriers for R12k CPUs, those don't have a PROM at all, they to have a lot of resistors straps).
Another difference between this revision of the carrier and the R12k carrier, is the IC that sits left of the VICE chip.
On the R10k module:
On the R12k module (the one with no PROM and SysAD straps):
The R10k module has an ORCA OR2C16A FPGA, while the newer carrier module has an SGI & LUCENT branded ASIC.
Now, looking at the OR2C16A FPGA, this is an SRAM based FPGA, meaning it needs to load its configuration from an external device every time the board powers on.
The PROM on this CPU board is not connected to the CRIME ASIC in any way, but to the ORCA FPGA. It holds the FPGA bitstream, and since there isn't another memory device on the board, it also holds the R10k SysAD mode bits.
There are two ways the CPU mode bits and FPGA bitstream might be stored in the PROM:
1. PROM contains FPGA bitstream followed by the CPU configuration bits (good)
2. PROM contains the FPGA bitstream, the CPU configuration bits are baked right into the FPGA bitstream (bad)
chunk 8
ours into this model today!
Nothing like 3D modelling with a good cup of coffee!
--- Post by Irinikus ---
I managed to get some more work done on this model today: (Still a very long way to go!!!)
--- Post by Irinikus ---
After doing the work shown above, Ive made a start on "normalising" the mesh of the front face of the machine: (This is taking hours to complete, and this image gives you some idea as to how i'm working to accomplish this)
--- Post by Irinikus ---
I've neatened up the front face even more:
--- Post by Jacques ---
I’d love to see this moulded/printed! Nice work!
--- Post by Irinikus ---
Today I did a bit of work on the top right hand edge of the front face:
--- Post by Grim.Black ---
The model is looking really good. Can't wait.
--- Post by megaimg ---
Anyone has the O2 Base..I will love to fix mine....the base is damage in the back!
--- Post by Irinikus ---
I've now made a start on the inside surface of the model: (What a mess!!!)
--- Post by Irinikus ---
Here's where I ended today:
--- Post by Grim.Black ---
It's looking really good!
--- Post by Jan ---
Wow! So cool, what you are doing man!
The perfect solution for the average O2 owners problems !
chunk 8
that replaces the Xilinx part, and is reprogrammable (one can change values live with an USB cable connected).
--- Post by ruckusman ---
sdz said:
Thanks for linking those patches!
Good observation about the endianess! Would have likely been bitten by that too.
I will be making a PROM emulator of sorts, that replaces the Xilinx part, and is reprogrammable (one can change values live with an USB cable connected).
Click to expand...
With all of the boot-time mode strings at cold boot = 0, MIPS boots in little endian, it's actually right there in the datasheet, because bit 8 hasn't been set to 1 for big endian.
https://picture.iczhiku.com/resource/eetop/ShkdaOJfHhEFimMM.pdf
Chicago Joe's set:
Hex: 0x80550102 -> Binary: 10000000 01010101 00000001 00000010
I used online byte swapping, or what I thought were byte swapping tools, on the hex, and on the 32 bit binary, they swapped by nibble, not byte - not helpful.
Seems there's no strict rule for this as it depends on the context, it can be by nibble, byte, double-byte or 32 bit word.
It really did my head in.
chunk 8
me SD card into the second zulu board, everything worked fine.
here are my results: (left: zulu | right: spinning rust)
--- Post by stormy ---
Nice results there @flexion what SD card did you use?
--- Post by flexion ---
Currently on SanDisk Extreme PRO microSDXC,UHS-1, V30, 200 read | 90 write
chunk 8
is one dies. ZuluSCSI SD cards formatted with FAT are fully readable by Linux (though the actual disk image files ON the card are probably not...didn't try) and the dd copy completed without errors.
The ZuluSCSI is attached to a drive sled, and I used some 1/8" black textured ABS sheet to make a pseudo-panel for the "drive" and installed an activity LED on it. Unless you look really closely, it looks just like a HDD in the bay. I couldn't be happier with this solution, as every other option, using "real" HDDs looked like a lot of work. A very nice (and nicely priced) product, good value for money, and one I would recommend.
--- Post by stormy ---
@ka1axy Your post really confuses me because you say:
I just pulled the SD card and made a "dd" image of it on my Linux system, so I can create another card if this one dies.
Click to expand...
So I'm thinking you are either using it in RAW mode, or have a fundamental misunderstanding of what makes Zulu great for backups. ie; you don't need to be dd'ing an SD card to back it up, you simply open the drive, copy the drive image file with right click > copy, and paste it somewhere.
But earlier you said:
chunk 8
elt solder but you dwell enough time to rock them out slowly.
The Sony's do have some positives but until somebody figures out how to even just shift the fan curve properly, it's not worth my time.
Also to be fair, I'm not a big fan of posting material lists because it encourages people that shouldn't be inside these things to try to fix them. Remember they don't make any more of these and they're proprietary. So every unit that somebody chars the board with a heat gun or something is a unit lost permanently to time. If you have the correct tools then obviously making the material list yourself is absolutely no problem. After all most of the issues are going to be dimensional so even if somebody posted capacitor values you can't just go buy any random capacitor. You need to get one that's physically going to fit in the dimension required or it's actually smaller. Part numbers change so frequently that even when I order stuff, six months later one or more of the parts has been retired on DigiKey. That's another reason I don't bother.
chunk 8
ut is also a much noisier supply. Is it because the capacitors are going? No idea, but it is not the only Nidec I have that behaves that way. The no-load ripple of the 12V rail certainly stands out!
True vs. reactive vs. apparent power is a subject outside the scope of this post, but in simple terms the closer the power factor is to 1 (ideal), the fewer amps it takes to deliver the same amount of real work (watts). Power factor can be considered a secondary factor in terms of efficiency, affecting things like the amount of loss in power transmission from the utility company to you, how many things you can put on a circuit breaker even though it may appear under capacity, etc. The closer something is to a purely resistive load (e.g. heater or incandescent lightbulb), the closer to 1 its power factor will be.
chunk 8
her bricks.
The fact that you have an O350 4x1ghz means also that your setup is not 20 years old - that very machine was released around 2004.
--- Post by nondem ---
HAL said:
ok,
your hinv shows the resources of 1 brick, so in case you have a numalink'ed setup of 4 bricks you will have to make a reboot in order to add the resources of the remaining 3 bricks to the setup. Make a reboot and already during the POST you will see it is running discovery and will hope-
fully detect the other bricks.
The fact that you have an O350 4x1ghz means also that your setup is not 20 years old - that very machine was released around 2004.
Click to expand...
How do I do the reboot you speak of? I've rebooted the OS but I assume you mean the cluster hardware.
We did a * pwr up at the L1 prompt and the hardware check came back w/this:
Checking hardware inventory ...............
***Warning: Board in module 001c04 is missing or disabled
It previously contained a node-board, barcode RBS343 laser 627d35c3
***Warning: Board in module 001c04 is missing or disabled
It previously contained a IXBRICK board, barcode RBH247 laser 62755bf7
chunk 8
s, but I can't tackle them until at least a few months.
--- Post by 3DChris ---
So after almost a year I've successfully moved into my new place and am trying to get the system back up and running.
I was able to purchase a new Frontplane for the Octane as that's the only board that I haven't tried replacing. That seems to have done the trick! The system is now booted up into the startup environment, but it seems like everything is reset and doesn't know how to boot up properly. I completely forget how to use any of the commands as it's been years and years since I last did anything on this machine. I have a number of photos attached showing the HINV as well as the different error messages I'm getting.
Any help would be greatly appreciated in setting this bad-boy back up!
--- Post by mousehouse ---
Great to hear! I have an Octane as well, but not with your specs…
It looks like the variables for partition booting are missing. You need something like this:
Code:
setenv SystemPartition dksc(0,1,8)
setenv OSLoadPartition dksc(0,1,0)
setenv OSLoader sash
setenv OSLoadFilename unix
Assuming your disk is on controller 0 and has SCSI ID 1.
chunk 8
s Console...
graphics install: searching for pipe 0
Walking SCSI Adapter 0, (pci id 1)
1+ Device Vendor Product: IBM-ESXS ST336732LC FN
2- 3- 4- 5- 6- 7- 8- 9- 10- 11- 12- 13- 14- 15- = 1 device(s)
Walking SCSI Adapter 1, (pci id 1)
1- 2- 3- 4+ Device Vendor Product: PLEXTOR CD-R PX-R412C
5- 6- 7- 8- 9- 10- 11- 12- 13- 14- 15- = 1 device(s)
Initializing PROM Device drivers .......... DONE
odsy dfifo timeout
...
odsy dfifo timeout
INFO: console subchannel changed: 001a01 CPU0
A 000 001c01:
A 000 001c01: *** General Exception on node 0
A 000 001c01: *** EPC: 0xc00000001306c520 (0xc00000001306c520)
A 000 001c01: *** Press ENTER to continue.
A 000 001c01: POD SysCt Dex>
I got a lot of "odsy dfifo timeout" errors. before crash.
There is problem with the V12 board.
My plan next was trying to get rid of the strange environment values.
Code:
001a01-L1>flash status verbose
Flash image B currently booted
Image Address Status Revision Built
----- ---------- ------------- ---------- -----
A 0xffe10000 valid 1.14.4 07/25/2002 13:34:38
B 0xffe80000 default 1.14.4 07/25/2002 13:34:38
chunk 8
ther drive.)
-- SCSI2SD v6 w/ Transcend 64GB High performance SD card. More on my SCSI2SD settings below.
-- Fujitsu MAJ3182MP UW-160 10,000RPM SCSI disk (68 pin interface w/ a 68-50 pin adapter).
First, I benchmarked both drives using diskperf 1.2. I found that the 10 second test interval produced wildly varying and often nonsensical results (near zero throughput or throughput nearly twice the theoretical maximum speed of the Indy's Fast SCSI bus), so in the end I used 60 second test intervals. Note this is 60 seconds per test (i.e. 60 seconds for 4MB forward write, 60 seconds for 4MB forward read, etc.), so a complete test suite takes ~75 minutes. I ran each test twice on each drive. The two test runs gave very similar results (minus a couple of outliers on the SCSI2SD data), with 1-sigma values generally less than .2MB/S.
These results showed that at best, the SCSI2SD performed roughly on par with the Fujitsu control, especially with read/writes less than 64kb. With larger files, at best it performed on par with the Fujitsu and, at worst (large file write performance), had less than half the measured throughput.
chunk 8
Click to expand...
I've successfully used initiator mode to clone from a SCSI2SD to Zulu on Indigo2 IMPACT
No problems with ZuluSCSI so far, I'm using pretty much default settings (SCSI2).
Also moved an Indy from SCSI2SD to ZuluSCSI, where I used dd to pull an image. For older/smaller disks watch out for sector size, might be 512.
--- Post by liquidkoshman ---
flexion said:
I've successfully used initiator mode to clone from a SCSI2SD to Zulu on Indigo2 IMPACT
No problems with ZuluSCSI so far, I'm using pretty much default settings (SCSI2).
Also moved an Indy from SCSI2SD to ZuluSCSI, where I used dd to pull an image. For older/smaller disks watch out for sector size, might be 512.
Click to expand...
Thanks for sharing your experience.
chunk 8
the card and assigned it tg1.
If you find this helpful, please reply! Thanks.
Sources:
Nekonomicon - SGI P/N 9210289 ~ 3Com 3C996B-T Gigabit Network Card
supported (non SGI) PCI gigabit cards? - Page 4 - Nekochan Net
web.archive.org
chaos/servers/system/pci/pci-id.c at master · chaos4ever/chaos
The chaos Operating System. Contribute to chaos4ever/chaos development by creating an account on GitHub.
github.com
Nekonomicon - 3com 996B eeprom dump?
sgi: tricks: gigabit ethernet
rqsall.com
--- Post by ruckusman ---
I'm not after a gigabit ethernet BUT this is incredibly interesting and very well documented.
From the live Mint install you've effectively overwritten the PCI and Vendor ID's on the card to identify and initialise with the SGI Tigon driver as opposed to making those changes in the driver file, which was the way it was accomplished on Nekochan in the very beginning - colour me impressed, it's a very useful method.
chunk 8
tried them myself in a origin 300 but they should work if they are the special sgi ones. And for the numbers. Thats the amount of pci slots that system has. And the X is a checkmark for what it is.
Id say the most average use case with the origin 300s today for hobbyist are for numalinking together and being used as compute nodes with graphics to have a workstation type system (Onyx 300/350). Another usecase would be a compliation machine for development since they are fast and have 2 or more procs.
chunk 8
of failing TRAMs and now I can be comfortable in knowing that they are fixed! (Really the TRAMs were a bit worse than the previous photos show. I repaired around 35 joints between all three boards)
So, now that the TRAMs are repaired and, in my humble opinion, better set up for lasting longer, we still have a second problem to deal with. This one could potentially make the previous work all for not.
Problem 2: SGI provided relatively adequate cooling for offices that kept the AC running at 65-68 degrees Fahrenheit (18-20 C) but that's not quite the reality of where these machines were used and certainly not where they're used today. The fact is, SGI used some incredibly good fans for the time period. So good in fact that you'd be hard pressed to find any replacements that can do better than stock. There are numerous posts on the old .sgi USEnet in addition to Nekochan, IRIXnetwork, and here about how to replace fans in systems with quieter ones to help keep down the noise.
chunk 9
r setup menu
Type 'status' + Enter for status
Type 'info' + Enter for info
Type 'boot' + Enter for USB bootloader
Type 'reboot' + Enter to reboot MCU
========================================
Attached SGI_O2_CPU_PROM_EMULATOR_A00_RELEASE.zip archive (will be available at https://sdz-mods.com/index.php/2026/02/18/sgi-o2-cpu-prom-emulator/ as well).
It contains the following:
1.SCH_BRD - contains editable schematic and board files. Format is Eagle CAD, but they can be imported in other tools, like Kicad.
2.SCH_PDF- schematics in pdf format.
3.P&P - pick and place files
4.BOM
5.GERBER - gerber files
6.FIRMWARE - pre-built firmware to be flashed on the RP2040
7.FIRMWARE_SRC - firmware source code plus support files.
Notes:
-For first flashing, press the tactile switch and connect the USB cable. It will show up as a mass storage device. Drag and drop the .uf2 file.
Subsequent flashes can be done the same way or type "boot" followed by Enter key in the console. It will go into recovery mode and show up as a mass storage device.
-Not all bitstreams have been tested as I either don't have those CPUs or the boards to solder them on.
chunk 9
he PROM:
1. PROM contains FPGA bitstream followed by the CPU configuration bits (good)
2. PROM contains the FPGA bitstream, the CPU configuration bits are baked right into the FPGA bitstream (bad)
Now, to analyze the dump. Wrote a python script to make the data a bit more parse-able, and had a look. The PROM dump matches the ORCA Series 2 devices bitstream structure:
-dummy 1 bits
-a 4 bit preamble 0010
-a 24 bit length count
-frames
-end of configuration pattern 0010011111111111
-dummy 1 bits
The 24 bit length count (which in the dump is at [15:38] is 000000110101111110110000, which means 221104 bits of FPGA configuration data. Add to this the dummy bits, preamble, length count, end pattern and that is 100% of the PROM dump. There is nothing extra after the FPGA bitstream part ends, meaning, we are here:
2.PROM contains the FPGA bitstream, the CPU configuration bits are baked right into the FPGA bitstream (bad).
(PROM dump attached to this post R10k_output_full_PROM.zip, it contains a text file with ones and zeroes, first one/zero is the first bit read by the FPGA).
chunk 9
ere's where I ended today:
--- Post by Grim.Black ---
It's looking really good!
--- Post by Jan ---
Wow! So cool, what you are doing man!
The perfect solution for the average O2 owners problems !
--- Post by Irinikus ---
I managed to get around to doing some work on this model this morning, it's been quite a while!
--- Post by Jan ---
I wonder why these models are in such a bad shape. They came out of the Inventor files of the IVView demo and they surely are an output of the real design data from the O2.
--- Post by Irinikus ---
If you look at them in a wireframe mode in inventor, they appear to be the exact mashes I started with.
--- Post by Irinikus ---
More cleaning up this morning: (This little bit of work took hours!)
The start:
--- Post by jenna64bit ---
All the annoying tolerances for the volume buttons! How close is that to fitting them?
--- Post by Irinikus ---
Final adjustments will be made once I've finished with the base of the machine and bring them together!
The only way to know if this model will fit an actual machine would be to 3D print it and make adjustments from there, a time-consuming and costly process!
chunk 9
they swapped by nibble, not byte - not helpful.
Seems there's no strict rule for this as it depends on the context, it can be by nibble, byte, double-byte or 32 bit word.
It really did my head in.
If I couldn't get Chicago Joes's known good working set to correctly correspond with the RM7000 datasheet...
I knew that I had no chance of getting the RM7900 bit time mode set string correct (It's longer than 32 bits) - from the RM7965 datasheet
https://www.datasheets360.com/pdf/-6475857418499999415 - pages 48 -> 52, significantly different.
BTW if you are able to read an R5K @ 180MHz or 200MHZboot-time string &/or RM5200 @ 300MHz mode string, would love to compare bits 17:16 of Chicage Joe's set as I've interpreted them according to the RM7000 data sheet, even though it's ignored, it's only one out of place so to speak.
I just bought a Tl866/T48, it's en route
A Xylinx PROM emulator, that would be a thing of beauty
--- Post by sdz ---
Thanks for Chicago Joe's set. Wasn't able to find that one. I will compare it at some point against the datasheet.
chunk 9
backups. ie; you don't need to be dd'ing an SD card to back it up, you simply open the drive, copy the drive image file with right click > copy, and paste it somewhere.
But earlier you said:
I set up two CDROM files and three HDD files. All devices were recognised by the Iris Indigo at their assigned SCSI device IDs.
Click to expand...
So that means you *should* be understanding how it works... so why on earth have you dd'd your SD card for backup? It's puzzling me, please elaborate
--- Post by RubyManning ---
aperezbios said:
In the interest of not derailing the original thread, this is a separate thread intended to cleanly peel off from this thread.
Since there seems to be a lot of confusion and outright FUD regarding this issue, I'd like to clarify that the BlueSCSI Pico/V2 firmware is ~98% re-branded ZuluSCSI firmware . That's why "Copyright <year> Rabbit Hole Computing" is present over 70 times in the current version of the BlueSCSI code base. This is easily verifiable via a simple recursive grep of the BlueSCSI code base for the string "Rabbit Hole Computing". We own the copyright to the code because we wrote it.
chunk 9
or it's actually smaller. Part numbers change so frequently that even when I order stuff, six months later one or more of the parts has been retired on DigiKey. That's another reason I don't bother.
I'm not trying to be arrogant about it, I'm simply saying that the barrier to entry stays where it is because these things are so easy to damage and we've already lost a huge amount of inventory already to people throwing away broken parts. It's one of the main reasons prices have radically increased in in the past decade.
Obviously it's personal property and you may do whatever with it, I just warned you that it is a project and you should expect to at least spend 10 hours or so not only removing each of those capacitors and marking where they're supposed to go but also researching their correct replacement and recording that and their dimensions and then finding something that's actually in stock at a reputable part supplier that matches those specifications.
Since your power supply technically works you shouldn't have any semiconductor issues so a simple recap should work. I also recap the logic daughterboard on the Nidecs, as there are a few small electrolytics there.
chunk 9
a circuit breaker even though it may appear under capacity, etc. The closer something is to a purely resistive load (e.g. heater or incandescent lightbulb), the closer to 1 its power factor will be.
A power factor of 0.8 to 0.9 is pretty good for a switching power supply, but 0.6 is not so hot. The negative sign on the power factor as read by the power meter in the tables above means that the current leads the voltage (capacitive), so a power factor of -0.4854 should be read as "0.4854, capacitive" (rather than inductive like a motor load). Don't mistake negative readings as being further away from 1, just ignore the negative sign.
On the subject of efficiency in general, the supplies are pretty bad:
Power supply State Watts / VA in Watts out Real power efficiency Apparent power efficiency Nidec Soft power-off 3.559W, 8.402VA 0W 0% 0% Nidec No-load 17.309W, 26.10VA 0W 0% 0% Nidec 5V @ 2A 34.324W, 49.44VA 10.06W 29.31% 20.35% Nidec 5V @ 10A 86.26W, 119.8VA 49.35W 57.21% 41.19% Sony Soft power-off 3.267W, 6.731VA 0W 0% 0% Sony No-load 6.174W, 13.40VA 0W 0% 0% Sony 5V @ 2A 17.807W, 35.24VA 10.27W 57.67% 29.14% Sony 5V @ 10A 64.69W, 105.8VA 48.82W 75.47% 46.14%
chunk 9
It previously contained a node-board, barcode RBS343 laser 627d35c3
***Warning: Board in module 001c04 is missing or disabled
It previously contained a IXBRICK board, barcode RBH247 laser 62755bf7
***Warning: Board in module 001c04 is missing or disabled
It previously contained a IXBRICK board, barcode RBH247 laser 62755bf7
***Warning: Board in module 001c10 is missing or disabled
It previously contained a node-board, barcode RBT012 laser 627ddc66
***Warning: Board in module 001c10 is missing or disabled
It previously contained a IXBRICK board, barcode RBX743 laser 6280d943
***Warning: Board in module 001c10 is missing or disabled
It previously contained a IXBRICK board, barcode RBX743 laser 6280d943
***Warning: Board in module 001c08 is missing or disabled
It previously contained a node-board, barcode RBT018 laser 627ddc6c
***Warning: Board in module 001c08 is missing or disabled
It previously contained a IXBRICK board, barcode RBX752 laser 6280d966
***Warning: Board in module 001c08 is missing or disabled
It previously contained a IXBRICK board, barcode RBX752 laser 6280d966
DONE
--- Post by nondem ---
More output that might mean something to you experts:
chunk 9
Code:
setenv SystemPartition dksc(0,1,8)
setenv OSLoadPartition dksc(0,1,0)
setenv OSLoader sash
setenv OSLoadFilename unix
Assuming your disk is on controller 0 and has SCSI ID 1.
--- Post by 3DChris ---
I sorted out why it wasn't booting. I have an Acard SCSI to SATA dock with an SSD and for some reason it isn't being seen by the system. I managed to find my backup boot disk that's an old spinning HDD and it now sees it and can boot into the system.
So now I'm trying to figure out why it takes the computer about 10-15 minutes to actually chime and start the boot sequence once I press the power button. I can hear the fans spinning and the light is on the front (not red), but no chime or video output for 10-15 minutes.
--- Post by jenna64bit ---
That is very strange! If you haven't, you might want to run "resetenv" in the PROM's Command Monitor. It'll do what you think, but at least gets you starting from a more known spot.
--- Post by 3DChris ---
I'll give that a shot when I get home.
chunk 9
rently booted
Image Address Status Revision Built
----- ---------- ------------- ---------- -----
A 0xffe10000 valid 1.14.4 07/25/2002 13:34:38
B 0xffe80000 default 1.14.4 07/25/2002 13:34:38
I concluded from the date that it was well before the 600Mhz CPU was released and L1 propably doesn't understand the data it is getting.
To reflash the L1 I needed to get IRIX running.
I set up raspberry pi with LOVE tool.
I had to rebuild the kernel with IRIX efs filesystem support.
I mounted IRIX 6.5.21 installation media images and configured LOVE to use them.
I removed mouse and keyboard and I think i changed to "setenv console d" too.
First the netinst failed:
Code:
chunk 9
especially with read/writes less than 64kb. With larger files, at best it performed on par with the Fujitsu and, at worst (large file write performance), had less than half the measured throughput.
Sequential read/write test results (average of two runs, using the forward test results only; backward tests showed the same trends):
Random read/write test results (average of two runs):
Next, I performed a suite of three tests representing real-world use cases. These results found, in contrast to the above, that performance with the SCSI2SD was better than the Fujitsu in every day applications. I repeated the first two test series twice, again values from the tests matched nicely. I only performed the tar tests once per drive.
Test 1: System boot-up (time from the first text displayed on the mini-root to the visual login window)
SCSI2SD: 44 seconds
Fujitsu: 51 seconds
Test 2: Firefox loading (from open command to complete rendering of www.google.com )
chunk 9
Indy from SCSI2SD to ZuluSCSI, where I used dd to pull an image. For older/smaller disks watch out for sector size, might be 512.
Click to expand...
Thanks for sharing your experience.
Interestingly I was able to successfully install IRIX 5.3 on the mechanical SCSI drive that came with my Indy yesterday and it seems to work just fine (from ZuluSCSI emulated CD drive). But no luck so far with ZuluSCSI - latest firmware, different cards, different termination setups, tried both exFAT and FAT32 format, quick or full format, different options - SCSI2 yes/no, synchronicity, raw card vs image etc.
Can you please elaborate on the sector size? When I see any error messages in the ZuluSCSI log it's usually related to incorrect disk geometry - sectors x cylinders (default 63 x 255) don't agree with detected size (size not divisible). This sounds like it could be related to formatting options, sector size, but my experimentation so far was unsuccessful etc.
Thanks.
--- Post by flexion ---
liquidkoshman said:
chunk 9
the SGI Tigon driver as opposed to making those changes in the driver file, which was the way it was accomplished on Nekochan in the very beginning - colour me impressed, it's a very useful method.
--- Post by CRaven ---
This should be compatible with the Tezro as well?
--- Post by draconpern ---
CRaven said:
This should be compatible with the Tezro as well?
Click to expand...
It should be since Tezro is just the multi-cpu version of fuel.
--- Post by 7spirals ---
Thank you, I appreciate this. I have a Tezro and a 3C996
--- Post by 0xDEADBEEF ---
Neat, worked beautifully with 3com card. The hard part was getting old PCI-X system to flash this one and lsi sata controller ;-)
chunk 9
better than stock. There are numerous posts on the old .sgi USEnet in addition to Nekochan, IRIXnetwork, and here about how to replace fans in systems with quieter ones to help keep down the noise.
I'll lead this next part by saying that noise was a concern, but was absolutely not my number one issue. My goal was to figure out how to replace the front-mounted fan with something that pushes more air AND has equal or higher static pressure. I ended up finding a solution to this goal, albeit with a small increase in fan noise but with higher airflow and static pressure.
The stock fan that all Indigo2 units use is the Panaflo FBA09A12V. It is a 92x25mm 12v fan that draws 0.25 amps. It is rated for up to 56 cubic feet per minute of airflow at 3.98mm of H20 static pressure. This fan can be found in many SGI machines including the Octane. It's a very capable fan and balances things well with only 35dB of sound. It generally strikes a solid balance between noise and functionality.
chunk 10
Enter key in the console. It will go into recovery mode and show up as a mass storage device.
-Not all bitstreams have been tested as I either don't have those CPUs or the boards to solder them on.
--- Post by mattst88 ---
That is incredibly cool. Fantastic work!
--- Post by sdz ---
Now tested with RM5271.
Below is a config example for setting half integer multiplier (SysClock to Pclock) at 3.5x, for running the CPU at 350MHz:
Code:
========================================
O2 CPU PROM EMULATOR FW. REV. A00
CPU: R5000
Bitstream Profile: default R5000 180/200MHz 512kB secondary cache
Bitstream: 256 bits
Mode: Polled (all sends)
Type 'setup' + Enter for setup menu
Type 'status' + Enter for status
Type 'info' + Enter for info
Type 'boot' + Enter for USB bootloader
Type 'reboot' + Enter to reboot MCU
========================================
setup
1. R5000
2. RM5271
3. RM7000
4. RM7000A
5. RM7000B
6. RM7000C
7. RM7900 (RM7965 Mode bits)
8. SR71010A
2
1. default RM5271 300MHz secondary cache off
2. default RM5271 300MHz 1MB secondary cache
3. default RM5271 350MHz secondary cache off
4. default RM5271 350MHz 1MB secondary cache
5. custom
5
chunk 10
ked right into the FPGA bitstream (bad).
(PROM dump attached to this post R10k_output_full_PROM.zip, it contains a text file with ones and zeroes, first one/zero is the first bit read by the FPGA).
Making any changes to the R10k mode bits would require reverse engineering the ORCA2 bitstream. To have any change of making sense of it, the first thing needed is the actual SysAD configuration of this module. There are a couple of ways of doing this:
1. Read CP0 Config from Irix somehow. I have no clue how to do this at the moment, and I'd like a quick solution
2. Read the mode bits directly from the SysAD bus.
Going with option 2.
Now, to measure the SysAD I'd need to solder a bunch of wires on the bus, and figure out when to actually sample the data. I would like to avoid this.
Since the assumption is that the FPGA straps the SysAD bus, it is very likely the rest of the system is not needed to measure them. Not even the CPU.
I traced the 3.3V and 5V rails on the MB to the CPU connectors, and powered on the bare CPU module (without MB and CPU) with a lab power supply:
chunk 10
e of the machine and bring them together!
The only way to know if this model will fit an actual machine would be to 3D print it and make adjustments from there, a time-consuming and costly process!
In a worst case scenario, you'd end up with a nice looking O2 enclosure for a Raspberry Pi!
I'll get the model to look as good and clean as possible, but a 3D printed model would still require some finishing in the form of sanding to get it the way it should be!
--- Post by Grim.Black ---
looking forward to seeing the final product.
--- Post by jenna64bit ---
Yeah, I'm genuinely interested enough that I might try and take the model, print out some sections of it and check vs my O2. - Well, pay someone to print.
--- Post by Irinikus ---
This is where I ended today on this model:
--- Post by Irinikus ---
Some more work done today: (This takes more time than most would think!)
--- Post by Irinikus ---
Next I cleaned this up a bit, but I'll still have to do allot of optimising once I fit the CD-ROM bezel: (What a mess this was!!!)
--- Post by Irinikus ---
I've now rebuilt the rear panel, so I'm almost done with this piece for now!
chunk 10
route
A Xylinx PROM emulator, that would be a thing of beauty
--- Post by sdz ---
Thanks for Chicago Joe's set. Wasn't able to find that one. I will compare it at some point against the datasheet.
I will dump all the PROMs I have, but waiting to get a few more CPU modules first. Currently I only have an R5k 180MHz and an R10k 150MHz.
--- Post by ruckusman ---
I got the AT17LV65A.bin from discord - I mistakenly thought it was hosted on the sgidepot site - seems not - it won't allow me to upload the binary file, will forward to you on discord
Good thread here
The SGI O2 600MHz R7K mod in 2024
It's been a long time comin'! Since getting my O2, I've had the plan to try and fit it with the 600MHz R7K CPU through a BGA swap on a 300MHz R5K card. It's been a couple of years now, but I've finally made the move to BGA soldering in the last few months, and after getting comfortable with...
forums.sgi.sh
The R5K boot time mode strings interest me from the perspective of verifying them against a data sheet to verify the RM7000C byte flipping
chunk 10
the BlueSCSI code base. This is easily verifiable via a simple recursive grep of the BlueSCSI code base for the string "Rabbit Hole Computing". We own the copyright to the code because we wrote it.
At a firmware level, the BlueSCSI V2 code base is nearly identical, with the notable exception of the format of the text in the log file, which is all most end users actually see. There are many other small and relatively superficial differences, but at the end of the day, nearly all of the heavy lifting was done by us, and at my expense. The BlueSCSI V2 firmware represents a search-and-replace of "Zulu" to "Blue"
The BlueSCSI V2 hardware is slightly different, since the BlueSCSI V2 hardware designs only use the Pico/Pico2, so it's necessary for the pinout to be slightly different. It's also worth noting that the BlueSCSI V2 (and original V1) hardware designs omit components necessary to mitigate Electromagnetic Interference , and that these components, which are surface-mount ferrite bead inductors, can and do slightly affect signal timings. While those differences are small, they can and do matter in practice.
chunk 10
supply technically works you shouldn't have any semiconductor issues so a simple recap should work. I also recap the logic daughterboard on the Nidecs, as there are a few small electrolytics there.
Also I don't know about the Sonys, but the Nidecs also use a very old form of stabilizer that glues several of the components down as well as holds the daughterboard down to its connectors to prevent accidental separation during shipping. About 25 minutes of my time is spent very carefully disconnecting these with a special low temperature blade on my soldering iron and then attempting to get it removed off some of the components. Some of them are fully coated in this stuff which causes some problems and some of it is just to tack components to each other but all of them need to be separated because several need replacement. So not only will you have to replace components you'll likely have to separate the old stabilizer. I replace the stabilizer with a 3M product design designed for the same purpose but using different chemicals.
chunk 10
7.21% 41.19% Sony Soft power-off 3.267W, 6.731VA 0W 0% 0% Sony No-load 6.174W, 13.40VA 0W 0% 0% Sony 5V @ 2A 17.807W, 35.24VA 10.27W 57.67% 29.14% Sony 5V @ 10A 64.69W, 105.8VA 48.82W 75.47% 46.14%
The Nidec has a slightly better power factor than the Sony, but both are poor overall. The Sony is more efficient than the Nidec and seems to do better with both lighter and heavier loads, but again neither are great and from certain angles they are really quite bad! Efficiency and power quality alone are enough reason to develop a new Indy supply, even if reliability weren't an issue. With issues like the Sony supply's fan, heat buildup in the Indy can be problematic and an inefficient power supply that just throws away 25-70% of power away as heat doesn't help.
How attached are you to your Indy power supply? I am not very attached to mine after this!
Both draw a little over 3W when the machine is powered off but plugged in.
--- Post by Elf ---
I put in a bit of work today to solve the last remaining Indy PSU mystery: the temperature sensor. It is not quite what I thought before, but not far off either.
chunk 10
rd in module 001c08 is missing or disabled
It previously contained a IXBRICK board, barcode RBX752 laser 6280d966
DONE
--- Post by nondem ---
More output that might mean something to you experts:
001c02-L1>reset
returning to console mode 001c02 CPU0, <CTRL_T> to escape to L1
Starting PROM Boot process
IP35 PROM SGI Version 6.210 built 02:33:51 PM Aug 26, 2004
Testing/Initializing memory ............... DONE
Copying PROM code to memory ............... DONE
Discovering local IO ...................... DONE
Discovering NUMAlink connectivity .........
Local hub NUMAlink is down.
*** Local network link down
DONE
--- Post by nondem ---
HAL said:
ok,
your hinv shows the resources of 1 brick, so in case you have a numalink'ed setup of 4 bricks you will have to make a reboot in order to add the resources of the remaining 3 bricks to the setup. Make a reboot and already during the POST you will see it is running discovery and will hope-
fully detect the other bricks.
The fact that you have an O350 4x1ghz means also that your setup is not 20 years old - that very machine was released around 2004.
Click to expand...
chunk 10
want to run "resetenv" in the PROM's Command Monitor. It'll do what you think, but at least gets you starting from a more known spot.
--- Post by 3DChris ---
I'll give that a shot when I get home.
Now my system isn't seeing my keyboard properly since I posted my previous post. I can see the green LEDs very faintly flashing on/off. When I unplug it and plug it back in, they flash brightly for a brief second, then continue to faintly flash. I tried using DeoxIt! spray to clean the contacts, but that didn't help.
I've got a keyboard from work that I'll borrow to see if changing it will help. Right now I can't get into the system because of it.
--- Post by weblacky ---
A couple possible points.
Did you move over the system ID when you exchange front plane, which I assume is/was the XBOW board? It has a thing that looks like a coin cell battery but is most definitely not a coin cell battery?
The small fan that failed before must've been the ASIC HEART fan, explains your XBOW failure.
chunk 10
IRIX 6.5.21 installation media images and configured LOVE to use them.
I removed mouse and keyboard and I think i changed to "setenv console d" too.
First the netinst failed:
Code:
IRIX Release 6.5 IP35 Version 07141608 System V - 64 Bit
Copyright 1987-2003 Silicon Graphics, Inc.
All Rights Reserved.
QLFC: running as interrupt thread.
QLFC: using spinlocks.
WARNING: Xbow at /hw encountered Fatal error
xtalk PIO Read error in kernel mode
widgetnum: 0xd
srccpu: 0x0
srcnode: 0x0
errnode: 0x0
sysioaddr: 0xd23241c
xtalkaddr: 0x23241c
vaddr: 0x920000000d23241c
epc: 0xc00000000043e204
ef: 0xa800000000b93c38
(NOTE: CPU 0=/hw/module/001c01/node/cpubus/0/a)
kl_ioerror_handler Failed handling PIO Read error in kernel mode
widgetnum: 0xd
srccpu: 0x0
srcnode: 0x0
errnode: 0x0
sysioaddr: 0xd23241c
xtalkaddr: 0x23241c
vaddr: 0x920000000d23241c
epc: 0xc00000000043e204
ef: 0xa800000000b93c38
(NOTE: CPU 0=/hw/module/001c01/node/cpubus/0/a)
junkbus: PPP error (len=5), PPP:bad FCS (checksum)
HARDWARE ERROR STATE:
junkbus: PPP error (len=2), PPP:short read/frame
I restarted and started the installation again:
chunk 10
rst text displayed on the mini-root to the visual login window)
SCSI2SD: 44 seconds
Fujitsu: 51 seconds
Test 2: Firefox loading (from open command to complete rendering of www.google.com )
SCSI2SD: 37 seconds
Fujitsu: 52 seconds
Note: Tests 1 and 2 are obviously read-heavy (avoiding the SCSI2SD's greatest flaw according to diskperf), but I still did not expect it to do so well based on the at best neck and neck read performance from the diskperf tests.
Test 3A/B: tar and untar a large set of files of varying, but mostly small, size (I used /usr/nekoware on the tested system, test tar was ~489MB. I did not/not use the verbose option)
3A: Archive
SCSI2SD: 6 minutes, 10 seconds
Fujitsu: 3 minutes, 54 seconds
3B: Extract
SCSI2SD: 11 minutes, 24 seconds
Fujitsu: 4 minutes, 43 seconds
chunk 10
le). This sounds like it could be related to formatting options, sector size, but my experimentation so far was unsuccessful etc.
Thanks.
--- Post by flexion ---
liquidkoshman said:
Can you please elaborate on the sector size? When I see any error messages in the ZuluSCSI log it's usually related to incorrect disk geometry - sectors x cylinders (default 63 x 255) don't agree with detected size (size not divisible). This sounds like it could be related to formatting options, sector size, but my experimentation so far was unsuccessful etc.
Thanks.
Click to expand...
I cloned my Indy image from an existing IRIX 5.3 installation which was formatted using 512 sector size instead of default 4096, because it wasn't a huge disk. You could try and name the image file "HD1_512.img" to force sector count and see if it still complains about geometry.
--- Post by liquidkoshman ---
Me again... so my issue is still unresolved but I since purchased a 73GB SCSI HDD with an adapter that works fine and I'm just using the ZuluSCSI to emulate the CDROM.
chunk 10
an be found in many SGI machines including the Octane. It's a very capable fan and balances things well with only 35dB of sound. It generally strikes a solid balance between noise and functionality.
In the case of an Indigo2 with Max IMPACT boards, you're going to likely need a bit more airflow. In fact, I'd argue that there's really no way to run a Max IMPACT set with TRAMs if you don't have better airflow. Not if you don't want eventual heat-related failures to crop up. That's why this is so important. Fixing the failed joints from overheating and warped PCBs is only half the issue. Airflow must be addressed to avoid similar issues from cropping up again.
One of the biggest issues with trying to replace the stock fans on SGI systems is the fact that they utilize two-pin connectors and in general this greatly limits options. You have to be accepting of either two-pin fans that fit what you're looking for or that any four-pin fans are going to run at max blast due to the computer not having any way of controlling PWM fans. Until now.
is not needed to measure them. Not even the CPU.
I traced the 3.3V and 5V rails on the MB to the CPU connectors, and powered on the bare CPU module (without MB and CPU) with a lab power supply:
Powered on the board, then measured SysAD[31:0] directly on the CPU pads (well, the vias next to them, so I don't affect the gold plating on the pads) according to the datasheet:
Sure enough, the SysAD bits are set! And they are set by the FPGA, so the CRIME really has nothing to do with the CPU configuration via SysAD. R5k/7k configure themselves via PROM, R10k is configured by the FPGA through the SysAD bus (Note: Some R10k modules use the newer carrier with ASIC, same as the R12k modules), R12k is configured with hardware straps on the SysAD bus . CRIME never actually does this.
This is how the the SysAD bus is configured:
SysAD[31:0] 00001010000100011000101000000100
Decoding this according to the R10k documentation, results in this:
SysAD[2:0] — Kseg0CA = 100b (value 4)
kseg0 cache algorithm: Cacheable coherent exclusive.
SysAD[4:3] — DevNum = 00b (value 0)
Processor device number: 0.
SysAD5 — (target of coherent processor requests)
chunk 11
'll still have to do allot of optimising once I fit the CD-ROM bezel: (What a mess this was!!!)
--- Post by Irinikus ---
I've now rebuilt the rear panel, so I'm almost done with this piece for now!
--- Post by Irinikus ---
I've made a small start on the CD-ROM Bezel:
--- Post by Irinikus ---
I've now made a start on the "lid":
--- Post by Irinikus ---
Here's a perspective rendering:
--- Post by KayBee ---
So glad this project is a bee in your bonnet, its a noble act of preservation.
--- Post by Irinikus ---
Thanks man!
I get to it when I can!
--- Post by Irinikus ---
I managed to get to this a little bit today:
--- Post by Irinikus ---
The lid is now complete: (The lid along with the CD-ROM bezel will be more manually tessellated and smoothed once I've finished with the base!)
--- Post by Irinikus ---
I've just imported and scaled the base of the machine!
--- Post by Irinikus ---
Some more shots showing how the parts fit together: (I haven't touched the base as yet!)
--- Post by Irinikus ---
I've just taken a quick look at the base to work on a strategy as to how I'm going to go about cleaning it up!
Here's a shot before I started working on it:
chunk 11
omfortable with...
forums.sgi.sh
The R5K boot time mode strings interest me from the perspective of verifying them against a data sheet to verify the RM7000C byte flipping
--- Post by sdz ---
I will dump the R5K PROM (180MHz, 512kB) really soon (maybe in a day or two). Almost finished designing the PROM emulator and I will need to validate some things on the O2 before ordering the boards (which will involve sniffing the PROM while the system starts.
--- Post by ruckusman ---
The actual pathway of that boot time mode string is a bit mysterious - not sure if it travels from that Xylinx PROM chip to the Crime chip then to the CPU itself, I thought I need to know that to decrypt it, till I figured out the byte flipping (swizzling).
--- Post by sdz ---
CRIME reads the Xilinx PROM, straps the SysAd bus accordingly and pulls the CPU out of reset.
On the PROM-less modules there are resistors straps on the bus.
Edit: Just so I don't spread misinformation. CPU mode bits are set like this:
On R5k/R7k modules, the CPU clocks a serial PROM (present on the CPU module) and reads it to configure itself.
chunk 11
ference , and that these components, which are surface-mount ferrite bead inductors, can and do slightly affect signal timings. While those differences are small, they can and do matter in practice.
The Pico-based BlueSCSI V2 was publicly announced, to much adulation and fanfare, around seven weeks after we began sales of the original ZuluSCSI RP2040, in late 2022. This is not a simple coincidence.
Since the initial fork, the BlueSCSI V2 team has certainly added other useful features, some of which we have chosen to merge into the ZuluSCSI code base. Multiple third parties have privately and independently chosen to share with me that this decision, which is our right under the GPLv3, infuriated BlueSCSI project leads. Hypocritical much?
chunk 11
y will you have to replace components you'll likely have to separate the old stabilizer. I replace the stabilizer with a 3M product design designed for the same purpose but using different chemicals. That radically increase my time and costs but there's a reason the stabilizer was used, as some of the components are incredibly top-heavy, a few coils especially, and so moving the system around or putting it on its side and potentially jarring it could actually cause part damage inside the power supply. So after load testing and then bench testing I batch up about 4 to 5 power supplies at once and open a new tube and start gooping up all the same locations for the same reasons.
Good luck.
--- Post by Geoman ---
I just acquired an Indy, that had exactly the same symptoms, as stated by @trembl . The magic smoked escaped elsewhere: (see attached Image)
The PSU still works, the machine powers on, recommends me to change a "faulty system board" (impressive, that Indy feels its 'pain'!). So I quickly powered it down. Next step: replace the cap on the planar and recap the PSU.
chunk 11
but plugged in.
--- Post by Elf ---
I put in a bit of work today to solve the last remaining Indy PSU mystery: the temperature sensor. It is not quite what I thought before, but not far off either.
Part numbers and analysis come from a sample of one CPU, SGI P/N 030-8201-001. The temperature sensor itself is a glass package (looks like a diode w/out a band marking) NTC thermistor labelled "U1" residing on the Indy CPU module. The thermistor is involved in a voltage divider bridge feeding a set of opamps (LM358AN, U6) which, minus a few capacitors (used for stabilizing the output), looks like:
The output of of U6:1 feeds through the top (closest to board edge) CPU connector on the 3rd pin from the left of the "41" marking, then goes through the motherboard directly to the "Temp" pin (2) on the Aux connector to the power supply. This outputs what is essentially a 0-5V signal that controls fan speed.
I was able to quantify this with some testing. First, of the temperature sensor itself and then of the output of the circuit, using hot air and a thermocouple probe:
Indy CPU temperature sensor characteristics:
chunk 11
hope-
fully detect the other bricks.
The fact that you have an O350 4x1ghz means also that your setup is not 20 years old - that very machine was released around 2004.
Click to expand...
It's possible that it was upgraded on 2004 - at that time it was totally managed by a vendor.
--- Post by CiaoTime ---
Odd indeed! The L1 controller on c02 is able to see the hardware configuration of c04, c08, and c10 - but then it reports that NUMAlink is down during the normal boot process? That seems like an oxymoron at first glance...
The warnings during the hardware inventory process are nothing to worry about: these systems autoconfigure themselves when they're all set up properly, and those messages are just saying that the current configuration differs from the last known configuration.
Would it be possible to get a picture of the back of the system? I'm curious to see if everything's wired up correctly -- though I do imagine it must be, if only the power setup was altered.
chunk 11
rd? It has a thing that looks like a coin cell battery but is most definitely not a coin cell battery?
The small fan that failed before must've been the ASIC HEART fan, explains your XBOW failure.
I thought Ian told me this, he can certainly correct me if I'm wrong, that if you're using one of the Acard SATA to SCA 80 SE/LVD Ultra160 SCSI bridges that is the full aluminum enclosure that's the size of a normal low-profile 3.5" hard drive that you shove in, that those have a tendency to fail if you force them to run single ended versus on an LVD system. So if the drive never comes back up, that may be the case. It could also be a 5 V power supply issue as hard drives tend to use that voltage quite a bit.
While there could be any number of reasons the keyboard isn't seen, you may be fighting with the power supply issue. I only mention this because the keyboard PS/2 interface should be driven directly off the 5 V power supply line.
chunk 11
us/0/a)
junkbus: PPP error (len=5), PPP:bad FCS (checksum)
HARDWARE ERROR STATE:
junkbus: PPP error (len=2), PPP:short read/frame
I restarted and started the installation again:
Code:
Setting $netaddr to 10.2.0.12 (from server 10.2.0.1)
Setting $netaddr to 10.2.0.12 (from server 10.2.0.1)
Setting $netaddr to 10.2.0.12 (from server 10.2.0.1)
It appears that a miniroot install failed. Either the system is
misconfigured or a previous installation failed.
If you think the miniroot is still valid, you may continue booting
using the current miniroot image. If you are unsure about the
current state of the miniroot, you can reload a new miniroot image.
You may abort the installation and return to the menu, or you can
fix (reset to normal) the miniroot install state
See the 'Software Installation Guide' chapter on Troubleshooting for
more information
Enter 'c' to continue booting the old miniroot with no state fixup.
Enter 'f' to fix miniroot install state, and try again
Enter 'r' to reload the miniroot.
Enter 'a' to abort (cancel) the installation.
Enter your selection and press ENTER (c, f, r, or a) f
chunk 11
t/not use the verbose option)
3A: Archive
SCSI2SD: 6 minutes, 10 seconds
Fujitsu: 3 minutes, 54 seconds
3B: Extract
SCSI2SD: 11 minutes, 24 seconds
Fujitsu: 4 minutes, 43 seconds
After seeing this data, I will continue to use my SCSI2SD as my "everyday" Indy drive. It performs better than a spinning disk in the tasks I perform the most often, uses much less power, and is quieter. However, if your workload includes many operations with large sets of files, a conventional disk may be considerably faster (but then, why on earth are you using a device with only a Fast SCSI bus?).
More on my SCSI2SD config:
Firmware 6.2.1, excerpts from my config. xml (My full SCSI2SD config xml file is available on my github )
Code:
<parity>true</parity>
<enableScsi2>true</enableScsi2>
<selLatch>true</selLatch>
<startupDelay>6</startupDelay>
<scsiSpeed>0</scsiSpeed>
Note that I did not/not try a newer firmware version primarily because it was a giant pain to get the SCSI2SD working with my Indy originally, so I do not want to risk messing anything up.
chunk 11
--- Post by liquidkoshman ---
Me again... so my issue is still unresolved but I since purchased a 73GB SCSI HDD with an adapter that works fine and I'm just using the ZuluSCSI to emulate the CDROM.
I previously successfully installed IRIX 6.2 to the HDD by first installing ZuluSCSI mounted CD1, quitting, mounting CD2 in its place and restarting the installation - this is needed because ZuluSCSI has no way to eject and switch CD images mid-install.
Buuuut 6.5 doesn't allow this anymore as it needs to read all install CDs first in one go before installation starts - without ejecting this is not possible on a ZuluSCSI.
I was thinking I can use admin within inst, manually mount all 3/4 CDs in their respective folders and point at these folders when reading each CD. Is that possible? Or do all CD images have to be read from exactly the same mounted location?
Thanks.
--- Post by flexion ---
liquidkoshman said:
I was thinking I can use admin within inst, manually mount all 3/4 CDs in their respective folders and point at these folders when reading each CD. Is that possible? Or do all CD images have to be read from exactly the same mounted location?
Thanks.
chunk 11
e accepting of either two-pin fans that fit what you're looking for or that any four-pin fans are going to run at max blast due to the computer not having any way of controlling PWM fans. Until now.
Enter the Coolerguys 12v PWM fan thermostat control board. While searching for fan options I took a look to see if there was any easy way to control fan speed without built-in PWM. This module ended up being exactly what I needed to get the perfect combo of a better fan and reduced noise. It's extremely small and fits inside the front plane frame near the power button.
You can see the module adhered via Velcro to the inside of the frame. It plugs into the fan port on the PCB while allowing the fan to plug into it.
A closer shot showing how things are wired up. I directly soldered the fan to the pin on the PWM controller since the fan I ordered was bare-leaded.
And for the best part: a thermostat that constantly reads the temperature inside the system, adjusting the power of the fan as needed to ensure cooling is kept to the right level.
chunk 12
block write-reissue
2
5. TmrIntEn
0. Timer Interrupt Enabled (default)
1. Timer Interrupt Disabled
0
6. Secondary cache present
0. Not Present
1. Present (default)
1
7. DrvOut
0. 67%
1. 50% (slowest)
2. 100% (default)
3. 83%
2
8. Secondary cache RAM type
0. Dual Cycle Deselect SRAMs (default)
1. Single Cycle Deselect SRAMs
0
9. User configuration identifiers (Config[21..20])
0. 00 (512K SCACHE)
1. 01 (1MB SCACHE) (default)
2. 10 (2MB SCACHE)
3. 11 (4MB SCACHE)
1
10. Multiply mode (bit20)
0. Integer Multiplier (default)
1. Half-integer Multiplier
1
[PROM] RM5271 custom bitstream saved.
========================================
O2 CPU PROM EMULATOR FW. REV. A00
CPU: RM5271
Bitstream Profile: custom
Bitstream settings: WriteBackRate: DDDD, Multiplier: x3.5, Endianness: BE, pipelined non-block writes, TmrIntEn: ON, Secondary cache: ON, DRVOut: 100%, SRAM type: Dual Cycle Deselect SRAMs, UserCfgID: 01, Mult mode: half-integer
Bitstream: 256 bits
Mode: Polled (all sends)
Type 'setup' + Enter for setup menu
Type 'status' + Enter for status
Type 'info' + Enter for info
Type 'boot' + Enter for USB bootloader
Type 'reboot' + Enter to reboot MCU
base as yet!)
--- Post by Irinikus ---
I've just taken a quick look at the base to work on a strategy as to how I'm going to go about cleaning it up!
Here's a shot before I started working on it:
--- Post by jenna64bit ---
Getting close! I'm excited to order a print of this after moving destroys my O2.
--- Post by mgtremaine ---
Lol... Soon it will be "I looked at my o2 and some plastic feel off..."
--- Post by Dodoid ---
This is really nice! I always wanted to fix up that O2 model myself and never got around to it. I'm rather close to having a relatively high-quality relatively large 3D printer, but it would be (good) FDM, not SLS as you want. It could probably handle these. Do you plan to release the model? I imagine plenty of people would want to print replacements.
--- Post by Irinikus ---
I do plan to release the model, it's just a bit hot down here in South Africa (Mid summer), so I'll jet back on it once things start to cool down here a bit!
--- Post by Dodoid ---
Nice! I have that 3D printer now, btw - if you want anything test-printed and test-fitted to one of my O2s (though I've been quite lucky with the skins on mine) I'd be happy to try them.
chunk 12
he bus.
Edit: Just so I don't spread misinformation. CPU mode bits are set like this:
On R5k/R7k modules, the CPU clocks a serial PROM (present on the CPU module) and reads it to configure itself.
On R10k/12k, the CPU can't configure itself via serial PROM. It needs to have the SysAD bus strapped externally. There are two main revisions of the carrier board:
-older revision with an FPGA. There is a PROM IC on this board, attached to the FPGA. This PROM holds the FPGA bitstream. Inside the FPGA bitstream there's also the SysAD (mode bits) config, that the FPGA sets on the bus.
-newer revision with ASIC. No PROM on this board. SysAD (mode bits) configuration is set by resistor straps.
CRIME 1.5 spec says that CRIME is responsable of strapping the bus. That is incorrect. CRIME never configures mode bits on any of the CPU modules (R5k/7k/10k/12k), it also doesn't read any serial PROM on the CPU module.
--- Post by sdz ---
ruckusman said:
I got the AT17LV65A.bin from discord - I mistakenly thought it was hosted on the sgidepot site - seems not - it won't allow me to upload the binary file, will forward to you on discord
Good thread here
chunk 12
de base. Multiple third parties have privately and independently chosen to share with me that this decision, which is our right under the GPLv3, infuriated BlueSCSI project leads. Hypocritical much?
Because the ZuluSCSI firmware was built around a subset of the existing SCSI2SD firmware (command-handling code), which was GPLv3 licensed, the ZuluSCSI firmware was, as required by the license, also released under the GPLv3. A common argument I've seen tossed around by people with little to no understanding of how the mechanics of many open-source licenses work is "well if you didn't want other people to use it, you shouldn't have released it as open-source software" but I personally find that to be an amusingly oversimplified analysis, and one which arguably borders on being intellectually lazy.
chunk 12
I quickly powered it down. Next step: replace the cap on the planar and recap the PSU.
chunk 12
sting. First, of the temperature sensor itself and then of the output of the circuit, using hot air and a thermocouple probe:
Indy CPU temperature sensor characteristics:
As you can see, maximum output is reached around 180F (82C), and minimum around 60F (15.5C), from the motherboard to the power supply. All in all, that is a fairly sensible range for a control signal used in setting fan speeds.
What the power supplies do with it, though, is a little different between Nidec and Sony. The next test consists of feeding a control voltage in from a lab power supply to both types of PSUs to see what they do with the fan.
Sony under test:
Neither one provides a PWM signal to the fan; both vary the DC voltage supplied to the fan to set its speed. The fan intakes air from the Indy through the side of the power supply and blows it out the rear of the power supply near the area where AC line power comes in.
The difference between the Nidec and Sony fan control inside the power supply (both of which receive the same control signal voltage from the motherboard) is quite substantial.
chunk 12
ation.
Would it be possible to get a picture of the back of the system? I'm curious to see if everything's wired up correctly -- though I do imagine it must be, if only the power setup was altered.
--- Post by Unxmaal ---
From my own bitter experience, I'll recommend that you completely disconnect the NUMALINK cables, then very carefully reconnect them. They can appear to be connected, but are in fact not properly seated. Get a flashlight, get up close, and compare the distances from the metal connector housings to the plastic NUMALINK connectors once plugged in. It should be even all the way across. You should also see green and amber lights on the left side of the connectors.
--- Post by weblacky ---
Nondem,
Ciaotime’s first response was actually the critical one, and perhaps you misunderstood it. Later SGIs have this mini embedded system call the L1, in clusters like yours those mini systems in each brick are controlled by a device in your rack (or a laptop with software) called the L2. All this has nothing to do with Irix.
chunk 12
of reasons the keyboard isn't seen, you may be fighting with the power supply issue. I only mention this because the keyboard PS/2 interface should be driven directly off the 5 V power supply line.
PS/2 peripherals have a pretty rigid voltage requirement, so you could actually have a failing power supply which would certainly be expected of a system this old. Slightly low voltage or increased ripple from poor filtering from failing capacitors in the power supply could be causing peripheral malfunction.
--- Post by 3DChris ---
Thanks for your detailed analysis of the situation!
I did move the System ID over from my old Xbow board to the new one. The old one did have a fan failure, I'm sure, as the new one is definitely "louder" when I turn on the system. I'm not sure how long the old one wasn't working for, but I think it might have been for a while.
The 5v issue you're referring to might be the culprit for both the Acard SATA sled AND the keyboard. I don't really know what you mean by "single ended vs LVD system" though.
chunk 12
xup.
Enter 'f' to fix miniroot install state, and try again
Enter 'r' to reload the miniroot.
Enter 'a' to abort (cancel) the installation.
Enter your selection and press ENTER (c, f, r, or a) f
miniroot install state reset to normal
Copying installation program to disk.
Setting $netaddr to 10.2.0.12 (from server 10.2.0.1)
......... 10% ......... 20% ......... 30% ......... 40% ......... 50%
......... 60% ......... 70% ......... 80% ......... 90% ......... 100%
Copy complete
Setting $netaddr to 10.2.0.12 (from server 10.2.0.1)
Setting $netaddr to 10.2.0.12 (from server 10.2.0.1)
IRIX Release 6.5 IP35 Version 07141608 System V - 64 Bit
Copyright 1987-2003 Silicon Graphics, Inc.
All Rights Reserved.
QLFC: running as interrupt thread.
QLFC: using spinlocks.
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
chunk 12
eed>
Note that I did not/not try a newer firmware version primarily because it was a giant pain to get the SCSI2SD working with my Indy originally, so I do not want to risk messing anything up.
--- Post by nintendoeats ---
Thank you for running such a comprehensive suite of tests! They are certainly consistent with my experience; that running off the SCSI2SD is not noticeably slow. The one difference, I have successfully run my SCSI2SD with another device on the bus (though I cannot recall if it was with multiple devices on the internal connector).
--- Post by callahan ---
My Indy has been very particular. Initially the SCSI2SD wouldn't work at all ... After a bunch of troubleshooting I found that a 6 second startup delay somehow fixes the issue. There might be some odd timing issue with my SCSI2SD or Indy that causes compatibility problems. I've tried both known-good SGI OEM (IBM produced IIRC) 50 pin drives and known-good Fujitsu drives using the external and internal connectors with no luck. It's a limitation I've grown to live with.
--- Post by Elf ---
callahan said:
chunk 12
ount all 3/4 CDs in their respective folders and point at these folders when reading each CD. Is that possible? Or do all CD images have to be read from exactly the same mounted location?
Thanks.
Click to expand...
It's probably less complicated to perform an installation over network. Check out the new "all-in-one" IRIX installer tool called ' LOVE ', created by TruHobbyist. It combines services like tftp, bootp, rsh etc in a single binary to serve IRIX installation media over network.
And I would stick to Version 5.3 for an Indy.
--- Post by liquidkoshman ---
Cool, my approach seems to work, I'm over 80% of the 6.5 installation in (using Installations Tools, Foundation 1 & 2 and Applications).
What I did was:
1. boot into inst from Installations Tools CD, go to Admin, sh.
2. mkdir CDROM2, mkdir CDROM3, mkdir CDROM4
3. mount -o ro /dev/dsk/dks0d5s7 /CDROM2 (in my case Foundations 1 was the SCSI device 5); then do the same for device 6 & 7
4. exit, .. to go back to inst
5. press 1, Enter to read Installation Tools from the default /CDROM/dist location
chunk 12
bare-leaded.
And for the best part: a thermostat that constantly reads the temperature inside the system, adjusting the power of the fan as needed to ensure cooling is kept to the right level.
This little PWM controller is programmed to start ramping the fan slowly at 30 C until it hits maximum airflow at 40 C. There's a configurable idle speed so that the fan is always providing adequate cooling even when the machine is simply sitting. All of this is programmed directly on the board with a few LEDs and a button.
Now to the fan part. I ended up going with a Delta AFC0912D. This is a 92x25mm 12v fan rated for 1 amp. While it's rated for a higher power draw than the Panaflo, on testing it showed to pull no more than .7 amps. Additionally, it's hardly ever going to ramp up all the way based on using the PWM controller. Total airflow is rated for 103 CFM at 13.3mm of H2O. This of course assumes you're running the fan at full speed, to a hardly-quiet 53dB. (Even more of a reason to use a PWM controller)
chunk 13
e: Polled (all sends)
Type 'setup' + Enter for setup menu
Type 'status' + Enter for status
Type 'info' + Enter for info
Type 'boot' + Enter for USB bootloader
Type 'reboot' + Enter to reboot MCU
========================================
--- Post by sdz ---
Now tested with RM7000C.
Below is a config example for setting integer multiplier (SysClock to Pclock) at 7x, for running the CPU at 700MHz:
Code:
========================================
O2 CPU PROM EMULATOR FW. REV. A00
CPU: R5000
Bitstream Profile: default R5000 180/200MHz 1MB secondary cache
Bitstream: 256 bits
Mode: Polled (all sends)
Type 'setup' + Enter for setup menu
Type 'status' + Enter for status
Type 'info' + Enter for info
Type 'boot' + Enter for USB bootloader
Type 'reboot' + Enter to reboot MCU
========================================
setup
1. R5000
2. RM5271
3. RM7000
4. RM7000A
5. RM7000B
6. RM7000C
7. RM7900 (RM7965 Mode bits)
8. SR71010A
6
1. default RM7000C 500MHz tertiary cache off
2. default RM7000C 500MHz tertiary cache on
3. default RM7000C 600MHz tertiary cache off
4. default RM7000C 600MHz tertiary cache on
5. custom
5
[PROM] RM7000C custom bitstream not set
chunk 13
000b
Reserved: 0.
SysAD[28:25] — SCCIkTap = 0101b (value 5)
Meaning: value 5 -> SCCIk 5/12 of a PCIk period earlier than the internal clock (alignment tap).
SysAD29 — Reserved = 0
Reserved: 0.
SysAD30 — ODrainSys
Value 0 : Push-pull (not open-drain) for system interface bidirectional/output signals.
SysAD31 — CTM
Value 0 : Cache test mode disabled.
This all makes sense, just the PClk = SysClk × 3 is a a bit strange. If the CPU clock is set at 150MHz, this would mean that the SysAD bus runs at only 50MHz.
Clock generation is done directly on the CPU module, so I can use the earlier setup to directly measure the CPU SysClk pin, A22. Sure enough, it is 50MHz:
Which means that:
-CPU runs at 150MHz
-external cache runs at 100MHz
-SysAD bus runs at 50MHz
To be continued (maybe).
--- Post by sdz ---
4. RM5271 300MHz 1MB
Raw bitstream:
0000010010101010100000000000000001000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Meaning:
Bit 0 - reserved
bit0 = 0
chunk 13
Dodoid ---
Nice! I have that 3D printer now, btw - if you want anything test-printed and test-fitted to one of my O2s (though I've been quite lucky with the skins on mine) I'd be happy to try them.
--- Post by joshyfishy22 ---
Hey Irinikus, How are the 3d models going? I would love to print myself a new set of skins for my poor naked o2.
--- Post by Irinikus ---
I'll continue with the model in the next month or so, when things cool down over here a bit.
It gets very warm over here in the summer months, and therefore pretty uncomfortable to sit in front of a computer for long periods of time!
--- Post by Irinikus ---
Today I worked on this model for the first time in ages!
The base is going to take quite a while to complete as it's pretty messed up!
Here's how the model looked when I started working on it:
--- Post by Irinikus ---
I managed to get to this model a little bit more today!
Here's how the front of the base originally looked:
--- Post by Irinikus ---
Here's what the front of the base currently looks like when rendered with texture using ray-traced rendering:
chunk 13
A.bin from discord - I mistakenly thought it was hosted on the sgidepot site - seems not - it won't allow me to upload the binary file, will forward to you on discord
Good thread here
The SGI O2 600MHz R7K mod in 2024
It's been a long time comin'! Since getting my O2, I've had the plan to try and fit it with the 600MHz R7K CPU through a BGA swap on a 300MHz R5K card. It's been a couple of years now, but I've finally made the move to BGA soldering in the last few months, and after getting comfortable with...
forums.sgi.sh
The R5K boot time mode strings interest me from the perspective of verifying them against a data sheet to verify the RM7000C byte flipping
Click to expand...
R5K 180MHz 512kB PROM dump available here: https://forums.sgi.sh/index.php?threads/o2-cpu-modules-prom-dumps-and-analysis.1502/
--- Post by sdz ---
Board #3:
Got this board a few days ago as part of a very sorry looking system, supposedly broken (blinking amber light). After reseating everything, it worked, there was nothing wrong with it. Until I killed it just now.
chunk 13
to use it, you shouldn't have released it as open-source software" but I personally find that to be an amusingly oversimplified analysis, and one which arguably borders on being intellectually lazy.
BlueSCSI Pico/V2 costs less because they are manufacturing and selling JLC-manufactured and assembled boards, and do not have to incur the actual development costs, because we do that for them. Additionally, the two core BlueSCSI maintainers directly receive remittances/royalties for every assembled and kit BlueSCSI sold through their approved "makers" (AKA resellers). They are running a business, have registered business LLC entities, and yet have repeatedly claimed it's "not for profit", simply because their hardware designs are also open source.
Since November of 2023, nearly two years ago, an OSHW-licensed ZuluSCSI Pico hardware design , released under the OSHWA-approved CERN OHL-Strict V2 license, has been publicly available. This is an Open Source Hardware Alliance-certified design . The original BlueSCSI Pico/V2 hardware design explicitly prevented commercial use by non-approved third parties.
chunk 13
power comes in.
The difference between the Nidec and Sony fan control inside the power supply (both of which receive the same control signal voltage from the motherboard) is quite substantial.
The Nidec acts linearly, with the fan spinning slowly even at 0V of control signal (60F, 15.5C) and ramping up to maximum speed at 5V of control signal (180F, 82.5C) which puts the fan at 11.87V maximum.
The Sony does not act linearly, with a 3rd order polynomial fit shown on graph. The voltage output by the Sony fan controller does not allow it enough torque to start spinning at all -- and only minimally -- until 2.17V of control signal, or in other words 113.1F / 45C in the vicinity of the CPU! It will need to be much hotter than that (e.g. 145F / 62.8C) before the fan really starts to blow. Interestingly the Sony fan has a higher maximum voltage, with a 5V control signal topping out at 15.76V to the fan, which at that point is going pretty fast.
chunk 13
d system call the L1, in clusters like yours those mini systems in each brick are controlled by a device in your rack (or a laptop with software) called the L2. All this has nothing to do with Irix.
CiaoTime said under normal circumstances, when you power cycle and boot, only one CPU brick out of groups of up to four will power on, the rest will seem to remain unpowered. You need to use the L1 in the CPU brick that did power up (or I think the L2 controller, someone please look into that for me, I may be wrong). To perform the power up command to bring the remaining bricks online correctly.
The reason you’re getting the errors has to do with serial numbers. All clusters have a serial number layout and remember their former numbers via the L2. The units loose these numbers when powered down. The L2 helps organize and restore these numbers in each brick as it’s booting and puts them back in a single system image cluster.
When you tried to manually power them on, they booted without L2 control, never got a serial number and were rejected by the startup process as unknown bricks.
chunk 13
have been for a while.
The 5v issue you're referring to might be the culprit for both the Acard SATA sled AND the keyboard. I don't really know what you mean by "single ended vs LVD system" though.
I replaced the original power supply years ago with a Cherokee branded 747W one with silver handle. This was mostly because I had upgraded my system to Dual 600 and V12 and needed the extra power.
I really didn't put many hours into the system since I replaced that supply. Maybe only a week's worth of actual use here and there. Do they fail even while not in use? Maybe needs a recap?... Anyone got a spare?
The super slow power up might also be explained by this PSU failure if the rails aren't energizing quickly enough due to failing or aging components.
--- Post by weblacky ---
I'll quickly summarize why you should care.
chunk 13
NING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
NOTICE: pcibr_attach: /hw/module/001c01/Ibrick/xtalk/15/pci Bus holds a usb part - settingbridge PCI_RETRY_HLD to 4
Setting hub ixtt.rrsp_ps field to 0x4e20
Selecting SN11
root on /hw/module/001c01/Ibrick/xtalk/15/pci/1/scsi_ctlr/0/target/1/lun/0/disk/partition/1/block ; dumpdev on /dev/swap ; boot swap file on /dev/swap swplo 0
WARNING: Cannot load runtime symbol table from bootp'ed kernel.
Loadable modules will not be registered or loaded.
Creating miniroot devices, please wait...
chunk 13
RC) 50 pin drives and known-good Fujitsu drives using the external and internal connectors with no luck. It's a limitation I've grown to live with.
--- Post by Elf ---
callahan said:
After further tests, I've found that SCSI2SD v6's max performance is slower than a high-end 10,000RPM SCSI drive, but it still often outperforms such drives in normal usage.
Click to expand...
A very thorough examination, thank you!
I wonder why the SCSI2SD suffers in sequential read performance? It seems like it shouldn't be the case...
--- Post by nintendoeats ---
Elf said:
I wonder why the SCSI2SD suffers in sequential read performance? It seems like it shouldn't be the case...
Click to expand...
I wish it was easier to seperate the SCSI2SD from the controller on the SD card. I speculate that it has more to do with the card than the SCSI2SD bridge, since I would think that from the bridge's perspective there is no difference between random and sequential reads/writes.
--- Post by callahan ---
Yeah, my results are definitely slower than @nintendoeats . Could be slightly older firmware or a slower-performing SD card.
chunk 13
in my case Foundations 1 was the SCSI device 5); then do the same for device 6 & 7
4. exit, .. to go back to inst
5. press 1, Enter to read Installation Tools from the default /CDROM/dist location
6. then write in /CDROM2/dist, Enter etc. to finish reading all 4 CDs (it seems the sequence of writing these in matters - the CD that has to be read first should be the lowest in the list, read in first)
7. press 5 to be Done and go back to inst
8. keep *, Enter, install standard, Enter, install prereqs, Enter (prereqs gives an error which is known and ok apparently)
9. go
Done. This was actually quite easy and logical in the end. Maybe this will be useful to somebody
Don't forget CDs have to be mounted with the ro flag (read only) otherwise it fails.
If you are using a disk that had IRIX previously installed on it for whatever reason it is always safer to format (mkfs) the disk first - the contents of the disk may prevent a successful installation!
chunk 13
controller. Total airflow is rated for 103 CFM at 13.3mm of H2O. This of course assumes you're running the fan at full speed, to a hardly-quiet 53dB. (Even more of a reason to use a PWM controller)
With this fan combo set to run at around 60% speed on boot, ramping up to around 70% once the boards get warm, the noise increase is definitely there. But it is no where near the full 53dB and is very tolerable. I will say that this mod requires accepting that either you stick with the stock fan and leave things as they are, or you bite the bullet and realize that a little more noise is helping ensure better cooling overall.
After running this setup for five hours with multiple texture and alpha demos going (to help verify TRAM functions) the outlet air stabilized at around 92 F (33C) and was definitely noticeable when coming near the side of the machine. A lot more air was moving through the chassis and it was easy enough to tell without having to use any measurement devices.
chunk 14
iary cache off
2. default RM7000C 500MHz tertiary cache on
3. default RM7000C 600MHz tertiary cache off
4. default RM7000C 600MHz tertiary cache on
5. custom
5
[PROM] RM7000C custom bitstream not set
1. Write-back data rate
0. DDDD (default)
1. DDxDDx
2. DDxxDDxx
3. DxDxDxDx
4. DDxxxDDxxx
5. DDxxxxDDxxxx
6. DxxDxxDxxDxx
7. DDxxxxxxDDxxxxxx
8. DxxxDxxxDxxxDxxx
0
2. SysClock to Pclock Multiplier
0. Multiply by 2/x
1. Multiply by 3/x
2. Multiply by 4/x
3. Multiply by 5/2.5
4. Multiply by 6/x (default)
5. Multiply by 7/3.5
6. Multiply by 8/x
7. Multiply by 9/4.5
5
3. EndBit
0. little-endian
1. big-endian (default)
1
4. Non-block write control
0. R4000 compatible non-block writes
2. pipelined non-block writes (default)
3. non-block write re-issue
2
5. Timer Interrupt Enable/Disable
0. Enable timer interrupt on IP[5] (default)
1. Disable timer interrupt on IP[5]
0
6. External tertiary cache
0. Disable
1. Enable (default)
1
7. Output driver strength
0. 67% strength
1. 50% strength (slowest)
2. 100% strength (default)
3. 83% strength
2
8. External tertiary cache RAM type
0. Dual-cycle deselect (DCD) (default)
1. Single-cycle deselect (SCD)
0
chunk 14
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Meaning:
Bit 0 - reserved
bit0 = 0
Bits [4:1] — 64-bit Write-back data rate
bits[4:1] = 0000b = 0
Meaning: DDDD (no interleaving)
Bits [7:5] — SysCkRatio (PClock = SysClock × multiplier)
bits[7:5] = 001b = 0
Meaning: Multiply by 3
Bit 8 — EndBit (endianness, OR’d with BigEndian pin)
bit8 = 1
Meaning: Big-endian (OR'd with the BigEndian pin)
Bits [10:9] Non-Block Write: Determines how non-block writes are handled.
bits[10:9] = 10b = 2
Meaning: Pipelined non-block write
Bit 11 — TmrIntEn: Disables Timer Interrupt on Int*[5]
bit11 = 0
Meaning: Timer interrupt enabled
Bit 12 — Secondary cache present
bit12 = 1
Meaning: Secondary cache enabled
Bits [14:13] — DrvOut: Output driver slew rate control
bits[14:13] = 10b
Meaning: 100% drive strength
Bit 15 - Select secondary cache RAM type
bit15 = 0
Meaning: Dual Cycle Deselect SRAMs
Bits [17:16] — User configuration identifiers - software visible in processor Config[21..20] register
bits[17:16] = 01b
Meaning: see below
Bits [19:18] reserved, must be 0
chunk 14
re today!
Here's how the front of the base originally looked:
--- Post by Irinikus ---
Here's what the front of the base currently looks like when rendered with texture using ray-traced rendering:
--- Post by VisualCortexLab ---
Despite having been a SGI obsessed and collector for quite some time (about 2 decades, I was very active on NekoChan as "sum][one", "the guy with the Origin2000 that had a MGRAS card and CAD Duo installed in it" ) I've signed up to this forum only today, and the reason is to say Thank You for this incredible work on this O2 model you're working on!!
This is amazing!
Back in the days I had an O2 model given by a friend in the VFX community and been trying to 3D print that just to keep a nice little "toy" on my desk.
I would really love to 3D Print your model now!
Anyway, Thank you for the hard work and looking forward to seeing your progress.
Cheers!
--- Post by Irinikus ---
I managed to work on this model a bit today!
--- Post by Irinikus ---
Yes there is!
This is a picture of the original .stl model:
--- Post by Irinikus ---
I mad some more progress today:
chunk 14
d a few days ago as part of a very sorry looking system, supposedly broken (blinking amber light). After reseating everything, it worked, there was nothing wrong with it. Until I killed it just now.
I was using it to probe some signals, being a bit lazy, I did not disconnect the logic analyzer probes while trying to probe something with an oscilloscope. Result was that the 3.3V rail shorted to ground. System powered off by itself. Removed power, waited a bit, applied power and the system powered on.
However, all that I got was a solid amber light and exactly one newline over serial.
Checked all the power rails and they were fine, so were all the inductors on the board. CPU module was functioning OK in another system.
Removed the RAM, and I got a blinking amber light, which means that the PROM is executed and it actually detects that there is no RAM.
Did exactly what I did to MB#2, removed the flash IC and flashed it externally, and now the system is working again.
Though this might be interesting info, as at the moment a corrupt PROM is known to:
-give a solid amber light, regardless if RAM is present or not
chunk 14
been publicly available. This is an Open Source Hardware Alliance-certified design . The original BlueSCSI Pico/V2 hardware design explicitly prevented commercial use by non-approved third parties.
On September 9th, 2024, ~ten months after I chose to release a version of the ZuluSCSI hardware design under the aforementioned license, the BlueSCSI V2 team chose to follow suit, re-licensing their hardware designs from the original Creative Commons Non-Commercial-ShareAlike 4.0 ( CC BY-NC-SA 4.0 ) license to the same more-permissive CERN OHL-S V2 license that we'd previously chosen to use.
Finally, it's important to know that the ZuluSCSI firmware began life as a fork of the original BlueSCSI V1 firmware, which seems to have been what originally ticked off the BlueSCSI maintainer back in April of 2022. By his own admission, only ~30 lines of the original BlueSCSI V1 source code remained by the time we released the very first ZuluSCSI V1, which significantly outperformed the original BlueSCSI V1. One can only assume that this was seen as an existential threat.
chunk 14
C) before the fan really starts to blow. Interestingly the Sony fan has a higher maximum voltage, with a 5V control signal topping out at 15.76V to the fan, which at that point is going pretty fast.
This is almost certainly what leads to the myth that Sony Indy PSUs don't use their fan. I have even read one person say that the Sony PSU has no fan, which is visibly untrue. It just doesn't start moving any appreciable amount of air until your Indy is already way too hot! Why they designed it this way, and continued to produce them without fixing what seems like an obvious defect, is a mystery to me.
So there you have it; with that last mystery solved this should tell you all you need to know about Indy PSUs from an external perspective. I will likely not put any more time into reverse engineering them as I think a replacement is not only an easier, but also a much better choice. With the existing options, you can either have:
chunk 14
ack in a single system image cluster.
When you tried to manually power them on, they booted without L2 control, never got a serial number and were rejected by the startup process as unknown bricks.
What was asked was that you go back to the starting point where you power on the rack, see only 1 brick of several start. Go to the L1 of that brick and issue the power up command for the remaining bricks via the command stated earlier, then the main CPU brick will soft-power cycle the other bricks under control of the L2 and reestablish the cluster setup for you.
It sounds dumb that all this isn’t remembered, but it’s not. This process allows easier brick replacement and such. So I believe this is all based on where you were when you initially powered on the system.
You misstepped in the startup process of the other bricks and that’s why you had this error. Go back, use the proper commands to do the two stage power on and then let us know what happened.
I think this can be done from the L2 interface, but someone with my practical experience then me needs to take you through that.
chunk 14
up might also be explained by this PSU failure if the rails aren't energizing quickly enough due to failing or aging components.
--- Post by weblacky ---
I'll quickly summarize why you should care.
SE and LVD are the distinctive and very different ways that the SCSI parallel bus evolved over time in signalling/transferring data over the the ribbon cable. From the very beginning of SCSI-I up until ultra wide (UW - 40MB/s) was introduced use SINGLE ENDED MODE, which has HIGHER 5V TTL signalling voltage and uses a specific termination resistance on a SCSI bus. SE mode also has a single COMMON ground and a single signaling wire for each line. This means that the difference between a common ground and the signaling wires is how signal measurement takes place.
While every FASTER SCSI standard (Ulta160 & Ultra 320) uses LVD mode, which operates at 3.3 V and uses DIFFERENTIAL signaling which means that the signal and the inverse of the signal is put out over two lines that are intertwined, twisted, together to allow for vastly increase transfer speed, higher resistance to interference, and longer bus length.
chunk 14
boot swap file on /dev/swap swplo 0
WARNING: Cannot load runtime symbol table from bootp'ed kernel.
Loadable modules will not be registered or loaded.
Creating miniroot devices, please wait...
Current system date is Mon Jan 05 23:55:24 PST 2032
Mounting file systems:
/dev/dsk/realroot: Invalid argument
No valid file system found on: /dev/dsk/realroot
This is your system disk: without it we have nothing
on which to install software.
Make new file system on /dev/dsk/realroot [yes/no/sh/help]:
Again I got lots of "WARNING: odsy dfifo timeout" messages.
After multiple retries and restarts I was able to get IRIX installed. Sometimes even with the "odsy dfifo timeout" warnings it wouldn't crash the system.
Starting IRIX would usually crash. Sometimes I would get to login prompt before crash.
After multiple reboots I was able to get IRIX started.
I messed around IRIX a bit and was confident enough for it to not crash.
I flashed L1:
Code:
chunk 14
nce between random and sequential reads/writes.
--- Post by callahan ---
Yeah, my results are definitely slower than @nintendoeats . Could be slightly older firmware or a slower-performing SD card.
Also worth noting that sequential performance was substantially better than random performance, so it didn't suffer relative to itself (no surprise that the UW-160 spinny drive could saturate the Fast SCSI bus).
--- Post by nintendoeats ---
THE SAGA CONTINUES.
I'm installing IRIX 6.5 on an Indigo2 R4400/250. I didn't have any spare good SD cards, so I grabbed a random Lexar class 10 MicroSD. The installation has been running for 5 hours.
Clearly, the quality of your SD card is very important. Since it's past 11:00 and rqsall is still at 37%, diskperf will have to wait until tomorrow. Clearly I won't be using this installation very much, holy jimminy. I...have another SD card coming...
--- Post by nintendoeats ---
Boot time, measured from the end of "System is coming up" screen to the Toolchest appearing, is 6:11. Yeesh. This is on a completely default install.
chunk 14
C) and was definitely noticeable when coming near the side of the machine. A lot more air was moving through the chassis and it was easy enough to tell without having to use any measurement devices.
With that much airflow, I do recommend adjusting the rear IO plates. I took a rather drastic measure and drilled three holes in the IO shield, directly in front of where the second TRAM sits. I wanted to be sure cool air could pass over the heatsink. I also replaced the solid IO shield on the empty slot with a vented one to allow more compartment airflow.
So, if you've read all this and want to do the same or similar thing with your TRAMs and Max or High IMPACT, here's your shopping list!
* Fan: Delta AFC0912D-PWM (available from most PC modding web shops but out of stock at larger resellers as of Feb 2022). I picked mine up from FrozenCPU.
* PWM Controller: Coolerguys 12v PWM Fan Thermostat Controller. Available directly from their site.
* Fujipoly 17 W/mK TIM: I snagged mine from Amazon. Look for Fujipoly Ultra Extreme pads. They'll list 17 W/mK on the ones you need.
l Cycle Deselect SRAMs
Bits [17:16] — User configuration identifiers - software visible in processor Config[21..20] register
bits[17:16] = 01b
Meaning: see below
Bits [19:18] reserved, must be 0
Bit 20 Select SysClock to Pclock multiply mode
Bit 20 = 0b
Meaning: Integer multiplier
Bits 21–255 reserved, must be 0. However, bit 33 and 37 are set to 1.
Regarding mode bits [17:16], User configuration identifiers - software visible in processor Config[21..20] register.
Unlike the R5K, the secondary cache size can't be set via mode bits. The O2 system PROM appears to use Config[21:20] to determine secondary cache size.
Changing it results in the following behavior:
[17:16] Config[21..20]
00: system PROM reports 512kB secondary cache, filesystem errors during startup, panic, filesystem corruption
01: system PROM reports 1MB secondary cache. Irix boots with no issues and reports 1MB secondary cache. (default value)
10: system PROM reports 2MB secondary cache. Irix boots with no issues and reports 2MB secondary cache.
11: system PROM reports 0MB secondary cache. Irix boots with no issues and reports 4MB secondary cache.
chunk 15
ikus ---
I managed to work on this model a bit today!
--- Post by Irinikus ---
Yes there is!
This is a picture of the original .stl model:
--- Post by Irinikus ---
I mad some more progress today:
--- Post by Irinikus ---
This is a bit premature, as I'm nowhere near finished with the O2 model yet, but just wondered what it would look like in a scene with a doughnut and a coffee?
--- Post by Irinikus ---
It now has a cube logo, thanks to @flexion EZsetup!!!
--- Post by VisualCortexLab ---
ooooh man this is progressing so beautifully.
As recently I bought myself a new (bigger, faster) 3D printer I was wondering if you're going to make this model available for download somewhere?
I hope I'm not too greedy
Great work regardless!! Still following this thread with lots of interest (made me bring my O2 to the office so I can stare at it whilst most people wonder what that blue "thingy" is! )
--- Post by siliboi ---
Looks complete is it ?
--- Post by WMSGI ---
Incredible work and results!
chunk 15
externally, and now the system is working again.
Though this might be interesting info, as at the moment a corrupt PROM is known to:
-give a solid amber light, regardless if RAM is present or not
-give a solid amber light with RAM installed, blinking amber light without RAM installed, otherwise dead system.
--- Post by sdz ---
Board #4:
This one showed no signs of life whatsoever, it wouldn't even turn on the PSU, even though the bypass jumper was installed.
On the O2 MB, the power button on the frontplane is connected to the Dallas IC. If the Dallas IC is actually programmed, and the power button is pressed, the Dallas IC will turn on the power supply (it pulls a signal low, that goes from the Dallas IC, through the frontplane, to the PSU). The jumper, when installed, connects that signal directly to ground, thus forcing the PSU on regardless if the Dallas IC is programmed or even present.
There is nothing else going on with that signal, so it was a weird that the system would not turn on with the jumper installed. Here is the jumper next to the Dallas IC:
chunk 15
1 source code remained by the time we released the very first ZuluSCSI V1, which significantly outperformed the original BlueSCSI V1. One can only assume that this was seen as an existential threat.
BlueSCSI V2 has every right to exist, and end users have every right to use it, however they should do so with full awareness of who performed and financed the actual effort. The original BlueSCSI fork went out of its way to seemingly-intentionally obfuscate the true origins of the code , and only after they were publicly called out about it did they claim to have made "a bad merge which lost history" and restore the stripped attribution.
I've been loosely involved with and a fan of open-source software for nearly thirty years, and have used GPLv3-licensed software almost daily since the early 2000s.
Entender a relação entre esses projetos ajuda a evitar confusão, algo importante em qualquer área técnica ou até ao analisar um slot dinheiro real . Contexto e documentação fazem toda a diferença.
chunk 15
tive. I will likely not put any more time into reverse engineering them as I think a replacement is not only an easier, but also a much better choice. With the existing options, you can either have:
Nidec - An electrically noisy, extremely inefficient PSU that keeps the Indy cool, or...
Sony - A slightly more efficient, less noisy PSU that will cook the machine
While the Nidec is known for killing capacitors and diodes and the Sonys are supposedly reliable, more than one recent report (and an experience on my side) has the Sony PSUs dying with shorted switching MOSFETs which take out a lot of other components as well. Lots of folklore out there about the Indy PSUs and much of it untrue, it would seem!
--- Post by Elf ---
A bit of an addendum regarding the "Power Good" signal:
Nidec Pgood vs. loaded 5V rail:
Sony Pgood vs. loaded 5V rail:
Sony Pgood loaded w/ 680Ω vs. loaded 5V rail:
chunk 15
nds to do the two stage power on and then let us know what happened.
I think this can be done from the L2 interface, but someone with my practical experience then me needs to take you through that.
but that’s the reason you’re seeing what’s happening now. You need the main CPU brick to bring up the other bricks for you, don’t try to press the power buttons in them to manually start them. That’s incorrect cluster startup (as CiaoTime mentioned in thefirst response)
Good luck.
--- Post by CiaoTime ---
Ooh, yeah, I hadn't even considered that his setup might have an L2 controller. (It probably doesn't, though.) L2 on the Origin 350 was an optional item: it's an extra piece of hardware sitting on the outside of the chassis that you can connect into for total rack control over LAN or a master serial terminal.
It's usually used for -really- big racks. On a 4 brick system (which likely only has two CPU nodeboards), L2 is overkill; running a proper startup from L1 should be enough to get everything sorted out. L1 controllers can talk to eachother over NUMAlink: connecting to one CPU brick with a serial cable should be able to control all four.
chunk 15
nd the inverse of the signal is put out over two lines that are intertwined, twisted, together to allow for vastly increase transfer speed, higher resistance to interference, and longer bus length.
Why you should care about this is because you cannot mix the two. So when you put devices on a bus, chain, you need to decide on the fastest common communication method that all the devices support. This is the primary reason that a lot of controllers have a narrow 50 pin bus that you would place an optical drive on and perhaps a zip drive or something, and another chain for the hard drives that uses a much higher/faster standard.
All the devices on the bus must talk in the same standard, the slowest (by standard) device on the chain causes every device to lower to that standard. This is why once Ultra & Ultra Wide SCSI SE came out you don't ever put a hard drive and an optical drive on the same bus, it will simply cause a hard drive to go incredibly slow because the optical drive has to go that speed (by standard, not data transfer ability) and therefore the hard drive has to match that bus speed. You cannot mix and match, lowest common denominator on standard wins.
chunk 15
et to login prompt before crash.
After multiple reboots I was able to get IRIX started.
I messed around IRIX a bit and was confident enough for it to not crash.
I flashed L1:
Code:
IRIS 18# flashsc --sc l1.bin local
flashsc: (System Controller Flash Utility) - Version 1.0.7
============= Updating (local) =============
Checking current flash image status.
Updating L1 flash image A to version 1.22.2
Erasing existing flash data: 100% complete
Writing new flash image: 100% complete
Validating new flash image.
IRIS 19# l1cmd flash status
Flash image B currently booted
Image Status Revision Built
----- ------------- ---------- -----
A default 1.22.2 06/17/2003 10:58:26
B valid 1.14.4 07/25/2002 13:34:38
escaping to L1 system controller
001a01-L1>reboot_l1
SGI SN1 L1 Controller
Firmware Image A: Rev. 1.22.2, Built 06/17/2003 10:58:26
001a01-L1>env
Environmental monitoring is enabled and running.
chunk 15
SD card coming...
--- Post by nintendoeats ---
Boot time, measured from the end of "System is coming up" screen to the Toolchest appearing, is 6:11. Yeesh. This is on a completely default install.
My Indigo2 is essentially unusable with this card. Sometimes things load quickly, but usually not. For example, at one point it took 20 seconds to open the shell.
Here are my diskperf results:
System: Indigo2 R4400SC/250 - 192MB RAM - GR3 (Elan) - SCS2SD v6
SD card: Some old 32GB class 10 Lexar microSD
Firmware and settings unchanged from my last test (except for disk size and SCSI2 turned on)
Code:
chunk 15
M Fan Thermostat Controller. Available directly from their site.
* Fujipoly 17 W/mK TIM: I snagged mine from Amazon. Look for Fujipoly Ultra Extreme pads. They'll list 17 W/mK on the ones you need.
* TRAM support: check the downloads! I attached the STL. I printed my pieces in PLA since the transition temp is higher than the TRAMs should ever be getting.
I hope this post helps anyone who's looking to fix up their TRAMs or add some better cooling to their machine. As I said, I won't say this is the best way to do it. This is just the way I came up with solving this issue. If anyone has any questions or would like to add their thoughts, please do!
Thanks for reading!
--- Post by Elf ---
Excellent troubleshooting and what a thorough and excellent write-up! I appreciate the animated GIF of the resoldering process and the effort you went through 3D printing a heat sink gapper.
Quite a comprehensive solution, and I appreciate you posting it! What a bizarre method SGI had of attaching the heatsink with kapton tape; I can't say I have ever seen that one before...
--- Post by CB_HK ---
Elf said:
chunk 16
ntry
0
12. On-chip secondary cache control
0. Disable
1. Enable (default)
1
13. Two outstanding reads with out-of-order return
0. Disable (default)
1. Enable
0
[PROM] RM7000C custom bitstream saved.
========================================
O2 CPU PROM EMULATOR FW. REV. A00
CPU: RM7000C
Bitstream Profile: custom
Bitstream settings: WriteBackRate: DDDD, Multiplier: x7, Endianness: BE, pipelined non-block writes, TmrIntEn: ON, Tertiary cache: ON, DRVOut: 100%, TCACHE RAM: Dual-cycle deselect, UserCfgID: 01, Mult mode: integer, JTLB: 48 dual-entry, On-chip secondary cache: ON, OOO reads: OFF
Bitstream: 256 bits
Mode: Polled (all sends)
Type 'setup' + Enter for setup menu
Type 'status' + Enter for status
Type 'info' + Enter for info
Type 'boot' + Enter for USB bootloader
Type 'reboot' + Enter to reboot MCU
========================================
chunk 16
PROM reports 2MB secondary cache. Irix boots with no issues and reports 2MB secondary cache.
11: system PROM reports 0MB secondary cache. Irix boots with no issues and reports 4MB secondary cache.
Regarding mode bits 33 and 37, which are reserved (should be 0) and are set to 1. It doesn't seem to make any difference if they are set to 0 or 1.
-SysAD runs at 100MHz
-External cache runs at 100MHz
chunk 16
g my O2 to the office so I can stare at it whilst most people wonder what that blue "thingy" is! )
--- Post by siliboi ---
Looks complete is it ?
--- Post by WMSGI ---
Incredible work and results!
--- Post by DynamicOsi ---
This is incredible work, and quite possibly the best solution for shattered O2s. I would love to print this on a Prusa XL to fix mine which has completely crumbled to bare metal. Any chance this was completed-or can be released in its current state? I'm desperate!
--- Post by wayned ---
Any update on this fabulous model?
--- Post by megaimg ---
Like to know if the model was completed and where I can get it. I have an O2 that I would love to print a couple of parts.
chunk 16
grammed or even present.
There is nothing else going on with that signal, so it was a weird that the system would not turn on with the jumper installed. Here is the jumper next to the Dallas IC:
I proceeded to remove the Dallas IC, and after that, with the jumper installed, the system powered on. This made absolutely no sense, as there was nothing that the Dallas IC could do to prevent the system powering on when the jumper is installed. After installing the IC back, the system still powered on.
Inspected the other side of the board, and this is how the jumper solder joints looked like:
One pin was totally floating. When I removed the Dallas IC, I probably moved it just enough so that the jumper started working. Soldered this back on.
Now, the system powered on, but not much else, just a solid amber light. Without the RAM installed it gave a blinking amber light, again meaning that the PROM is executed.
Without the PCI riser installed it did this:
Which is normal, as it does not detect the one wire IC present on the riser (that holds the MAC address). What is not normal, is that beyond that it doesn't print anything.
chunk 16
Entender a relação entre esses projetos ajuda a evitar confusão, algo importante em qualquer área técnica ou até ao analisar um slot dinheiro real . Contexto e documentação fazem toda a diferença.
Finally, I should also mention that prior to publicly releasing the ZuluSCSI firmware, I privately e-mailed and offered to submit a pull request to the BlueSCSI maintainer so they could incorporate our significant improvements to their code base, and this offer was rejected outright, in a relatively hostile and immature manner. All of this could have been avoided had a more-objective approach been taken.
Thank you for your attention to this matter.
Click to expand...
Thanks for starting it.
chunk 16
---
A bit of an addendum regarding the "Power Good" signal:
Nidec Pgood vs. loaded 5V rail:
Sony Pgood vs. loaded 5V rail:
Sony Pgood loaded w/ 680Ω vs. loaded 5V rail:
Once again another difference between the Nidecs and the Sonys. The Nidec asserts Pgood around 3.3V, long before the 5V rail stabilizes. The Sony apparently thinks it is always good and ties Pgood via a significantly high resistance path to +5Vsb. As can be seen, loading it with just 680Ω drops the voltage down significantly. This behavior is not present on the Nidec.
Between this and the fan, it always seems like the Sony design doesn't quite hit the original spec.
The Nidec Pgood is extremely noisy! It might need capacitor replacements?
--- Post by DVRC ---
I have a question: the new PSU for the Indy, will be compliant with ATX specs for ripple and regulation? A PSU with an high ripple output can cause damage to the hardware
--- Post by onre ---
Getting within (and well beyond) the ATX spec with modern DC-DCs is trivial.
chunk 16
startup from L1 should be enough to get everything sorted out. L1 controllers can talk to eachother over NUMAlink: connecting to one CPU brick with a serial cable should be able to control all four.
--- Post by weblacky ---
Good to know, seemed like an expensive system (newest hardware) so why not an L2? Would make things easier to admin. It’s just money .
--- Post by CiaoTime ---
L2's easier in theory, but none of the folks I know with O3x0 hardware have the sweetest clue how to run it. :V
--- Post by nondem ---
I shutdown the OS, unplugged the power - waited till the L1 console reported it was shutting down and I lost connection.
Then I plugged it back in and got this:
001c02-L1>INFO: 001c02 will power up system in 85 seconds...
INFO: 001c02 will power up system in 80 seconds...
INFO: 001c02 will power up system in 75 seconds...
INFO: 001c02 will power up system in 70 seconds...
INFO: 001c02 will power up system in 65 seconds...
INFO: 001c02 will power up system in 60 seconds...
INFO: 001c02 will power up system in 55 seconds...
INFO: 001c02 will power up system in 50 seconds...
INFO: 001c02 will power up system in 45 seconds...
chunk 16
al drive has to go that speed (by standard, not data transfer ability) and therefore the hard drive has to match that bus speed. You cannot mix and match, lowest common denominator on standard wins.
In order for newer devices to fill their role on older equipment ultra160 and ultra320 LVD Devices have the ability to operate as if they were ancient, older devices in SE mode!
Now one thing to note about LVD is that the drives no longer carry their own termination, termination of an LVD bus must be done by an external termination device. On the LVD supported cables it's crimped onto the end, after the last drive connector. So the cable helps the bus self terminate the drives cannot.
In SE mode the drives can still self terminate, if you jumper them to do that.
So the whole point of me explaining this is that those SATA-SCSI bridges that have Ultra160 SCSI Support are native LVD devices. They're supposed to operate just fine in SE mode, but there have been reports that they don't really like doing it because the company didn't really think anyone would buy the LVD version and shove it into a non-LVD system. So it wasn't really well tested...
- 192MB RAM - GR3 (Elan) - SCS2SD v6
SD card: Some old 32GB class 10 Lexar microSD
Firmware and settings unchanged from my last test (except for disk size and SCSI2 turned on)
Code:
# diskperf -W -n scsi2sd_BadCard -c 1G -t 60 /tmp/testpath
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name : scsi2sd_BadCard
# Test date : Tue Apr 7 08:15:16 2020
# Test machine : IRIX IRIS 6.5 05190003 IP22
# Test type : XFS data subvolume
# Test path : /tmp/testpath
# Request sizes : min=4096 max=4194304
# Parameters : direct=0 time=60 scale=1.000 delay=0.000
# XFS file size : 1073741824 bytes
#---------------------------------------------------------
# req_size fwd_wt fwd_rd bwd_wt bwd_rd rnd_wt rnd_rd
# (bytes) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s)
#---------------------------------------------------------
4096 1.96 8.36 1.71 7.02 0.02 0.25
8192 2.53 6.40 2.53 5.02 0.04 0.84
16384 2.56 5.57 2.53 5.10 0.08 1.80
32768 2.66 6.50 2.54 4.56 0.27 0.12
65536 6.20 6.06 1.98 0.00 0.80 0.00
131072 5.37 6.31 2.24 2.67 0.79 1.78
262144 6.86 6.70 1.99 2.24 0.61 2.89
chunk 16
I appreciate you posting it! What a bizarre method SGI had of attaching the heatsink with kapton tape; I can't say I have ever seen that one before...
--- Post by CB_HK ---
Elf said:
Excellent troubleshooting and what a thorough and excellent write-up! I appreciate the animated GIF of the resoldering process and the effort you went through 3D printing a heat sink gapper.
Quite a comprehensive solution, and I appreciate you posting it! What a bizarre method SGI had of attaching the heatsink with kapton tape; I can't say I have ever seen that one before...
Click to expand...
Thanks, Elf! It's always a nice feeling to help provide more tips and tricks for the community. As for the Kapton tape, I can't really figure out why they used it in the manner they did. They may have been worried about the heatsinks coming off but honestly the thermal tape was quite strong as it was.
--- Post by Jacques ---
Lovely writeup! Excellently presented and well done on the heatsink attachment clip.
chunk 17
nstalled it did this:
Which is normal, as it does not detect the one wire IC present on the riser (that holds the MAC address). What is not normal, is that beyond that it doesn't print anything.
This can indicate that the system has problem initializing/talking to some parts of the hardware (exact same behaviour with no Dallas IC installed or GBE not present on the board, likely with other faults, but I haven't confirmed yet). Would have been nice if the PROM had more debug prints, there was space for that, since the flash is about 20% empty. Another thing that it can indicate is that the PROM is corrupted, even though it kind of works.
Inspected traces, components and so on, really could not spot anything that would indicate a fault. So I proceeded to remove the flash (same as board #2 and #3), rewrite the PROM, and install it back in. After doing this the MB fired up:
It also boots into Irix with no issues.
--- Post by ruckusman ---
Besides the dysfunctional behaviour of that Dallas chip - Atmel PROM data corruption is emerging as a prime suspect in the non-functioning Mobo category.
chunk 17
specs for ripple and regulation? A PSU with an high ripple output can cause damage to the hardware
--- Post by onre ---
Getting within (and well beyond) the ATX spec with modern DC-DCs is trivial.
--- Post by Elf ---
@Str1kernaut it should exceed them, but prior to releasing it I will put it under full load and post how it performs. Note however none of the original power supplies do too well
--- Post by callahan ---
Elf -- I've been making some improvements to the higher intellect wiki in areas where I have insight and suit my interests. Any heartburn if I incorporate your findings there, hopefully to preserve info in a readily accessible form?
--- Post by Elf ---
@callahan - no problem! I just ask that you link back to the forum thread to credit the original source
--- Post by callahan ---
Of course. You can see some of my recent edits here:
Nekoware
The Nekochan site, and along with it active Nekoware development, is gone and is unlikely to come back. See below for active porting efforts
wiki.preterhuman.net
Video Format Object (VFO) Files
chunk 17
1c02 will power up system in 60 seconds...
INFO: 001c02 will power up system in 55 seconds...
INFO: 001c02 will power up system in 50 seconds...
INFO: 001c02 will power up system in 45 seconds...
INFO: 001c02 will power up system in 40 seconds...
INFO: 001c02 will power up system in 35 seconds...
INFO: 001c02 will power up system in 30 seconds...
INFO: 001c02 will power up system in 25 seconds...
INFO: 001c02 will power up system in 20 seconds...
INFO: 001c02 will power up system in 15 seconds...
INFO: 001c02 will power up system in 10 seconds...
INFO: 001c02 will power up system in 5 seconds...
INFO: 001c02 powering up the system.
It stopped there and so far none of the bricks have power lights on them.
Is there some point in this process I should press the power buttons on each brick?
--- Post by weblacky ---
Again I’ll wait for someone else to confirm this. Don’t press the power buttons. Use the L1 to power up all. The L1 is always running as long as the power supply has power. If you press the power buttons you’ll be back with the same errors due to improper startup procedure.
So since you see L1 output, I assume you can type input.
Now type the command:
chunk 17
have been reports that they don't really like doing it because the company didn't really think anyone would buy the LVD version and shove it into a non-LVD system. So it wasn't really well tested...
Even though both did use the SCA 80 connector for hot swap capability, the SGI octane is an ultra wide SE system. The SCA 80 standard has all the configurations available through the pin interface on the connector, when you shove in the drive it's AUTO configurable as much as whoever built the backplane wanted it to be. The backplane sets the drives ID and other options, including the detection of SE mode.
For a normal consumer hard drive this should work just fine and everything's great, for these SCSI bridge devices this wasn't well tested. So you're asking the device to operate in a reduced mode at a different voltage with different signaling and different termination then it was optimally designed to do. So any flaws or design issues that didn't properly account for this will crop up when it's not in LVD mode. And it will never be in LVD mode inside the bay of an octane.
chunk 17
2.97/ 3.63 20% 2.64/ 3.96 3.29
PIMM0 5V aux Enabled 10% 4.50/ 5.50 20% 4.00/ 6.00 5.10
XIO 12V bias Enabled 10% 10.80/ 13.20 20% 9.60/ 14.40 12.06
XIO 5V Enabled 10% 4.50/ 5.50 20% 4.00/ 6.00 5.17
XIO 2.5V Enabled 10% 2.25/ 2.75 20% 2.00/ 3.00 2.47
XIO 3.3V aux Enabled 10% 2.97/ 3.63 20% 2.64/ 3.96 3.30
Description State Warning RPM Current RPM
-------------- ---------- ----------- -----------
FAN 0 EXHAUST Enabled 920 1202
FAN 1 HD Enabled 1560 2200
FAN 2 PCI Enabled 1120 1573
FAN 3 XIO 1 Enabled 1600 2229
FAN 4 XIO 2 Enabled 1600 2171
FAN 5 PS Enabled 1600 2040
Advisory Critical Fault Current
Description State Temp Temp Temp Temp
-------------- ---------- --------- --------- --------- ---------
NODE 0 Enabled 60C/140F 65C/149F 70C/158F 42C/107F -0-
NODE 1 Enabled 60C/140F 65C/149F 70C/158F 36C/ 96F -0-
NODE 2 Enabled 60C/140F 65C/149F 70C/158F 30C/ 86F -0-
PIMM Enabled 60C/140F 65C/149F 70C/158F 50C/122F -0-
ODYSSEY Enabled 60C/140F 65C/149F 70C/158F 32C/ 89F -0-
BEDROCK Enabled 70C/158F 75C/167F 80C/176F 45C/113F -0-
001a01-L1>
The strange values are now fixed and no more "ALERT: Unknown PSC: 9"
chunk 17
02 0.04 0.84
16384 2.56 5.57 2.53 5.10 0.08 1.80
32768 2.66 6.50 2.54 4.56 0.27 0.12
65536 6.20 6.06 1.98 0.00 0.80 0.00
131072 5.37 6.31 2.24 2.67 0.79 1.78
262144 6.86 6.70 1.99 2.24 0.61 2.89
524288 5.59 5.85 2.29 0.01 0.79 5.60
1048576 5.58 5.40 2.17 0.02 0.75 3.84
2097152 6.69 5.33 2.37 1.68 0.90 7.48
4194304 6.18 6.52 2.26 3.26 2.23 0.18
Many of those numbers aren't that different from those of my good SD card. However, the random reads and writes are truly appalling. They are also inconsistent across sizes, which I'm guessing represents strong run-to-run variance based on the behavior of the card's internal controller.
chunk 17
about the heatsinks coming off but honestly the thermal tape was quite strong as it was.
--- Post by Jacques ---
Lovely writeup! Excellently presented and well done on the heatsink attachment clip.
--- Post by bokowski ---
Thanks a lot for documenting the problem and the fix! My two TRAM modules had exactly the same issue of loose contacts and I've re-soldered everything.
I'm running into a different problem now, and I was wondering if you have any idea what might be going on.
If I install both TRAM modules on my Max IMPACT, i.e. one on the top board and one on the middle board, the Indigo2 doesn't start properly: I hear the regular chime followed by a dissonant chord, and the power LED stays yellow. I assume this means that some kind of check of the graphics board failed.
I've tried all kinds of things and have discovered that the system does boot if I install only one of the TRAM modules, on the top board. In this mode of operation, anything with textures appears striped, since only every other scanline has the proper texture. Both TRAM modules "work" in this way when I put them on the topmost board and leave the middle board without a TRAM module.
chunk 18
x with no issues.
--- Post by ruckusman ---
Besides the dysfunctional behaviour of that Dallas chip - Atmel PROM data corruption is emerging as a prime suspect in the non-functioning Mobo category.
I've got a solid red Mobo here, I think that's going to have to be my entry point in diagnosis, the Ateml PROM
--- Post by ruckusman ---
Hmm - solid red may means something more dire, kaput PROM or something even worse.
The adapter ecosystem around the Xgecu programmers is vast, but so many of the adapters are quite specific, or schematic/pin mappings are either absent, indecipherable or type specific - nothing that I could locate in the software anyway.
Instead I bit the bullet on two cheaper adapters, one which I can solder the FFC connectors to directly, the other with a TSOP48 socket.
I made an adapter that plugs in place of the Dallas IC, two FFCs soldered where the flash IC is, with a TSOP 32 socket on top and a socket for the relocated Dallas IC.
That sound to be a very simple solution, so you've got the FFC soldered to the board, the Atemel socketed, can be easily removed for programming I assume and the Dallas elsewhere out of the way...impressive.
chunk 18
pment, is gone and is unlikely to come back. See below for active porting efforts
wiki.preterhuman.net
Video Format Object (VFO) Files
Video format objects are microcode images loaded into SGI graphics display hardware to generated the timing signals required to produce display images at specific resolutions and refresh rates. Vfo's are generated using SGI's Video Format Compiler (VFC) and end-user prepared video format source...
wiki.preterhuman.net
--- Post by callahan ---
@Elf my first stab at condensing Indy PSU content is here: https://wiki.preterhuman.net/Indy_Power_Supplies I enjoyed digging into your work, definitely have a better grasp of the details of the PSU now.
--- Post by ghost180sx ---
Great post! I'm really impressed with your analysis Elf.
Some thoughts on the standby supply:
This should be providing power to the RTC and CMOS (Dallas) chip as the system supports booting up on a time schedule that you can set. This is a hardware feature built right into the Dalls chip. Any standby voltage/current should be feeding this part of the system when plugged into the wall.
chunk 18
pply has power. If you press the power buttons you’ll be back with the same errors due to improper startup procedure.
So since you see L1 output, I assume you can type input.
Now type the command:
* pwr up
into the L1 and see if everything starts powering up.
--- Post by nondem ---
nondem said:
I shutdown the OS, unplugged the power - waited till the L1 console reported it was shutting down and I lost connection.
Then I plugged it back in and got this:
001c02-L1>INFO: 001c02 will power up system in 85 seconds...
INFO: 001c02 will power up system in 80 seconds...
INFO: 001c02 will power up system in 75 seconds...
INFO: 001c02 will power up system in 70 seconds...
INFO: 001c02 will power up system in 65 seconds...
INFO: 001c02 will power up system in 60 seconds...
INFO: 001c02 will power up system in 55 seconds...
INFO: 001c02 will power up system in 50 seconds...
INFO: 001c02 will power up system in 45 seconds...
INFO: 001c02 will power up system in 40 seconds...
INFO: 001c02 will power up system in 35 seconds...
INFO: 001c02 will power up system in 30 seconds...
INFO: 001c02 will power up system in 25 seconds...
chunk 18
as optimally designed to do. So any flaws or design issues that didn't properly account for this will crop up when it's not in LVD mode. And it will never be in LVD mode inside the bay of an octane.
An Octane's internal SCSI bus moves so slow that honestly putting an SSD SCSI bridge, that is now worth a lot of money, doesn't really make any sense over a nice cool running Fujitsu SCA80 hard drive of the day.
Obviously you can do whatever you like with personal property, it's simply a warning that given there's been some talk about this and it's kind of a waste anyway to not have it on an ultra160 bus to get actual speed out of it that your bridge you would be better off removing the bridge from the internal bay and spending the $35 or whatever on eBay and getting a nice cool running Fujitsu MAS3367NC SCSI drive to throw in there.
I was under the impression there are cards available that run at ultra160 (QLOGIC QLA10160) that you can put in an octane PCI shoebox that you could then use external enclosures to attach at ultra160 speed and actually get multiple times the speed of the Octane's SCSI bus out of the SCSI-SATA bridge while running it the way it was designed to.
chunk 18
-
ODYSSEY Enabled 60C/140F 65C/149F 70C/158F 32C/ 89F -0-
BEDROCK Enabled 70C/158F 75C/167F 80C/176F 45C/113F -0-
001a01-L1>
The strange values are now fixed and no more "ALERT: Unknown PSC: 9"
I still have CPU mismatch, but what I have read it should not matter.
Next I tied to figure out what is wrong with the V12 board.
Code:
IRIS 21# /usr/gfx/gfxinfo -vv
Graphics board 0 is "ODYSSEY" graphics.
Unmanaged 1280x1024
BUZZ version B.1
PB&J version 0
128MB memory
Banks: 4, CAS latency: 3
Monitor 0 type: Unknown
Xvc info not available for unmanaged boards
There seems to problem with PB&J as it reports "PB&J version 0".
I was able to install "Customer Diagnostics for Silicon Graphics Fuel visual workstation 1.0" to the system.
Both diagnostics (in Command monitor and IRIX) runs successfully without any fails.
There is something wrong with V12 that is possibly related to PB&J chip.
I started to wonder if the chips solder balls have separated from the PCB.
I removed the V12 board and detached the small radiator from PB&J. Thermal pad is completely dry and there looks like to be a hairline crack on the side of the chip.
chunk 18
andom reads and writes are truly appalling. They are also inconsistent across sizes, which I'm guessing represents strong run-to-run variance based on the behavior of the card's internal controller.
Combine this information with the results from @callahan and the disk tests from @23jodys , and I think we can conjecture that random read/write performance is critical to real-world performance of system boot and running typical applications. I don't think this is news to anybody, but it seems like for general use you should stick with whatever has the best small random r/w performance (within reason). In the tests so far, that is a SCSI2SD with a high-quality SD card (even if it can't touch the spinning metal for forward and large size r/w performance).
Another thing to consider is endurance. I'm curious if performance will degrade faster for SD cards than it does for typical SCSI HDDs, since SD cards tend to use lower-quality flash. Le sigh, if only those SATA -> SCSI bridges weren't being sold at horrifically inflated prices...
--- Post by Elf ---
nintendoeats said:
chunk 18
s appears striped, since only every other scanline has the proper texture. Both TRAM modules "work" in this way when I put them on the topmost board and leave the middle board without a TRAM module.
Without any TRAM modules installed, textures work, but as expected there's only 1MB of texture memory available.
Does this mean that there's something wrong with the middle board? The system was (mostly) working with occasional weird glitches before I attempted the repair, and I am wondering if I caused a problem when pulling out the TRAM modules. I don't see anything wrong when inspecting things visually, i.e. there aren't any shorts or bent pins.
Anyway, I would appreciate any ideas, or questions to narrow down what's causing my issues. Thanks!
--- Post by CB_HK ---
bokowski said:
Thanks a lot for documenting the problem and the fix! My two TRAM modules had exactly the same issue of loose contacts and I've re-soldered everything.
I'm running into a different problem now, and I was wondering if you have any idea what might be going on.
chunk 19
d to be a very simple solution, so you've got the FFC soldered to the board, the Atemel socketed, can be easily removed for programming I assume and the Dallas elsewhere out of the way...impressive.
Do you mean leaving the flash IC on the MB, and then connecting the needed signals to the programmer?
Yes.
My plan is to revive a Mobo, or Mobos, hopefully with a PROM re-flash, but I when I devised this idea of flashing the Atmel in place, it was with a view to getting the PROM mods done for the RM7900 without sacrificing Mobos - PROM mods (experimental) could brick a board easily.
Other elements are, PWR_ON jumper (same as pressing the power button) able to be activated externally from the cable connections to the programmer, and the reset button (switched = kept depressed) which should be able to keep the CPU and the rest of the system on, but inactive, in reset, which should allow the programmer signals to avoid collision with the other IC's that would be attempting to read the PROM.
Your solution actually achieves that by the sound of it, makes mine look over-engineered.
--- Post by siliboi ---
very nice ill have to check my two solid reds for that defect
chunk 19
up on a time schedule that you can set. This is a hardware feature built right into the Dalls chip. Any standby voltage/current should be feeding this part of the system when plugged into the wall.
I just solved an issue with my Indy today. I have two units, one with a Nidec and the other with a Sony PSU. For no reason at all, I was using the machine with the Nidec as my primary setup, and had left the Sony unit on the shelf as a spare. I noticed a lot of noise through the monitor on high res (1280x1024) mode, specifically fuzz and overall picture clarity issues. I also noticed, when transferring files over FTP to my Indy, some strange buzzing and chirping sounds from the built in power supply speaker.
I knew it wasn't the monitor or the 13W3->VGA adapter, as both of those work flawlessly on my other systems. I thought it could be the XL 8-bit video card, but the noise from the speaker made me think the issue was elsewhere. I also had noticed that one of the two main (large) electrolytic caps on the NIDEC was starting to bulge when I opened it up to blow all the dust out and inspect it for cap leakage a week ago.
chunk 19
1c02 will power up system in 40 seconds...
INFO: 001c02 will power up system in 35 seconds...
INFO: 001c02 will power up system in 30 seconds...
INFO: 001c02 will power up system in 25 seconds...
INFO: 001c02 will power up system in 20 seconds...
INFO: 001c02 will power up system in 15 seconds...
INFO: 001c02 will power up system in 10 seconds...
INFO: 001c02 will power up system in 5 seconds...
INFO: 001c02 powering up the system.
It stopped there and so far none of the bricks have power lights on them.
Is there some point in this process I should press the power buttons on each brick?
Click to expand...
Just got an L1 prompt and entered * pwr up
came back w/o saying anything:
001c02-L1>* pwr up
001c02-L1>
All of the bricks power lights are still off.
Dunno if I should try to power them w/the buttons on them - and if so - at what point in the process? I know you said not to so I haven't yet.
--- Post by nondem ---
I'd like to take just a minute to say I appreciate the help...I'm really in the hotseat here.
--- Post by weblacky ---
Looking at O350 manual, try
pwr u
chunk 19
d then use external enclosures to attach at ultra160 speed and actually get multiple times the speed of the Octane's SCSI bus out of the SCSI-SATA bridge while running it the way it was designed to.
But yeah I'd say right now you probably have a Power supply issue.
All that's available are used ones on the market, I do rebuild SGI power supplies but I've not gotten to Octane yet and it won't get there for at least a year. Octane PSUs are in big demand along with Indigo2 but I not only have a bunch of stuff ahead of it but I plan to do O2 next because it's the next "simple" power supply that we could probably knock off the list real fast to provide rebuilds. Octane and Indigo2 are much more complex power supplies that require a lot more physical work to rebuild/clean/test.
chunk 19
ls have separated from the PCB.
I removed the V12 board and detached the small radiator from PB&J. Thermal pad is completely dry and there looks like to be a hairline crack on the side of the chip.
The chips packaging is very thick and unusual.
After putting it back together errors have changed:
Code:
WARNING: xbow_base: 0x9200000000000000 link: 13 Widget present, but link not al!
WARNING: xbow_base: 0x9200000000000000 link: 13 Widget present, but link not al!
no response from 001a01 CPU0, system not responding
DIAG RESULTS:
/hw/module/001c01/brick/xtalk/13: IO link bad
I may have damaged the PB&J chip or its connection to PCB more when removing the radiator.
However, now the IRIX seems to always boot and is stable. "/usr/gfx/gfxinfo -vv" says there is no graphics card.
Most likely I will need new V10 or V12 board.
I would also like to have someone resolder the PB&J if the problem is with the BGA connection.
It may be impossible to do as the packaging is very thick and the solder balls are massive. The PCB is also very thick itself.
I think the last owner tried to fix this by changing the CPU, but the problem was in V12.
chunk 19
nce SD cards tend to use lower-quality flash. Le sigh, if only those SATA -> SCSI bridges weren't being sold at horrifically inflated prices...
--- Post by Elf ---
nintendoeats said:
I'm curious if performance will degrade faster for SD cards than it does for typical SCSI HDDs, since SD cards tend to use lower-quality flash.
Click to expand...
I used to worry about this while putting together single board systems that ran off Compact Flash cards, but, if you do the math on it some pretty consistent throughput has to be put on it for many months / a few years to get to the write cycle life of the individual cells. If you can find write cycle life info for those cards it's worth doing the math vs. IOPS and see what you come up with for your conbination.
--- Post by callahan ---
I also have an Indigo2 (R10k 175MHz) and Octane that I've been running benchmarks against. Will post results when I have good data. Initial results look like the I2 is substantially faster all-around than the Indy, wonder if it's just a better SCSI controller?
chunk 19
TRAM modules had exactly the same issue of loose contacts and I've re-soldered everything.
I'm running into a different problem now, and I was wondering if you have any idea what might be going on.
If I install both TRAM modules on my Max IMPACT, i.e. one on the top board and one on the middle board, the Indigo2 doesn't start properly: I hear the regular chime followed by a dissonant chord, and the power LED stays yellow. I assume this means that some kind of check of the graphics board failed.
I've tried all kinds of things and have discovered that the system does boot if I install only one of the TRAM modules, on the top board. In this mode of operation, anything with textures appears striped, since only every other scanline has the proper texture. Both TRAM modules "work" in this way when I put them on the topmost board and leave the middle board without a TRAM module.
Without any TRAM modules installed, textures work, but as expected there's only 1MB of texture memory available.
chunk 20
ng to read the PROM.
Your solution actually achieves that by the sound of it, makes mine look over-engineered.
--- Post by siliboi ---
very nice ill have to check my two solid reds for that defect
--- Post by sdz ---
@ruckusman @siliboi
For solid red, I'd first check the power rails, CPU connectors, main 133MHz oscillator and the general CRIME area.
@ruckusman
Keeping the system in reset while writing to the FLASH IC might work nicely (if MACE keeps its IOs in high-Z)
--- Post by ruckusman ---
CPU connectors are good candidates as something that went from working to non-booting whilst on the shelf doesn't really point to component failure.
For the flashing, there was the, not really feasible, possibility of flashing it with the system unpowered, but there would have been a lot of parasitic voltage losses on the power rails - I've set it up to be able to keep the power rails from board and programmer unconnected.
Hopefully MACE does keep it's nose out of it.
chunk 20
here. I also had noticed that one of the two main (large) electrolytic caps on the NIDEC was starting to bulge when I opened it up to blow all the dust out and inspect it for cap leakage a week ago.
Then, I swapped the Nidec for the Sony power supply, and almost all the noise and issues has gone away! I think it's time for a re-cap on this Nidec to see if I can get it back to good working order again.
So if you have noisy video or audio on your Indy, and you haven't inspected your power supply, you might want to do that ASAP before it goes "pop!"
--- Post by Elf ---
Good info! That must have been a crazy noisy power supply for it to manifest in the VGA output... Ouch!
Glad you got it sorted
I really need to put the last finishing touches on the Indy PSU replacement boards; just have been busy with birth stuff... Probably not for another few months unfortunately, until all this settles out.
--- Post by ghost180sx ---
Take your time! Birthing is very important in one's life
--- Post by stormy ---
I am wondering if we could replace the Indy PSU with a Meanwell? They have quite a few different models available and are very popular in the retro community:
chunk 20
o so I haven't yet.
--- Post by nondem ---
I'd like to take just a minute to say I appreciate the help...I'm really in the hotseat here.
--- Post by weblacky ---
Looking at O350 manual, try
pwr u
--- Post by nondem ---
Most recent output and I tried a "pwr" command to get this status:
001c02-L1>* pwr up
001c02-L1>pwr u
001c02-L1>pwr
Supply State Voltage Margin Value
-------------- ----- --------- ------- -----
1.8V on 1.777V normal 0
12V <not present>
12V #2 on 12.000V N/A
3.3V NC 3.320V normal 0
12V IO NC 12.063V N/A
5V AUX NC 5.044V N/A
3.3V AUX NC 3.268V N/A
PCI 5V AUX NC 5.044V N/A
PCI 3.3V NC 3.320V N/A
PCI 2.5V on 2.509V normal 0
PCI 5V on 4.940V normal 0
XIO 12V BIAS <not present>
XIO 5V <not present>
XIO 2.5V <not present>
XIO 3.3V AUX <not present>
IP59 3.3V AUX NC 3.268V N/A
IP59 5V AUX NC 5.018V N/A
IP59 12V NC 11.938V N/A
IP59 VCPU on 1.283V normal 11
IP59 SRAM on 2.457V normal 0
IP59 1.5V on 1.480V normal 0
--- Post by weblacky ---
Ok, I have a contractor here so I have to bounce for now. I’m just going with page 53 @ https://irix7.com/techpubs/007-4566-001.pdf
chunk 20
r supply that we could probably knock off the list real fast to provide rebuilds. Octane and Indigo2 are much more complex power supplies that require a lot more physical work to rebuild/clean/test.
--- Post by 3DChris ---
Thanks for the detailed info on the SE vs LVD SCSI. I'll have to double check, but I'm pretty sure when I bought the Acard, I put it in the correct mode. I didn't notice any speed difference compared to the internal HDD. It was quieter and cooler though, so maybe that's why I bought it? It's been a long time, and this is when SSDs were brand new to the market. I think I was just itching to see if I could have any additional advantage of an SSD in an Octane vs a traditional HDD. But the SCSI interface inside is so slow that it didn't make a difference.
I don't have that SSD Acard drive in the system right now anyways. It's running on a Seagate Cheetah HDD. It's physically a big boy. I've got other HDDs that I bought from Ian over the years. I don't know what's on them, but that's something I'll need to investigate after I get my PSU fixed/replaced.
chunk 20
e to do as the packaging is very thick and the solder balls are massive. The PCB is also very thick itself.
I think the last owner tried to fix this by changing the CPU, but the problem was in V12.
Any ideas what to do/test?
--- Post by rams ---
Looks like I'm now getting following on irix boot again. Kernel crashes and system resets.
No more "IO link bad". So I'm back to where it was before I messed around with the heatsink.
I didn't have the card fully screwed in, so it might have been a bad connection.
Code:
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
WARNING: odsy dfifo timeout
Credits stuck above maximum
ALERT: odsy board 0: Graphics error
odsy flags: 0x800000<XFORM_DFIFO_OFLOW_INTR>
odsy status0: 0x434080<CTXSW_ACTV,CFIFO_LW,CFIFO_MT,XRFIFO_LW,RASTER_SYNC_SRC=unset,CFIFO_SYNC_SRC=unset,DMA_SYNC_SRC=unset>
This error might give a clue.
My card is propably beyond repair. There is V10 on ebay for, but I don't really need it that much (the price) since this is just a hobby project.
I would like to try to run V12 diagnostics on it now, but it seems there is no publicly available copy of it (IST 2.7 CD).
chunk 20
running benchmarks against. Will post results when I have good data. Initial results look like the I2 is substantially faster all-around than the Indy, wonder if it's just a better SCSI controller?
FWIW, the Octane is spitting nonsensical data with the diskperf options I had been using (rnd_rd in the 100+ MB/S range, other values 0.00). After looking at the manpage and examples, I think we need to add the "-D" flag. Just starting a run now, but it seems to be giving good data even with a 10 second run on my Octane. If this options gives better data, I'll re-run it on all three systems.
One reason I chose my Transcend card is that I seem to recall it's supposed to have increased write tolerance. Shame that the SCSI2SD almost certainly has no write-leveling feature.
On the bogus data, initial phases of a few different runs ...
Code:
chunk 20
en I put them on the topmost board and leave the middle board without a TRAM module.
Without any TRAM modules installed, textures work, but as expected there's only 1MB of texture memory available.
Does this mean that there's something wrong with the middle board? The system was (mostly) working with occasional weird glitches before I attempted the repair, and I am wondering if I caused a problem when pulling out the TRAM modules. I don't see anything wrong when inspecting things visually, i.e. there aren't any shorts or bent pins.
Anyway, I would appreciate any ideas, or questions to narrow down what's causing my issues. Thanks!
Click to expand...
Hello!
chunk 21
ve been a lot of parasitic voltage losses on the power rails - I've set it up to be able to keep the power rails from board and programmer unconnected.
Hopefully MACE does keep it's nose out of it.
--- Post by mapesdhs ---
Just a quick mention, please feel free to send me any files you'd like to be included on my Depot downloads page, along with relevant descriptions. I don't use Discord, especially not after their recent changes.
sdz, would an R10K/175 module be of any use?
Ian.
--- Post by sdz ---
@mapesdhs I'll prepare some things and send them!
The 175MHz R10k would be useful for documenting how it's set up/dumping the FPGA bitstream (moving that to the 150MHz R10k will likely allow it to run at 175MHz, since it's a 180MHz R10k CPU inside)/or if it's broken, document what, if it can be fixed etc.
chunk 21
e
--- Post by stormy ---
I am wondering if we could replace the Indy PSU with a Meanwell? They have quite a few different models available and are very popular in the retro community:
MEAN WELL Switching Power Supply Manufacturer
MEAN WELL offers a comprehensive power solution with our versatile series of power supplies. You can use this product overview tool to find product information and datasheet of all MEAN WELL products, such as RS, LRS, UHP series for industrial application, HLG, ELG, XLG, HVGC series for LED...
www.meanwell.com
--- Post by Elf ---
They don't really have a match for all the output rails in the same form factor, but it's not a bad source of current
--- Post by Elf ---
Speaking of which, it is about time I pick up this project again...
chunk 21
normal 0
IP59 1.5V on 1.480V normal 0
--- Post by weblacky ---
Ok, I have a contractor here so I have to bounce for now. I’m just going with page 53 @ https://irix7.com/techpubs/007-4566-001.pdf
I’ll check back but have to bow out. It claims to have the procedures for these types of start ups.
--- Post by HAL ---
You should be able to power up the other 3 bricks manually and say after 2 minutes restart the boot-brick (either from Irix or the L1) and the
it should discover the 3 bricks automatically.
If I was you I'd first check the thick numalink cable from the boot-brick to the 1st compute-brick thoroughly since if this connection is not up none
of the other bricks can be discovered.
--- Post by nondem ---
Ok - I followed the steps you mentioned...rebooted the one main brick after manually hitting the power on the other ones.
Looks like it may be fixed!!!!!
Here is the new hinv output:
vortex 1# hinv -vm
Location: /hw/module/001c02/node
IP59_4CPU Board: barcode NSG072 part 030-1989-003 rev -B
Location: /hw/module/001c02/IXbrick/xtalk/15
2U_INT_53 Board: barcode NST935 part 030-1809-006 rev -B
Location: /hw/module/001c02/IXbrick/xtalk/15/pci-x/0/1/ioc4
chunk 21
D. It's physically a big boy. I've got other HDDs that I bought from Ian over the years. I don't know what's on them, but that's something I'll need to investigate after I get my PSU fixed/replaced.
I managed to run a test last night using the built in System Test in the maintenance screen. The power supply failed the test, so there's no doubt that it needs replacing.
I've put in some feelers around my area for people who know how to fix PSUs, so I'm waiting to hear back from them. Hopefully this is fixable.
Buying and shipping/importing a refurbished one is going to be expensive with all the bull tariffs going on in the States (I'm in Canada, but nobody knows what the hell they're doing with shipping anymore).
--- Post by weblacky ---
I'm genuinely not aware if a power supply test in the Octane, did you use the firmware diagnostic option or did you use the confidence tests in the UI?
What did you run?
--- Post by 3DChris ---
I used the system diagnostics button that opens the ESD test and it automatically runs.
chunk 21
t really need it that much (the price) since this is just a hobby project.
I would like to try to run V12 diagnostics on it now, but it seems there is no publicly available copy of it (IST 2.7 CD).
--- Post by weblacky ---
What PIMM is in it now, you just say you got another CPU, what is actually in the system? Can you please give the actual SGI part number on the side of the PIMM?
Can you please provide the V12 SGI Part number on the side of the Graphics Card?
I can't necessarily help with the card but if you do deem it problematic and use a V10 to prove it. I have been trying to obtain these V12 Fuel cards as research subjects for a future repair business. Since it's not working but is detected I'd be willing to buy it off you for research purposes. The V12 fuel cards have a very high rate of failure compared to the V10, age related degeneration of the passive doesn't help this problem.
Where are you located?
I'm in Seattle, WA, USA.
Also likely the cheapest dealer for Fuel V10 cards will be: http://mashek.com/SGIparts/Fuel.php
chunk 21
supposed to have increased write tolerance. Shame that the SCSI2SD almost certainly has no write-leveling feature.
On the bogus data, initial phases of a few different runs ...
Code:
[octane]:~/indy$ diskperf -W -n Octane_SCSI2SD -c 1G -t 60 /home/indy/testpath
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name : Octane_SCSI2SD
# Test date : Mon Apr 6 21:11:10 2020
# Test machine : IRIX64 octane 6.5 07202013 IP30
# Test type : XFS data subvolume
# Test path : /home/indy/testpath
# Request sizes : min=16384 max=4194304
# Parameters : direct=0 time=60 scale=1.000 delay=0.000
# XFS file size : 1073741824 bytes
#---------------------------------------------------------
# req_size fwd_wt fwd_rd bwd_wt bwd_rd rnd_wt rnd_rd
# (bytes) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s)
#---------------------------------------------------------
16384 9.83 5.95 5.96 0.00 0.00 140.21
That doesn't make sense! Let's see if -D w/ 10 sec tests is consistent for a couple runs ...
Code:
chunk 21
ings visually, i.e. there aren't any shorts or bent pins.
Anyway, I would appreciate any ideas, or questions to narrow down what's causing my issues. Thanks!
Click to expand...
Hello!
The first thing that comes to mind would be the interconnect cables that attach the boards together. They happen to be fairly fragile and if damaged may be the source of what you're dealing with. Besides this, it's possible that there's some other issue with your middle board and you may need to either find the source of the problem or swap that board out. Unfortunately I'm not too sure where to look specifically when it comes to troubleshooting. Unlike a lot of other vintage systems we lack the wiring diagrams and board schematics to be able to check individual parts and functions.
If you need parts, either the interconnect cables, or middle board, I'd try reaching out to Doug Mashek. If you google Mashek Systems you'll find his site. He has a lot more than what he has listed on there.
Good luck!
--- Post by 7spirals ---
Amazing job of removing the solder-mask and fixing it without bleeding over on the other leads!
chunk 22
't really have a match for all the output rails in the same form factor, but it's not a bad source of current
--- Post by Elf ---
Speaking of which, it is about time I pick up this project again...
--- Post by weblacky ---
Cool, it looks like you've made a kind of power distribution backplane where you have individual modules produces the other voltages? At least that would easier to troubleshoot in the future. So you're basic plan was the get a main 12V AC-DC PSU module, then design a board that passed that 12V through and took needed 12v power to produce the other voltages. Did you have a plan to modularize the "system specific logic" of this PSU in one of those neat edge connectors? Like a plan to create a basic platform you could refactor in size and shape (for other SGIs, like the O2), and use a module to emulate the non-standard signalling lines?
--- Post by Elf ---
Yes, more or less that
Once I get this sorted I will be reusing the same modules for an Indigo 1 supply, most likely.
--- Post by Elf ---
Well, this is starting to come together.
--- Post by Silicon-Surfer ---
Slightly off topic but thanks for all your work measuring the outputs of the Indy PSUs!
chunk 22
NSG072 part 030-1989-003 rev -B
Location: /hw/module/001c02/IXbrick/xtalk/15
2U_INT_53 Board: barcode NST935 part 030-1809-006 rev -B
Location: /hw/module/001c02/IXbrick/xtalk/15/pci-x/0/1/ioc4
IO9 Board: barcode NSW748 part 030-1771-005 rev -B
Location: /hw/module/001c04/node
IP59_4CPU Board: barcode RBS343 part 030-1989-003 rev -C
Location: /hw/module/001c04/IXbrick/xtalk/15
2U_INT_53 Board: barcode RBH247 part 030-1809-006 rev -D
Location: /hw/module/001c08/node
IP59_4CPU Board: barcode RBT018 part 030-1989-003 rev -C
Location: /hw/module/001c08/IXbrick/xtalk/15
2U_INT_53 Board: barcode RBX752 part 030-1809-006 rev -D
Location: /hw/module/001c10/node
IP59_4CPU Board: barcode RBT012 part 030-1989-003 rev -C
Location: /hw/module/001c10/IXbrick/xtalk/15
2U_INT_53 Board: barcode RBX743 part 030-1809-006 rev -D
Location: /hw/module/001c10/IXbrick/xtalk/15/pci-x/0/1/ioc4
IO9 Board: barcode NJJ725 part 030-1771-005 rev -A
Location: /hw/module/001r06/router
ROUTER Board: barcode NCT816 part 030-1634-003 rev -A
16 1.0 GHZ IP35 Processors
CPU: MIPS R16000 Processor Chip Revision: 3.0
FPU: MIPS R16010 Floating Point Chip Revision: 3.0
chunk 22
eration of the passive doesn't help this problem.
Where are you located?
I'm in Seattle, WA, USA.
Also likely the cheapest dealer for Fuel V10 cards will be: http://mashek.com/SGIparts/Fuel.php
I have purchased from Doug before in order to get a fuel V10 card for troubleshooting purposes. Cheapest you'll likely find, assuming you're in the United States.
--- Post by rams ---
These are in the system:
PIMM
030-1891-001 D
V12
030-1726-003 REV F
Motherboard
030-1707-003 REV H
And the spare PIMM that I have not tested is 030-1730-001 REV G
I live in Finland
chunk 22
----------------------------------------
16384 9.83 5.95 5.96 0.00 0.00 140.21
That doesn't make sense! Let's see if -D w/ 10 sec tests is consistent for a couple runs ...
Code:
[octane]:~/indy$ diskperf -W -D -n Octane_SCSI2SD -c 1G -t 10 /home/indy/testpath
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name : Octane_SCSI2SD
# Test date : Tue Apr 7 21:11:14 2020
# Test machine : IRIX64 octane 6.5 07202013 IP30
# Test type : XFS data subvolume
# Test path : /home/indy/testpath
# Request sizes : min=16384 max=4194304
# Parameters : direct=1 time=10 scale=1.000 delay=0.000
# XFS file size : 1073741824 bytes
#---------------------------------------------------------
# req_size fwd_wt fwd_rd bwd_wt bwd_rd rnd_wt rnd_rd
# (bytes) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s)
#---------------------------------------------------------
16384 1.41 6.32 1.43 6.52 1.19 5.65
^C
[octane]:~/indy$ diskperf -W -D -n Octane_SCSI2SD -c 1G -t 10 /home/indy/testpath
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
chunk 22
nd his site. He has a lot more than what he has listed on there.
Good luck!
--- Post by 7spirals ---
Amazing job of removing the solder-mask and fixing it without bleeding over on the other leads!
--- Post by 0xDEADBEEF ---
Very nice. Just installed the controller and the fan after fixing my TRAM. I attached to probe to TRAM heatsink. Couple minutes after boot it already goes into hurricane mode ;-)
I am still debating whether to use thermal paste for attaching heatsink and print some plastic clips or to keep using capton tape with thermal tape for attaching heatsinks. It seems to me the transfer of heat to heatsink is just fine, the heatsinks get pretty hot and the main problem is lack of airflow to cool everything down.
chunk 23
ly, most likely.
--- Post by Elf ---
Well, this is starting to come together.
--- Post by Silicon-Surfer ---
Slightly off topic but thanks for all your work measuring the outputs of the Indy PSUs!
I've been repairing a Nidec PSU which had a bad failure on the input circuitry due to a dead electrolytic. After replacing just about every semiconductor in the input side of the PSU, it seemed to work but I spent hours trying to figure out why the +12V output was only about 8.5V. Then I came across your measurements that the 12V output is low until loaded, and sure enough with a load mine is right on 12V.
Without your post I would probably never have figured that out...
--- Post by vvuk ---
I just grabbed an Indy with a Nidec power supply that's behaving strangely. PSU seems to be in OK shape; nothing visually wrong. The machine boots just fine if I don't connect the aux connector, but I get spammed with a stream of "power failures" during irix install because it's not getting the Pgood signal. If I do connect the header, nothing happens when I press the power key or anything else. Luckily, SGI used a boring header for this, so I have a bunch of jumper wires.
chunk 23
e/001r06/router
ROUTER Board: barcode NCT816 part 030-1634-003 rev -A
16 1.0 GHZ IP35 Processors
CPU: MIPS R16000 Processor Chip Revision: 3.0
FPU: MIPS R16010 Floating Point Chip Revision: 3.0
CPU 0 at Module 001c02/Slot 0/Slice A: 1.0 Ghz MIPS R16000 Processor Chip (enabl ed)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 1 at Module 001c02/Slot 0/Slice B: 1.0 Ghz MIPS R16000 Processor Chip (enabl ed)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 2 at Module 001c02/Slot 0/Slice C: 1.0 Ghz MIPS R16000 Processor Chip (enabl ed)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 3 at Module 001c02/Slot 0/Slice D: 1.0 Ghz MIPS R16000 Processor Chip (enabl
ed)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 5 at Module 001c04/Slot 0/Slice B: 1.0 Ghz MIPS R16000 Processor Chip (enabl ed)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 6 at Module 001c04/Slot 0/Slice C: 1.0 Ghz MIPS R16000 Processor Chip (enabl ed)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
chunk 23
ctane]:~/indy$ diskperf -W -D -n Octane_SCSI2SD -c 1G -t 10 /home/indy/testpath
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name : Octane_SCSI2SD
# Test date : Tue Apr 7 21:19:15 2020
# Test machine : IRIX64 octane 6.5 07202013 IP30
# Test type : XFS data subvolume
# Test path : /home/indy/testpath
# Request sizes : min=16384 max=4194304
# Parameters : direct=1 time=10 scale=1.000 delay=0.000
# XFS file size : 1073741824 bytes
#---------------------------------------------------------
# req_size fwd_wt fwd_rd bwd_wt bwd_rd rnd_wt rnd_rd
# (bytes) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s) (MB/s)
#---------------------------------------------------------
16384 1.42 6.33 1.42 6.55 1.19 5.65
32768 1.93 7.43 1.93 7.70 1.75 6.97
Much better ! The most consistent SCSI2SD data I've seen, with only 10s intervals!
--- Post by Elf ---
Ah, bypassing the cache? Makes sense!
--- Post by callahan ---
UPDATE:
It turns out my last post's methodology wasn't great. So, updates!
chunk 24
not getting the Pgood signal. If I do connect the header, nothing happens when I press the power key or anything else. Luckily, SGI used a boring header for this, so I have a bunch of jumper wires.
If I connect just Pgood (pin 4), system turns on as normal (and importantly I don't get the power failure any more, so the power supply is asserting Pgood correctly).
(At this point I also connected the speaker pins, because I wanted the startup chime!)
If I then add the run pin (3), system does not turn on. Ok, sure, nothing is triggering the power switch. I then connected the power switch pins. Nothing, doesn't turn on when power is pressed or held down. If I short the power switch pins, the system boots! ... but only while the power switch (9+13) remains connected. If I break the connection it immediately powers off.
I'm kind of confused. The power switch is not a switch, it's just a button; it's only going to temporarily make the power switch connection. I can believe that the switch itself is somehow dead, but even if it wasn't, I'd expect it to have the same behaviour of powering off when released that I get when I just short the connection. Any thoughts?
chunk 24
. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 6 at Module 001c04/Slot 0/Slice C: 1.0 Ghz MIPS R16000 Processor Chip (enabl ed)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 7 at Module 001c04/Slot 0/Slice D: 1.0 Ghz MIPS R16000 Processor Chip (enabl ed)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 8 at Module 001c08/Slot 0/Slice A: 1.0 Ghz MIPS R16000 Processor Chip (enabl ed)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 9 at Module 001c08/Slot 0/Slice B: 1.0 Ghz MIPS R16000 Processor Chip (enabl ed)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 10 at Module 001c08/Slot 0/Slice C: 1.0 Ghz MIPS R16000 Processor Chip (enab led)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 11 at Module 001c08/Slot 0/Slice D: 1.0 Ghz MIPS R16000 Processor Chip (enab led)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 12 at Module 001c10/Slot 0/Slice A: 1.0 Ghz MIPS R16000 Processor Chip (enab led)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
chunk 24
a I've seen, with only 10s intervals!
--- Post by Elf ---
Ah, bypassing the cache? Makes sense!
--- Post by callahan ---
UPDATE:
It turns out my last post's methodology wasn't great. So, updates!
New TL;DR: With top-tier SD cards the SCSI2SD v6 can perform better than conventional 10k and 15k RPM disks on a Fast SCSI (10MB/S) bus, except for sequential write. The quality of your SD card is very important to overall performance. Also, firmware 6.1.3 performs better (on tested SGI systems) than 6.3.0.
This update is driven by two developments. First, after getting some nonsense data from my Octane over the last week, I realized that it is critical to use the -D flag with SGI's diskperf utility. Using this flag removed variability with 10 second runs on the Indy and Indigo2 and kept my Octane from giving nonsensical results (e.g. random read speeds of >250 MB/S). Second, I bought a new top-tier SD card to compare SCSI2SD performance. The results surprised me!
Methodology notes:
I used two high-performance SD cards with identical drive images, SCSI2SD settings, and firmware.
chunk 25
lieve that the switch itself is somehow dead, but even if it wasn't, I'd expect it to have the same behaviour of powering off when released that I get when I just short the connection. Any thoughts?
I should probably connect the thermistor pin too in hopes of getting the fan to spin down some
--- Post by weblacky ---
I just repaired a couple indy Nidec PSUs, I did find ONE failed PSU power button. I did find a replacement button that works fine, I also found that when I unsoldered the button and clicked it for FUN 100+ times, I later found out the button started working again! I literally did recheck the button several times with a multimeter and provide it didn't work...yet after "playing with it". It consistently worked...
chunk 25
Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 12 at Module 001c10/Slot 0/Slice A: 1.0 Ghz MIPS R16000 Processor Chip (enab led)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 13 at Module 001c10/Slot 0/Slice B: 1.0 Ghz MIPS R16000 Processor Chip (enab led)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 14 at Module 001c10/Slot 0/Slice C: 1.0 Ghz MIPS R16000 Processor Chip (enab led)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 15 at Module 001c10/Slot 0/Slice D: 1.0 Ghz MIPS R16000 Processor Chip (enab led)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
Main memory size: 16384 Mbytes
Instruction cache size: 32 Kbytes
Data cache size: 32 Kbytes
Secondary unified instruction/data cache size: 16 Mbytes
Memory at Module 001c02/Slot 0: 4096 MB (enabled)
Bank 0 contains 512 MB (Premium) DIMMS (enabled)
Bank 1 contains 512 MB (Premium) DIMMS (enabled)
Bank 2 contains 512 MB (Premium) DIMMS (enabled)
Bank 3 contains 512 MB (Premium) DIMMS (enabled)
Bank 4 contains 512 MB (Premium) DIMMS (enabled)
Bank 5 contains 512 MB (Premium) DIMMS (enabled)
chunk 25
new top-tier SD card to compare SCSI2SD performance. The results surprised me!
Methodology notes:
I used two high-performance SD cards with identical drive images, SCSI2SD settings, and firmware.
Transcend S64GSDC500S 64GB ( amazon link ), currently ~$25. This is a good card, U3/V30 rated, listed transfer rates of up to 95 MB/s Read; 60 MB/s write. Tests with this card are sometimes shorthanded as $testsystem _T
Sandisk Extreme Pro SDSDXXY-128G-GN4IN 128GB ( amazon link ), current ~$38. This is a top-tier card, also U3/V30 rated but claims "Shot speeds up to 90MB/s, transfer speeds up to 170MB/s". Tests with this card are sometimes shorthanded as $testsystem _San
Note: Both of these are very good SD cards. If you use a more normal/bargain SD card, I would expect worse--possibly very bad--performance using the SCSI2SD.
All diskperf tests used the following command line (and relied on previously created 1GB test files): diskperf -W -D -n [description] -r4k -t 10 [$testpath]. All tests were performed with a single user logged in via ssh. The systems tested were:
chunk 26
ter found out the button started working again! I literally did recheck the button several times with a multimeter and provide it didn't work...yet after "playing with it". It consistently worked...
So try that, pull power to the Indy. Take the cover off, the click the power button...a lot...then a lot..then try it again with a multimeter. I might "come back to life". If you need it I can tell you what button I got, however it has a different plunger so I'm unsure the case button mates up yet...it meets all other dimensions and heights, but plunger design has a small hole on a center and has a square head, while the button height is the same as the old one. So I still have to test the mating be 100% confident.
--- Post by vvuk ---
Will try that, thanks! I guess I assumed that the switch was a momentary switch and not a toggle, given that it just depresses and releases, but I guess that's not the case?
chunk 26
k 2 contains 512 MB (Premium) DIMMS (enabled)
Bank 3 contains 512 MB (Premium) DIMMS (enabled)
Bank 4 contains 512 MB (Premium) DIMMS (enabled)
Bank 5 contains 512 MB (Premium) DIMMS (enabled)
Bank 6 contains 512 MB (Premium) DIMMS (enabled)
Bank 7 contains 512 MB (Premium) DIMMS (enabled)
Memory at Module 001c04/Slot 0: 4096 MB (enabled)
Bank 0 contains 512 MB (Standard) DIMMS (enabled)
Bank 1 contains 512 MB (Standard) DIMMS (enabled)
ed)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 4 at Module 001c04/Slot 0/Slice A: 1.0 Ghz MIPS R16000 Processor Chip (enabl ed)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 5 at Module 001c04/Slot 0/Slice B: 1.0 Ghz MIPS R16000 Processor Chip (enabl ed)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 6 at Module 001c04/Slot 0/Slice C: 1.0 Ghz MIPS R16000 Processor Chip (enabl ed)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 7 at Module 001c04/Slot 0/Slice D: 1.0 Ghz MIPS R16000 Processor Chip (enabl ed)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
chunk 26
ine (and relied on previously created 1GB test files): diskperf -W -D -n [description] -r4k -t 10 [$testpath]. All tests were performed with a single user logged in via ssh. The systems tested were:
SGI Indy, 180Mhz R5000 processor, 256MB RAM, IRIX 6.5.22. On this device, each test was performed with only the test drive connected (i.e. the test drive was the system and test disk).
SGI Indigo2, 175MHz R10000 processor, 640MB RAM, IRIX 6.5.22. On this device, each test was performed on the secondary SCSI controller and the test device was the only device on the bus.
SGI Octane, 2x360MHz R12000 processors, 1.5GB RAM, IRIX 6.5.30. On this device 50/68 pin drives were connected externally to the secondary SCSI controller. 80 pin drives were connected internally. The Fujitsu MAX drive was the booted/system drive for all tests (including the test of the MAX drive itself).
The drives tested were:
SCSI2SD v6, Firmware 6.1.3, Transced 64GB SD card
SCSI2SD v6, Firmware 6.1.3 and Firmware 6.3.0, Sandisk Extreme Pro 128GB SD card
Fujitsu MAJ3182MP 18.2GB 10k RPM UW-160 disk
Fujitsu MAX-series 36GB 15k RPM U320 disk
HP 3008B26C 300GB 15k RPM U320 disk
chunk 27
t.
--- Post by vvuk ---
Will try that, thanks! I guess I assumed that the switch was a momentary switch and not a toggle, given that it just depresses and releases, but I guess that's not the case?
--- Post by vvuk ---
No issues desoldering Haven’t tested it yet, but I’m surprised by the behaviour I saw (not with the switch) of the Indy powering off when I stopped connecting the power switch & switch common. That's the bit that confuses me; I'd expect it to just power on and stay on.
Everything else seems to work including thankfully the temperature sensor, so worst case I can wire up a different switch. But.. just weird. Will report when I can investigate tomorrow.
--- Post by weblacky ---
Sorry, it's hard for me to tell what's going on based on the description you gave, as I cannot tell what you've connected and what you've omitted. All I can say is:
chunk 27
. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 7 at Module 001c04/Slot 0/Slice D: 1.0 Ghz MIPS R16000 Processor Chip (enabl ed)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 8 at Module 001c08/Slot 0/Slice A: 1.0 Ghz MIPS R16000 Processor Chip (enabl ed)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 9 at Module 001c08/Slot 0/Slice B: 1.0 Ghz MIPS R16000 Processor Chip (enabl ed)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 10 at Module 001c08/Slot 0/Slice C: 1.0 Ghz MIPS R16000 Processor Chip (enab led)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 11 at Module 001c08/Slot 0/Slice D: 1.0 Ghz MIPS R16000 Processor Chip (enab led)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 12 at Module 001c10/Slot 0/Slice A: 1.0 Ghz MIPS R16000 Processor Chip (enab led)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 13 at Module 001c10/Slot 0/Slice B: 1.0 Ghz MIPS R16000 Processor Chip (enab led)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
chunk 27
rmware 6.1.3 and Firmware 6.3.0, Sandisk Extreme Pro 128GB SD card
Fujitsu MAJ3182MP 18.2GB 10k RPM UW-160 disk
Fujitsu MAX-series 36GB 15k RPM U320 disk
HP 3008B26C 300GB 15k RPM U320 disk
I've attached graphs to this post comparing sequential and random read/write tests for all drives. My key takeaways:
The SCSI2SD/Sandisk duo was fast at random reads/writes (should be no surprise). It outperformed even the 15k RPM U320 drives in the Octane at random read performance up until 32kb blocks (where the conventional drives were able to surpass the SCSI2SD's Fast SCSI transfer limit). On the Indy/Indigo2, it outperformed all drives at all block sizes.
The only clear loss for the SCSI2SD against other Fast SCSI devices was in sequential write performance , where it topped out around 4 MB/S while the 10k and 15k RPM disks were able to sustain transfers at the Fast SCSI bus limit.
chunk 28
orrow.
--- Post by weblacky ---
Sorry, it's hard for me to tell what's going on based on the description you gave, as I cannot tell what you've connected and what you've omitted. All I can say is:
1. The power button works by shorting the two CLOSEST legs/pins together on a single side/edge of the square housing of the button (NOT the ground leg/pin, it's not ground, it's body ground for shock purposes), pin pairs are on opposite sides of the button, but same elevation, they are the same pin (on each side of the button they are duplicated) and electrically connected all the time (lower R to lower L , higher R to higher L on L/R sides). So you're shorting a pair of pins to another pair (higher to lower pair). Each side of the button has half of each pair (that short together, i.e Lower R shorts to Higher R, just like Lower L shorts to Higher L when button is pressed). So when you're testing it, it needs to be the two of the legs on either side of the button that should short together only when pressed.
chunk 28
Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 13 at Module 001c10/Slot 0/Slice B: 1.0 Ghz MIPS R16000 Processor Chip (enab led)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 14 at Module 001c10/Slot 0/Slice C: 1.0 Ghz MIPS R16000 Processor Chip (enab led)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
CPU 15 at Module 001c10/Slot 0/Slice D: 1.0 Ghz MIPS R16000 Processor Chip (enab led)
Processor revision: 3.0. Scache: Size 16 MB Speed 333 Mhz Tap 0x15
Main memory size: 16384 Mbytes
Instruction cache size: 32 Kbytes
Data cache size: 32 Kbytes
Secondary unified instruction/data cache size: 16 Mbytes
Memory at Module 001c02/Slot 0: 4096 MB (enabled)
Bank 0 contains 512 MB (Premium) DIMMS (enabled)
Bank 1 contains 512 MB (Premium) DIMMS (enabled)
Bank 2 contains 512 MB (Premium) DIMMS (enabled)
Bank 3 contains 512 MB (Premium) DIMMS (enabled)
Bank 4 contains 512 MB (Premium) DIMMS (enabled)
Bank 5 contains 512 MB (Premium) DIMMS (enabled)
Bank 6 contains 512 MB (Premium) DIMMS (enabled)
Bank 7 contains 512 MB (Premium) DIMMS (enabled)
Memory at Module 001c04/Slot 0: 4096 MB (enabled)
chunk 28
2SD against other Fast SCSI devices was in sequential write performance , where it topped out around 4 MB/S while the 10k and 15k RPM disks were able to sustain transfers at the Fast SCSI bus limit.
The older 6.1.3 firmware outperformed the newest 6.3.0 release handily. I tested both with and without "turbo mode" enabled. I found turbo slightly increased most speeds, but also added variability that caused a drops at some block sizes. I've reverted my device to 6.1.3, no-turbo. My SCSI2SD config is still available on my github.
Using a SCSI2SD on a Indy/Indigo2 appears to be largely a no-brainier -- minus cost . At ~$140 for SCSI2SD v6+SD card, my current SCSI2SD setup is over twice as expensive as all of the other disks I tested combined (each was less than $20 on ebay).
On anything with a Ultra/Wide SCSI bus, the SCSI2SD probably won't make sense except for a very specific use cases (e.g. CD-ROM emulation).
SD card/firmware comparison:
Not a key takeway, but I was surprised that the SCSI2SD performed measurably better on the Octane, despite being limited to Fast SCSI speeds, which both the Indy and Indigo2 support. Any ideas why?
chunk 29
ust like Lower L shorts to Higher L when button is pressed). So when you're testing it, it needs to be the two of the legs on either side of the button that should short together only when pressed.
2. Assuming you fully connect both connections from the PSU to the Indy, I would agree that shorting what the power button shorts (above statement) should correctly turn it on and off as you intend...if you're jumping wires and not placing the entire IDC connector onto the board, I cannot say.
3. Also assuming your button failed OPEN and not closed. Closed would hold it the signal line incorrectly.
--- Post by Elf ---
Quite possible the switch contacts have just oxidized over the years as well. I would second @weblacky 's advice about testing and/or replacing the (momentary) switch. Regarding the Indy turning off when the lines are disconnected, you might look to see if there is some sort of pull-up or pull-down arrangement on the board, which could explain it. I'd check myself, but I don't have one accessible at the moment! (Not at home)
chunk 29
k 5 contains 512 MB (Premium) DIMMS (enabled)
Bank 6 contains 512 MB (Premium) DIMMS (enabled)
Bank 7 contains 512 MB (Premium) DIMMS (enabled)
Memory at Module 001c04/Slot 0: 4096 MB (enabled)
Bank 0 contains 512 MB (Standard) DIMMS (enabled)
Bank 1 contains 512 MB (Standard) DIMMS (enabled)
Bank 2 contains 512 MB (Standard) DIMMS (enabled)
Bank 3 contains 512 MB (Standard) DIMMS (enabled)
Bank 4 contains 512 MB (Standard) DIMMS (enabled)
Bank 5 contains 512 MB (Standard) DIMMS (enabled)
Bank 6 contains 512 MB (Standard) DIMMS (enabled)
Bank 7 contains 512 MB (Standard) DIMMS (enabled)
Memory at Module 001c08/Slot 0: 4096 MB (enabled)
Bank 0 contains 512 MB (Standard) DIMMS (enabled)
Bank 1 contains 512 MB (Standard) DIMMS (enabled)
Bank 2 contains 512 MB (Standard) DIMMS (enabled)
Bank 3 contains 512 MB (Standard) DIMMS (enabled)
Bank 4 contains 512 MB (Standard) DIMMS (enabled)
Bank 5 contains 512 MB (Standard) DIMMS (enabled)
Bank 6 contains 512 MB (Standard) DIMMS (enabled)
Bank 7 contains 512 MB (Standard) DIMMS (enabled)
Memory at Module 001c10/Slot 0: 4096 MB (enabled)
Bank 0 contains 512 MB (Standard) DIMMS (enabled)
chunk 29
Not a key takeway, but I was surprised that the SCSI2SD performed measurably better on the Octane, despite being limited to Fast SCSI speeds, which both the Indy and Indigo2 support. Any ideas why?
I also repeated the real-world benchmarks with the new Sandisk card and added Octane results for comparison. My key takeaway remains that in real-world tests, the performance boost with a SCSI2SD was nearly enough to make a top-spec Indy feel like a high-spec Indigo2. Emphasis on the "feel" and "nearly". Obviously it doesn't make up for the difference in raw CPU or graphics muscle. And in some workloads, the sequential write performance will still make a SCSI2SD slower than an Indy with a good conventional disk. I've attached graphs with times for various tasks. A few further methodology notes:
The Indy and Indgo2's IRIX installs are configured very similarly, but they are not identical. The Octane has a newer IRIX version and more software installed.
As before, boot time was measured from the first text on miniroot window to the visual login screen.
As before, Firefox (current nekoware version) was measured from the command to a fully rendered Google.com.
chunk 30
, you might look to see if there is some sort of pull-up or pull-down arrangement on the board, which could explain it. I'd check myself, but I don't have one accessible at the moment! (Not at home)
--- Post by GameBreaker64 ---
Are there any visible or audible signs to look out for that indicate when a Nidec PSU is dying? Or do they just go kaput with no warning?
--- Post by Elf ---
Sometimes they will whine/hiss which can certainly indicate impending failure, however I would not say that an audible indicator of failure will always be present (or is even likely to be present) for ones that are dying. The best way to tell would be electrically, or just to do preventative maintenance.
--- Post by architeuthis ---
Thanks for the detailed write-up @Elf . I have a somewhat related question: the fan in my Sony PSU is running at full speed constantly. No temperature-specific throttling is happening, even though CPU / memory / main board are barely warm to the touch.
Any idea how to start debugging this? I think I have identified the thermistor you've mentioned - it's labeled "U8" on my R5000SC CPU board. Is there a way to check if it is still "good"?
chunk 30
contains 512 MB (Standard) DIMMS (enabled)
Bank 7 contains 512 MB (Standard) DIMMS (enabled)
Memory at Module 001c10/Slot 0: 4096 MB (enabled)
Bank 0 contains 512 MB (Standard) DIMMS (enabled)
Bank 1 contains 512 MB (Standard) DIMMS (enabled)
Bank 2 contains 512 MB (Standard) DIMMS (enabled)
Bank 3 contains 512 MB (Standard) DIMMS (enabled)
Bank 4 contains 512 MB (Standard) DIMMS (enabled)
Bank 5 contains 512 MB (Standard) DIMMS (enabled)
Bank 6 contains 512 MB (Standard) DIMMS (enabled)
Bank 7 contains 512 MB (Standard) DIMMS (enabled)
ROUTER in Module 001c02/Slot 0: Revision 1: Active Ports [1,6,7,8] (enabled)
Integral SCSI controller 3: Version IDE (ATA/ATAPI) IOC4
Integral SCSI controller 2: Version IDE (ATA/ATAPI) IOC4
CDROM: unit 0 on SCSI controller 2
Integral SCSI controller 4: Version QL12160, low voltage differential
Disk drive: unit 1 on SCSI controller 4 (unit 1)
Integral SCSI controller 5: Version QL12160, low voltage differential
Integral SCSI controller 0: Version QL12160, low voltage differential
Disk drive: unit 1 on SCSI controller 0 (unit 1)
Integral SCSI controller 1: Version QL12160, low voltage differential
chunk 30
time was measured from the first text on miniroot window to the visual login screen.
As before, Firefox (current nekoware version) was measured from the command to a fully rendered Google.com.
That's it for now!
--- Post by Elf ---
Very nice data; thanks for coming back with that update
I have been going the 15kRPM disk route but it sounds like I should pick up some more SCSI2SDs...
--- Post by onre ---
Yeah, highly appreciated. Myths and claims are one thing, raw data is another.
--- Post by stormy ---
@callahan FYI I was involved with beta testing the newer firmware as the older version would corrupt data on my apple 840av. When the latest firmware was finalised it did fix the corruption issue (the entire disc partition information would be erased on installing any application in system 8) but it had quite a negative impact on performance as you have found out here. It seems that you haven't had any corruption issues with your SGI systems though which is good.
--- Post by stormy ---
Here are some results of a 15k IBM SCSI disk vs the latest firmware of SCSI2SD V6 using the atto disk benchmark. The flat line at the bottom is the SD.
chunk 31
he touch.
Any idea how to start debugging this? I think I have identified the thermistor you've mentioned - it's labeled "U8" on my R5000SC CPU board. Is there a way to check if it is still "good"?
I have a multimeter, a soldering iron, and a nonexistent background in EE, so any pointers would be greatly appreciated
--- Post by Elf ---
Ah, you could measure:
The Temperature Sensor Control Voltage on the aux connector of the power supply when the machine is on, which would tell you where along the temperature curve (in the graph earlier) the machine is claiming to be
The voltage being supplied to the fan, which would tell you whether it aligns with the control voltage provided by the machine (based on the graph earlier)
The resistance across the thermistor when the machine is off/unplugged; if the R5k CPU module is designed the same as the one I tested then it might be in that 5.3kR range at room temperature, but the resistance values might also be different if it has been redesigned
chunk 31
ntial
Integral SCSI controller 0: Version QL12160, low voltage differential
Disk drive: unit 1 on SCSI controller 0 (unit 1)
Integral SCSI controller 1: Version QL12160, low voltage differential
IOC3/IOC4 serial port: tty7
IOC3/IOC4 serial port: tty8
IOC3/IOC4 serial port: tty9
IOC3/IOC4 serial port: tty10
IOC3/IOC4 serial port: tty3
IOC3/IOC4 serial port: tty4
IOC3/IOC4 serial port: tty5
IOC3/IOC4 serial port: tty6
Gigabit Ethernet: tg1, module 001c10, PCI bus 1 slot 4
Integral Gigabit Ethernet: tg0, module 001c02, PCI bus 1 slot 4
PCI Adapter ID (vendor 0x10a9, device 0x100a) PCI slot 1
PCI Adapter ID (vendor 0x1077, device 0x1216) PCI slot 3
PCI Adapter ID (vendor 0x14e4, device 0x1645) PCI slot 4
PCI Adapter ID (vendor 0x10a9, device 0x100a) PCI slot 1
PCI Adapter ID (vendor 0x1077, device 0x1216) PCI slot 3
PCI Adapter ID (vendor 0x14e4, device 0x1645) PCI slot 4
IOC4 firmware revision 83
IOC4 firmware revision 83
IOC3/IOC4 external interrupts: 2
IOC3/IOC4 external interrupts: 1
HUB in Module 001c02/Slot 0: Revision 2 Speed 200.00 Mhz (enabled)
HUB in Module 001c04/Slot 0: Revision 2 Speed 200.00 Mhz (enabled)
chunk 31
though which is good.
--- Post by stormy ---
Here are some results of a 15k IBM SCSI disk vs the latest firmware of SCSI2SD V6 using the atto disk benchmark. The flat line at the bottom is the SD.
--- Post by stormy ---
And here is the faster SD performance on the old firmware
--- Post by stormy ---
@aperezbios good point - the fast firmware which cause corruption on 68k hardware was 6.2.15. The fixed firmware, but much slower, was 6.3.0. Interestingly with 6.3.2 the option:
"Add new config option to enable blind writes to improve SD card write performance. This was option was previously enabled default but causes problems with some SCSI hosts. This option must be disabled on 68K Macs if there are errors when writing data."
Has been added. This fast writes is what was removed during my beta testing. I guess the option is safe on certain hardware and worth the risk. On my Quadra 840AV internal SCSI any writes would corrupt the entire partition with that enabled.
--- Post by stormy ---
My results from my Octane 2x400, SCSI2SDv6 rev F, firmware 6.4.11 / SD card used: Sandisk Ultra 64gb v10 80mb/s
SCSI-Util settings:
SCSI Terminator: ON
SCSI Speed Limit: Sync 10MB/s
chunk 32
; if the R5k CPU module is designed the same as the one I tested then it might be in that 5.3kR range at room temperature, but the resistance values might also be different if it has been redesigned
All in all though it may not be worth debugging, you might want to just connect the fan directly to 12V with some sort of speed controller and set it to your taste. If you set it to a speed with reasonable airflow it will usually be faster than the Sony supply will spin it anyways.
--- Post by architeuthis ---
Well, I just opened up the PSU and even to the untrained eye *this* didn't look quite right... It certainly was an easy fix though.
But now that Indy is all nice and quiet again, I hear quite a bit of static noise coming from the built-in speaker every time I move the mouse and with certain GPU operations. I expect this to be an RF shielding issue somewhere... ?
--- Post by Elf ---
Looks like someone did the always-on fan mod prior to you receiving it
chunk 32
/IOC4 external interrupts: 2
IOC3/IOC4 external interrupts: 1
HUB in Module 001c02/Slot 0: Revision 2 Speed 200.00 Mhz (enabled)
HUB in Module 001c04/Slot 0: Revision 2 Speed 200.00 Mhz (enabled)
HUB in Module 001c08/Slot 0: Revision 2 Speed 200.00 Mhz (enabled)
HUB in Module 001c10/Slot 0: Revision 2 Speed 200.00 Mhz (enabled)
IP35prom in Module 001c02/Slot n0: Revision 6.210
IP35prom in Module 001c04/Slot n0: Revision 6.210
IP35prom in Module 001c08/Slot n0: Revision 6.210
IP35prom in Module 001c10/Slot n0: Revision 6.210
vortex 2#
--- Post by nondem ---
The weather model runs at midnight and can't be manual done for several reasons so I won't know for sure till tomorrow AM...BUT
afaict it looks fixed. If you guys can think of anything else I should do please let me know.
AND THANKS IN A HUGE WAY! You guys may have saved my bacon.
--- Post by CiaoTime ---
Looks like you're up and running! Looks great. And if that system ever gets decommissioned, do try to hold onto it! That thing's a beauty, and it wouldn't be difficult to add a graphics option to it if you'd ever wanted one of the fastest IRIX desktops left in the world to play with.
chunk 32
by stormy ---
My results from my Octane 2x400, SCSI2SDv6 rev F, firmware 6.4.11 / SD card used: Sandisk Ultra 64gb v10 80mb/s
SCSI-Util settings:
SCSI Terminator: ON
SCSI Speed Limit: Sync 10MB/s
Startup Delay: 0
SCSI Selection Delay: 255
Enable Parity: ON
Enable SCSI2 Mode: ON
(all other settings are default/off)
NOTE: To get the SCSI2SDv6 Rev F to work internally it required 5v molex power.
using diskperf settings by @callahan :
Code:
--- Post by ghost180sx ---
Stormy, those don't look like very impressive numbers, but the SCSI2SD card is limited to 10MB/s sync right? So actually for reads, you're getting close to max theoretical of the interface board which is nice.
Does the system feel faster? Do you use it for boot and daily use? Is there any way of measuring the sequential and random access seek times? Just curious...
--- Post by ghost180sx ---
I just love how at blocks around 32k and up, you are virtually maxing out the 10mbit interface in all directions: forwards, backwards and random! Crazy!
It's not the 40mb/s that you can get with Ultra SCSI, but hey, that's gotta be fun to play with!
chunk 33
move the mouse and with certain GPU operations. I expect this to be an RF shielding issue somewhere... ?
--- Post by Elf ---
Looks like someone did the always-on fan mod prior to you receiving it
Regarding the static: possibly, or just the power supply or something on the motherboard getting old (electrolytics drying out etc.), where varying current draw will cause some noise and sag. It might be worth looking at what the rails are doing, ideally on a scope, or at least measuring the AC component while this is going on. At that point one could also probe around the audio amplifier.
--- Post by nintendoeats ---
How's this going Elf? It looks gorgeous, I'd be happy to put one in my better Indy.
--- Post by Elf ---
Hi! It is a low priority project for me so I haven't touched it in months, unfortunately.
--- Post by bitpak ---
@Elf Hi Elf! Can you explain how did you managed to run the PSU without connecting it to the motherboard, please?
I have a Nidec that needs to be recapped and tested (while being disconnected from the rest of the system) so I'm trying to understand the logic and the sequence of what voltage goes where after you connect the PSU to the AC..
chunk 33
oned, do try to hold onto it! That thing's a beauty, and it wouldn't be difficult to add a graphics option to it if you'd ever wanted one of the fastest IRIX desktops left in the world to play with.
Sixteen 1ghz processors. Wow. And here I thought I had a hot machine with only eight 800's!
--- Post by Unxmaal ---
I'm calling dibs on one of those 4x1GHz nodes.
Also @nondem take a look at the packages we have available for sgug-rse . There's a lot of very fresh ports for IRIX available -- new gcc, new python, so forth -- that can make your life as a sysadmin easier.
--- Post by nondem ---
So, I'd like to take a minute to defend my obvious ignorance here
I became responsible for this box about a year and half ago. There is no backup/failover system, no docs beyond the ones for the original system from SGI, no one to ask anything till I found you guys.
The box is used for smoke plume prediction and runs the model every night to base the next days plumes on as I mentioned earlier. Burn Permits for various purposes are approved based on the predicted plume the this box returns based on the weather model it creates every night.
chunk 33
virtually maxing out the 10mbit interface in all directions: forwards, backwards and random! Crazy!
It's not the 40mb/s that you can get with Ultra SCSI, but hey, that's gotta be fun to play with!
--- Post by Jinroh ---
@callahan Thank you for all of the data. This was the what I needed to decide to want to jump for a SCSI2SD for my Indy. :3
--- Post by architeuthis ---
For comparison: I just ran some performance tests with an ACARD SCSI to IDE adaptor (AEC-7720UW) plugged into a IDE-to-SATA adaptor, plugged into a 120 GB Kingston SSD on my R5k Indy.
The results look pretty good - I don't think it can get much better on a Fast-SCSI bus. Especially random reads - not surprisingly - perform pretty well.
Code:
--- Post by massiverobot ---
Adding in some more data points.
First, the best marks:
Code:
--- Post by seclorum ---
This is a very interesting thread - thanks for all the hard work to research the details and for sharing a good assessment of the situation.
chunk 34
be recapped and tested (while being disconnected from the rest of the system) so I'm trying to understand the logic and the sequence of what voltage goes where after you connect the PSU to the AC..
--- Post by toncho11 ---
Hi @Elf ,
How is the project for the new Indy power supply going?
I have one power supply that does not work and one that does. I think they both need to be recapped.
But maybe building your new power supply is a better idea?
--- Post by CRaven ---
Keep us posted I would like to buy one.
--- Post by erikarn ---
hi @Elf , any chance of an update? or would you be willing to share the designs so we can continue it along?
I just acquired an indy with a dead nidec power supply. One of the two on-board 250mA glass fuses immediately blows, so my guess is some semiconductor isn't working right and the switchmode isn't switching.
I'm going to need to crime up something locally in the short term with an ATX power supply to see if my Indy does boot and run, but I would like a longer term solution that doesn't cost $400 on ebay
Thanks!
chunk 34
se the next days plumes on as I mentioned earlier. Burn Permits for various purposes are approved based on the predicted plume the this box returns based on the weather model it creates every night.
It runs an old "MM5/Hysplit" model on the SGI system and it needs to be retired obviously. We are moving to the newer "WRF" model which has source code that is supported under Linux.
I couldn't dig into the box because I didn't have any docs from the previous admins to work with and couldn't risk causing it to go down even for a minute. It is like trying to work on an ambulance while it was driving down the road w/someone heading to the ER. I just left it alone and put my effort into a replacement.
About a year ago, I bought two identical Dell x86 boxes using the recommendations of people experienced with the new WRF model. Lots of processor cores and memory. The second one will be a failover when we get it in prod.
chunk 34
the best marks:
Code:
--- Post by seclorum ---
This is a very interesting thread - thanks for all the hard work to research the details and for sharing a good assessment of the situation.
I'm using SCSI2SD not just for my SGI gear, but also other systems too - Yamaha A-samplers, Powerbook, a couple other retro-computing items too boring to mention - so I have an interest in the SCSI2SD firmware, from the perspective of 'how does it work' and 'can it be optimized' somehow.
I see a lot of use of unlikely() / __builtin_expect throughout the code, which raises a bit of alarm bell. Its just a little too judicious. So .. I want to set up to build the SCSI2SD firmwares ..
Does anyone else have a working build of the SCSI2SD Firmware, meanwhile?
--- Post by stormy ---
Old thread but I wanted to add my results using a BlueSCSI v2 (with pico2) on an Indigo2 r4k.
SD card used (makes a big difference) Sandisk Extreme Pro 300mb/s v90.
Code:
chunk 35
ght two identical Dell x86 boxes using the recommendations of people experienced with the new WRF model. Lots of processor cores and memory. The second one will be a failover when we get it in prod.
Our meteorologist built the model on the one of the new boxes and we put it in test shortly after. Months have went by in testing with dozens of other hot issues but it's very close to being ready. But not quite...I tried moving it to prod today since the plume wasn't working anyway and that unconvered a couple of problems in the windoze desktop app that renders the plumes. So I guess that is a couple of good things that came out of this crisis.
This is why I'm the sysadmin for a box I have no business being admin on.
I got handed two Sun Sparc systems at the same time as this one and have already retired them...this is the last thorn in my side.
--- Post by massiverobot ---
Are you in the DC area? Is this for NOAA?
chunk 36
t handed two Sun Sparc systems at the same time as this one and have already retired them...this is the last thorn in my side.
--- Post by massiverobot ---
Are you in the DC area? Is this for NOAA?
--- Post by weblacky ---
Yeah, seriously. SGI collectors are a dedicated bunch. I only collect workstations (not big Iron like these) but if you know any other stations or business using these and they are "retiring" them. Please let us know. Many companies are either trashing these great systems or parting them out hoping to screw over other business needed last-minute parts. I'm missing several SGI workstation models so I'm still on the prowl. I've been collecting SGIs since 1998! I still haven't collected them all (3 remaining). So please let groups know if stuff is available to keep these machine out of the hands of recyclers who ruin them.