The cpus are:cpu 0 is /hw/module/001c01/node/cpubus/0/acpu 1 is /hw/module/001c01/node/cpubus/0/bcpu 2 is /hw/module/001c01/node/cpubus/1/acpu 3 is /hw/module/001c01/node/cpubus/1/b

The nodes are:node 0 is /hw/module/001c01/node [Tezro]

The topology is defined by:

/hw/module/001c01/node/xtalk/0/link -> /hw/module/001c01/IXbrick

A few photos - some have said they don't care for the tower Tezro's case design, and I wonder if that partially due to the fact most photos are taken head-on. Now that I've seen one in person, I don't think most photos accurately depict the visual strength of the design. I found the Tezro's most striking feature to be it's proportions - particularly the less often seen profile:

Sitting on an SGI short-rack - Fuel in the foreground.

Multi-processor versions of the Tezro have 8 PCI slots (the single processor version only 4). The mandatory main I/O controller board (IO9) occupies the first PCI slot (towards the top of the case). The IO9 is essential for proper system operation, leaving 7 expansion PCI slots. The power supply is to the top left, DVD drive to the right. The DVD drive is an IDE/ATAPI Matsushita SR-8588-C. The vertical black object to the right is the fan wall that holds fans to cool PCI expansion boards and the V12 graphics board. The V12 is located below the PCI slots inside the rectangular metal cooling shroud. Between the top of the V12 cooling shroud and the bottom PCI slot is an XIO2 connection header for the optional DM3 HD video capture board.

The Processor node board. The processors are under the perforated metal box/shroud. The diagram on the shroud shows four processors, but that's not a reliable indicator of the actual number. Dual and quad processor Tezros up to 800MHz use the same shroud, the shroud over 1GHz processors is taller to accommodate larger heat sinks (there wasn't a 900MHz Tezro processor). At the top left is the hard drive bay with SCA backplane - it will accommodate two low profile SCSI hard drives. At the top right is the I/O daughter card. The red arrow indicates the position of the node board part number label - the most reliable method to determine type and number of processors installed .

Just in case you ever need to tell an eBay seller where to find the part number so you figure out which and how many processors are in the system or node board he's selling.

Looks like the 800MHZ nodes generate a little more heat. After a few hours of run time I noticed the temps reported by an 'L1 env' were several degrees C warmer than these nekonoko posted for his Tezro.

To make the comparison a little more balanced I ran the 800MHz Tezro overnight with the same amount of RAM and number of PCI boards as nekonoko's Tezro <though I'm clearly short of whatever heat nekonoko's DM3 generates>. Here's the fan and temperature portion of nekonoko's Tezro:

If the temperature increases were anywhere near proportional to the speed increases of the R16 processor, it's easy to see why SGI more than doubled the size of the heatsinks on the 1GHz IP53 node boards <though I'm sure adding another 12MB of processor scache played into that too>.

While cleaning and setting up my Tezro I noticed I could lower the ambient operating temperatures of the processor nodes, bedrock ASIC and V12 5C to 7C simply by leaving the front skin off of the Tezro. As a result I decided to take a look at what could be easily done to lower the overall long-term operating temperatures with the full set of skins installed. My initial concern was the V12. There have a been a few posts on nekochan by Tezro owners that suggest their V12 died <I say suggest because none included a follow up>, and I wondered if those failures might be heat related <especially since the Fuel and O350/V12 report significantly lower operating temps for their V12s>. Might be only a coincidence, but I also noticed SGI included an <unused> three-pin fan header on the Tezro version of the V12 that isn't present on the Fuel version of the V12.

As a test I installed a low-rpm/low decibel 80mm fan on top of the metal shroud that encloses the V12, using the perforations in the shroud as attachment points for the rubber anti-vibration fan mounts.The fan is positioned directly above and blows air onto the V12 heatsink. The result was a 10C/18F reduction in the temperature the L1 reports for the V12. I don't have a DM3 installed - a Tezro with a DM3 would have a limited amount space to install a fan using this method, though there looks to be sufficient room to attach a radial fan to the underside of the V12 shroud <laterally positioned between the heatsink and bulkhead>, with the fan exhaust directed at the bulkhead.

Emboldened by the success, I took a look at the bedrock and node temps reported by the L1. The 1GHz versions of the Tezro include three 60mm fans positioned just to the front side of the node board cooling shroud. There's more than enough room to install fans in that same location. I didn't have any 60mm fans <nor did any of the sources local to me>, but I did have two 38mm fans pre-wired in a two-fan array with a molex-splitter power attachment. For initial testing I zip-tied the 38mm fans to the perforated metal shielding, directly in front and blowing onto the perforations in the node board cooling shroud, and made an air duct so that air was directed into the openings in the node board shroud <rather than the dead air space above the shroud. The molex splitter was connected at the <molex> power feed for the hard drive backplane <located directly above the node board>. The 38mm fans are only rated at 4.5CFM each <I plan to order three 12CFM-each low-DBA 60mm fans as replacements>, but made a noticeable 6C/11F drop in the operating temperature of the bedrock a ASIC. Here's the output of an L1 env run after 24 hours of continuous runtime and several hours of heavy use:

The "HD" temp reported in the table appears to actually the node temp , scsimon actually reports the hard drive temp as 29C. SGI probably intended for the HD fan to assist in cooling the node board <the HD fan pulls air across the hard drives and blows air onto the RAM end of the node board>.

Quick tip: Hot ar is less dense than cold air, that's why baloons go up So, if you put a fan on TOP of anything, make it PULLING air and not BLOWING. It will have a higher CFM if you keep the normal flux of air.

Tabalabs wrote:Quick tip: Hot ar is less dense than cold air, that's why baloons go up So, if you put a fan on TOP of anything, make it PULLING air and not BLOWING. It will have a higher CFM if you keep the normal flux of air.

I considered that, but in this case pulling air up from the heatsink would disrupt the front to rear air flow of the V12's existing fans - as well as dump hot air into the PCI card cage rather than out the exhaust vents in the chassis for the V12.

Not to mention that blowing air across the cooling fins on the heatsink isn't uncommon behavior for CPU and GPU cooling fans.

Got around to installing the DM10 drivers, and connected a firewire memory card reader. Just in case someone else might find a walk through of the process helpful, here's a summary.

The pseudo-DM10 is a generic firewire 3-port PCI board (two external, one internal FW ports with a TI chipset), the firewire memory card reader is a Microtech CameraMate. The compact flash memory card used is a 1GB SanDisk and the IRIX version is 6.5.30.

Installing the DM10 drivers requires a reboot (the kernel is rebuilt). As the system rebooted the following appeared in the boot messages (and was written to the syslog):

fwprobe (supplied with the DM10 driver package) returned the following info: Addendum - I later installed the DMediaPro D10 version 1.1 *beta*, which despite being a beta, seems to offer some improvements. fwprobe now fully identifies the generic FW board as a DM10. With DM10 version 1.0.1 the 'Model' and 'Proto' fields were both listed as unknown, after installing the DM10 1.1 beta version, fwprobe now identifies the pseudo-DM10 Model as 'DMediaPro DM10' and Proto as 'HBA', and it eliminated boot-time error messages that occurred as the 1.0.1 release scanned the FW bus:

There was an entry for the compact flash card under /hw/rdisk/1394 (the specific identification string, "30e00100001419", will be different on every system). I was able to manually mount the compact flash card that was in the card reader using:

and was able to open, edit and save one of the jpg files (back onto the CF card). It's worth noting the IRIX mounts of "DOS" file systems didn't progress beyond FAT16, which means using 2GB cards or smaller.

Was also able to hot-swap the compact flash card by unmounting the CF card with (use caution with my version of this command if you have more than one dos file system mounted),

then inserted a different CF card and successfully mounted and accessed the second CF card (using a repeat of the mount command from above).

The Microtech CameraMate has a single compact flash slot, I was able to mount a 2GB SD card using a CF-to-SD adapter.

I've also done some preliminary testing with a an external firewire hard drive. fx is able to 'see' the 250GB hard drive installed in the enclosure (the enclosure uses an Initio chipset rather than the Oxford chipset that has worked for others), but I haven't attempted to put a xfs file system on the drive (it currently holds the TimeMachine backup for one of my Macs). As soon as I pick up another PATA hard drive to install in the enclosure I'll try fx and report back.