The collected works of jan-jaap - Page 15

Yup, 32A single phase 220VAC. Search 'google images' for an IP44 typ223 plug. You want the blue one (2P + earth, the red ones are 4P + earth and are 3 phase).

My 4D380/VGX Predator rack has the same plug, and I just made a couple of extension leads for my APC 7953 rack PDUs, they have the same plugs. Be careful when you mess with this stuff or it will set your house on fire. I think you need to use at least 4mm neoprene cable to wire this, although 6mm may be required for 32A.

The good news it that it probably won't consume anywhere near 32A. If you remove the 3rd OLS it is possible to convert it to 110VAC. You may have to remove some boards to reduce the power load to be able to run on 2 OLS's.

I hope you're just using clean water and no soap, salt etc. ?

Onyx2 Infinite Reality3
4*500MHz R14K, GE16-4, 2*RM10-256. IRIX 6.5.30



13" MacBook Pro, 'Early 2011'
2.3GHz Core i5, Intel HD Graphics 3000, OSX 10.7.5, XQuartz 2.7.4




Ah well, any excuse to fire up the Onyx2

I think he's using a NUMA cable rather than the 'router jumper' normally found on desksides.

OK, you have configured a working DNS server in /etc/resolv.conf. Name resolution using DNS works...

... but are you using DNS are a source for host name resolution? Other sources (LDAP, NIS, files, ...) exist too.

Your sources are configured in /etc/nsswitch.conf. This is how mine looks:

The crucial bit here is:

Host name resolution tries NIS first, then DNS, then files (/etc/hosts)
Most people can probably eliminate 'nis' here, and/or swap the order of the 'files' and 'dns' entries.

Hey, AutoCAD 12 (and 13) even existed for IRIX

The midplane is configured for 180MHz nodeboards.

You have to toggle one or two jumpers, see: http://www.vdheijden-messerli.net/sgist ... .02-onyx2/

A couple of random observations & tips:

* Try to keep a healthy nodeboard and one bank of RAM in slot N0 in the system and put the hardware under test in slot N1. With a working nodeboard you should eventually reach POD whatever is in the other slots.

* With a RAM-less nodeboard in N1 you will eventually reach POD (if you have a working node in N0). But it takes ages (20 - 30 minutes?). This allows you to recover disabled nodes, flash the PROM of the secondary nodeboard, or flash CPU speed parameters in it. It will still try to test all RAM you put in, so put in the least you can.

* 256MB RAM banks were supported in 250MHz and faster nodes. But IIRC there's a minimum PROM rev. for them. You've got downrev PROM warnings, and 256MB banks?

* PROM version mismatches are an endless source of misery.

If I were you, I would:

1. Fix that 90/100MHz midplane speed selector.

2. Install the newest IRIX you have with a good nodeboard and one bank of RAM. This gives you a working config for flashing firmware. Flash the good node and the IO6G to the last rev. (6.156 I think). Congrats, now you have a functional system to work from.

3. Add a secondary nodeboard. With or without RAM. It may take a while and it may disable bit left and right, but you still have a working system capable of booting IRIX and flashing the secondary board if needed.

4. If a 250MHz node with the last firmware still won't recognize the 256MB bank, the first bank may be bad (bad contact, or otherwise broken). If you add another bank of RAM, it can swap banks 0 and 1 and use bank1 as the first bank.

5. Origins can accumulate loads of fine black dust. You could try to clean the memory slots with compressed air, clean the DIMMs with alcohol, and install/remove DIMMs still 'wet' from the alcohol in the slot in an attempt to clean them.

Forget what I said about 256MB banks, looks like you have 128MB banks.


Need more coffee

Be careful: the Challenge/Onyx uses HVD SCSI internally. That's *high* voltage diff and will destroy SE or LVD disks!. Usually the first scsi channel (on the primary IO4) is HVD, the second channel SE (for CD-ROM, tape, ...), and the rest mostly HVD again.

The IO4 has one daughter card per scsi channel. red=HVD, green=SE. All disk sleds are jumpered for SE or HVD operation and must match the channel(s) they are on. Finally, there are terminators and SE/HVD selector jumpers on the backplane of the drive cage.

So, it is possible to convert an Onyx/Challenge to SE operation if you know what you're doing. I did this with my deskside Power Challenge, and posted some pics here: http://www.vdheijden-messerli.net/sgist ... challenge/

Looks like I was wrong about SCSI0 and SCSI1, btw: my Onyx claims to have SE SCSI0 and DF SCSI1 (sticker on the inside of the drive bay door). And the IO4 looks like that too:

scsi0 = green = SE, scsi1 = red = HVD.

Both IR and VPro allow 12bits/component color (48-bit RGBA). Most other graphics systems are only 8bits/component. Not sure the default display modes are set up for either of these, and I don't think DVI allows more than 8bits so you're stuck with analogue outputs.

'incomplete base history' usually means you've freed up disk space with 'versions removehist' or similar. In that case you need the openssl software from the distribution CDs before you can install a patch.

S o ftware -> S h ort Product Names


While you're at it, tick P anes-> C ommand as well and you can treat swmgr like inst

You need two software components: the 'base' software (the package Recondas referred to) and the matching overlay software from your 6.5.30 discs (overlay disc #2, 'unbundled' directory).

HP might have nuked OpenVMS, but its parent, PDP-11, is still spry and powering GE nuclear power-plant robots and will do for another 37 years .

Couple of random thoughts:

* Does the DIVO show up in 'hinv' and '/usr/dmedia/binDIVO/divohinv'?
* Did you run the DIVO hardware diagnostics ?
* In some ways DIVO works different than other video options because it connects to system memory, not the graphics system. man(7) divo refers to avcapture(1) "to store large volumes of audio and video data in realtime" . Maybe worth a try?

Compressor air has tiny oil particles in it. Not what you want on your PCBs. Oil-less compressors exist, but they still use oil, you just don't need to refill during it's lifespan it so I guess (hope?) it doesn't spray tiny oil particles around. Special oil free compressors for electronics manufacturing exist, but they probably come at a price.

I use a soft brush to clean PCBs, and a regular vacuum cleaner to clean out the (empty) chassis. Occasionally I use a can of compressed air to blow the dust out of a PSU or other object I don't feel like opening.

I'm happy with mine . But I use it as a compile/compute/storage server, not a wannabe Tezro. I keep it in a server room, so the noise isn't bothering me and I can run it 24.7 without worrying about the power/airco bill

It's hosted at $WORK of course

Make that 4U (two modules). Of course current hardware offers an order of magnitude more speed and storage within the same space/power constraints. An O300 / O350 / Tezro may be recent by MIPS/IRIX standards, it still is nearly 10 years old. I'm not recommending anyone use such an old system in production unless you have no other choice (and a healthy supply of spares).

Well, in this case it is. 4TB hanging of an LSI SAS/SATA controller in the 2nd module of the O350 . This system is hosted at work, but that doesn't make it the company file server. Most of the storage is used by the FLAC files for the office stereo system.

My O350 also serves as a regression bot. This is why the company is hosting it. Before that I used a Fuel (1x500Mhz), that was a joke. Couldn't keep up. Replaced with a 2x600MHz O300. At some point the O300 was > 80% busy running the regression tests if people were committing frequently and sometimes the next regression job would kick in before the previous had finished. Makes a big mess of our build dash. The O350 (8x700MHz) doesn't break a sweat and has enough time left to do whatever I feel like doing.

Of course our Makefiles are crafted to keep all CPUs busy all the time.

BTW I wasn't trying to diss people who convert an O350 to a gfx workstation. I'm just saying that *I* still have a niche where an O350 can be useful. Once it stops being useful, it will be retired and join the rest of the museum.

Just putting the pieces together

UNIX linkers are single-pass linkers . You have to put the libraries which resolve symbols on the command line *after* the object code which uses them. You put the objects at the end of the command line so their undefined symbols will not be resolved. Also, adding an include path to the library path isn't going to do much because there (hopefully) aren't any libraries there. '/usr/lib32' is path of the standard library path for N32. I think you can reduce it to this:

IRIX 6.2 doesn't have snprintf(), you'll have to code a replacement.

The three GL functions require OpenGL 1.1 or newer and aren't documented for IRIX 6.2 so you probably don't have them. Anything with textures is going to be real slow on an Indy anyway.

ProPack 4, SP3 to be precise.


SUSE released an SLES9 SP4 , but I don't know is it's compatible with ProPack4 SP3

Another thing worth knowing for those playing with the Altixes: you can still get the Intel IA64 compiler (free for non-commercial use). Here's how:

* Go to the Non-Commercial Software Development page at Intel. Sign up for the current x86/x86_64 Linux Compose XE package.
* You will receive a license file and a download link.
* The license file works for Linux x86/x64 *and* ia64:

* The download page contains an option to download "Additional downloads, updates and versions".
* The current product (Composer XE) doesn't support ia64 any longer. You want Intel C++/Fortran Compiler 11.1, Update 9.

I have not tried this myself yet (no Itanium hardware), but the procedure works fine with a new key, the 11.1 compilers, on x86_64.

The release notes of the various ProPacks refer to the then-current Intel compilers (v8.x, ... v10.x) so maybe you want to install an older compiler if 11.1 gives trouble.

It is defined by POSIX, but the implementation is optional .



_SC_MONOTONIC_CLOCK is to check at runtime whether CLOCK_MONOTONIC exists using sysconf(). It is POSIX, 2003 . IRIX is POSIX anno 1995 . The check should simply return FALSE if _SC_MONOTONIC_CLOCK is undefined because in that case CLOCK_MONOTONIC isn't going to be available.

This should make the code compile and make sysconf() return false:


CLOCK_MONOTONIC is 'good enough' to measure time increments rather than the absolute time. IRIX has a similar clock: CLOCK_SGI_CYCLE. If the code really needs a cycle timer you can cook up replacement code using CLOCK_SGI_CYCLE.

Yes. Written a couple of years ago, still maintaining it.

Yes (Linux, Windows, several PPC based vxWorks platforms, some special purpose in-house RTOSes and a couple others).

I wouldn't choose IRIX as the platform for 'my first device driver'. IRIX isn't all that different from e.g. Linux but the necessary information can be a little harder to find and due to the closed nature of IRIX you cannot inspect the code behind the published interfaces.

But really, the concepts of device drivers are pretty universal. The constraints imposed by the platform/OS vary, but in the end you have to implement these bits:

* device registration.
* PIO or memory mapped register I/O
* interrupt handling
* uncached memory manangement for DMA
* interrupt handling
* implement an interface to user space, or to protocol layers

... and FWIW I'd do it in that order. The OS provides primitives to implement these functions and in case of IRIX they are documented on Techpubs and in to 1000+ page Device Driver Writer's Guide . In the case of IRIX, the PCI bus can sometimes be a little oddball because the PCI bus is never the primary system bus and the PCI-XTalk interface can impose some limitations (or amplify effects you wouldn't have noticed on another platform), but really the essentials are all there.

Try to keep your code clean, modular and elegant because (depending on the platform), debugging options beyond 'kprintf' can be a hard enough to be not worth bothering. Apply copious amounts of assert(). And *know* the hardware you're talking to.

SGI documentation here: http://techpubs.sgi.com/library/tpl/cgi ... /ch04.html

Basically, the drive cage (and its disk sleds!) is wired to two SCSI channels. Each sled has thus two SCSI connectors, JA and JB, and depending on which connector you plug your device into, it shows up on the first or second SCSI channel.

Each SCSI channel in turn, can be configured for SE or HVD operation. This is done with the green or red daughter cards on the IO4, the terminators and jumpers on the drive cage backplane. The jumpers on the sleds must match this configuration. As a result the same jumper configuration must be set on all sleds .

The sleds themselves exist in two flavors: narrow and wide. Here's two from my Onyx IR :

To the left a HVD hard disk, configured as scsi(1,1). To the right an SE SCSI CDROM, configured as scsi(0,6)

So: SCSI0 is SE, SCSI1 is HVD. This is the default configuration and yours is likely configured like that as well.

Here's a closeup of the sled holding the hard disk:


Notice how the (wide) SCSI cable is connected to JB, the 2nd SCSI channel.

The configuration is done with the jumper block between the connectors. Actually, it's two jumper blocks, H1 (left, fully populated with 4 jumpers) and H2 (right, half populated with two jumpers).

IIRC, H1 sets SCSI channel A, and H2 sets SCSI channel B. Fully populated (H1, left, SCSI0) means SE. Half populated (H2, right, SCSI1) means HVD.

This particular disk sled has an original, HVD disk installed. If I wanted to install a more modern SE or LVD disk, easiest would be to simply move the 68pin flat cable to JA and leave the SCSI setup unchanged. The disk would show up on SCSI0, but that doesn't matter.

Originally, the SCSI device ID of the disk is set using a selector on the front of the disk. This connects to the jumper block on the actual disk. Unfortunately, these jumper blocks are absolutely not standardized, so you probably want to ignore it and simply set the relevant jumpers on the disk.

If you want to change an entire SCSI channel from SE to HVD or vice versa you must change IO4 daughter card(s), terminator(s), and all relevant jumpers at the same time or risk the release of magic smoke left and right. HVD and SE SCSI don't mix well! I documented some of this work here: http://www.vdheijden-messerli.net/sgist ... challenge/

Edit: moved advanced stuff to the end

I'll split up this post in the two categories of noise you mention:

Fan
The O2 dates from ~ 1996. Back then most computers were loud(er), but a lot of progress was made in fan technology. The Noctua could very well move the same amount of air as the original fan with much less noise (I didn't check, though). Anyway, the original fan must be 15 years old by now and the bearings must be dry or worn out so your O2 is now probably louder than it was when it was new.

The O2 fan runs at a fixed, full speed and was designed to provide enough airflow to cool:
* The mainboard
* Maximum conversion losses (heat) in the PSU. So under maximum PSU load.
* The fattest CPU an O2 could possibly hold. An R12K puts out a lot more heat than an R5000, and maybe it was designed for en even hotter running CPU?
* Maximum RAM.
* 1600SW/dual display daughter card.
* Maximum power dissipation (per PCI standard) for one PCI slot. I could check, but IIRC it's at least 25W.
* A healthy margin to avoid overheating even a fully loaded system.
* All of that at an unknown ambient temperature which is probably higher than what you have in a normal house/office.

In other words, if you know you've got a cool running CPU, half populated memory banks and no PCI card, and you don't lock it up in a closet, you can probably get away with (a bit) less than original airflow without roasting the internals. If you can limit power consumption you win twice because (due to relatively low efficiency of the oldskool PSUs) you will also reduce heat generated inside the PSU.

Also, modern day PC's are quiet, but only when cool. The fan speed is dynamic and fan control (and the noise) will kick in if the system runs hot. Isn't there a decent fan with dynamic (temperature dependent) speed, all builtin? You could enjoy the silence without worrying about overheating.

Disk
If you were hoping to netboot the O2 from that NAS dongle: forget it. IIRC, to netboot an IRIX system, you need at least bootp support, TFTP to load the kernel and NFS for the rest. Even if you have a full blown Linux system available, it requires kernel tweaks. This thing serves the disks up using FTP and SMB protocols -- rather useless for an O2.

Diskless operation in general is slow, due to the latency introduced by the network stack and the 10MB/s throughput limit. There's only one thing more hateful than a diskless UNIX system, and that's swapping over the network

As for the SSD:
1. The O2 only boots from Adaptec 2940 chips (or ethernet).
2. SCA SSDs exist but they are very, very expensive.
3. SCA-to-2.5"-SATA adapters exist, and would allow you to install a regular SSD in the original disk sled. If the SCA-SATA adapter does the conversion properly, then it's just another SCSI disk as far as the O2 is concerned and there's no reason it wouldn't boot. While a lot cheaper than SCSI SSD's, the price of these adapters is still such that I'm not going to verify that claim myself

About the SCSI parity errors: could be a disk, could be wiring or incorrect termination.

You were talking about a disk on the 50pin connector of the sled, but is it a wide disk with some adapter? I don't think that's possible, because both controller and disk are 'wide', will try to negotiate wide, except half the lines is missing because there's a 'narrow' cable in between.

Termination is on the disk backplane. I don't think jumper settings are documented anywhere, but I kept a couple of shots of my (deskside) Challenge when I converted the 2nd channel to SE. They are here: http://www.vdheijden-messerli.net/sgist ... challenge/ (high res available on request)


You also have a message about illegal RM4 termination on the screen. Onyx RM4's don't need terminators, but Crimson/PowerSeries did. I think you'll find that at least one RM4 has a bunch of resistor packs installed close to the backplane connector. You could do without them, and possibly make someone happy who's trying to upgrade a Crimson.

Oh, and is that rack always that 'naked'? I can see the RM4 from the outside, that's got to affect the airflow. If you like the naked look, mount a sheet of perspex but try to cover that hole. RM4's are fragile enough as it is ...

PS: I like the industrial looks of that rack. That's the one from sunhelp 'rescue', right?

Somehow this never happened...

I'm pretty sure it would have failed, though:

IO9 contains an IOC4 chipset, and a pair or QL12160 chips. IRIX and PROM contain support for both IOC4 and QL12160.

IO10 contains an IOC4 chipset, and a "Vitesse Semiconductor VSC7174 PCI/PCI-X Serial ATA Host Bus Controller". The IOC4 may (or may not) work, but to the best of my knowledge neither IRIX not PROM support the Vitesse SATA chip.

The VSC7174 is limited to 1.5Gb link speeds, and IIRC there were other performance issues with either the IOC4 or the VSC7174.

I think it's better to stay with one of the supported LSI SAS/SATA controllers.

I couldn't if I wanted to. They turn on by themselves, day or night, at speeds > 160kph ...

Probably this post . But again, it only talks about Altix / Prism (aka Dorado) systems. Nothing MIPS/IRIX based.