The collected works of bri3d - Page 1

So, I had a unique problem yesterday.
I only had Install Tools Supportfolio overlay sets, not real CDs.
And the Install Tools overlay sets don't have a stand directory, and therefore don't have fx.
So I did a little poking around, and learned that fx can be found in the eoe set.
The problem? I don't have a working IRIX host at the moment, so I found myself without inst.

So I did a little looking.
For each distribution set there's a simple .idb file which contains, in plaintext, offsets and compressed sizes (CMPSIZE).
Then, the .sw file contains the data associated with each file, compressed using the oldschool BSD compress utility (the one from the 80s).
So all you've got to do is:
1) Open up the .idb file in a text editor, and search for the file you're looking for (telling fx from fx64 takes a minute, because fx64 is also named just fx, but you can figure it out). Find the OFFSET= and CMPSIZE= lines.
2) Go to this OFFSET (it's in bytes) in the .sw, using a hex editor. Look for the filename (it should be a few bytes after the OFFSET= value).
3) Copy out CMPSIZE bytes *AFTER* the FILENAME (the area you're copying, if you're doing it right, should start with 1f 9d, the magic numbers for compress files) into a new file with extension .Z i.e. fx.Z (be *sure* to copy and count bytes starting from 1f 9d / right after the filename, NOT right after the offset, or you'll get a truncated file. uncompress will still uncompress it without error, and then you'll be in a world of confusion as everything barfs on a file you thought was correct).
4) Run uncompress on the .Z file you just got.

Ta-da! There's a file, extracted from a .sw/.idb distribution set. Not *too* hard, was it?
Fastest SGI MIPS CPU ever, plus a V10! Still looking for a V12... but too broke to buy any :(

hinv:

Code: Select all

4 1.0 GHZ IP35 Processors
CPU: MIPS R16000 Processor Chip Revision: 3.0
FPU: MIPS R16010 Floating Point Chip Revision: 3.0
Location: /hw/module/001c01/node/cpubus/0/a
CPU 0 at Module 001c01/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
Location: /hw/module/001c01/node/cpubus/1/a
CPU 1 at Module 001c01/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
Location: /hw/module/001c02/node/cpubus/0/a
CPU 2 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
Location: /hw/module/001c02/node/cpubus/1/a
CPU 3 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
Main memory size: 4096 Mbytes
Instruction cache size: 32 Kbytes
Data cache size: 32 Kbytes
Secondary unified instruction/data cache size: 16 Mbytes
Location: /hw/module/001c01/node/memory
Memory at Module 001c01/Slot 0: 2048 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)
Location: /hw/module/001c02/node/memory
Memory at Module 001c02/Slot 0: 2048 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)
Integral SCSI controller 3: Version IDE (ATA/ATAPI) IOC4
CDROM: unit 0 on SCSI controller 3
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)
Disk drive: unit 2 on SCSI controller 4 (unit 2)
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)
Disk drive: unit 2 on SCSI controller 0 (unit 2)
Integral SCSI controller 1: Version QL12160, single ended
IOC3/IOC4 serial port: tty3
IOC3/IOC4 serial port: tty4
IOC3/IOC4 serial port: tty5
IOC3/IOC4 serial port: tty6
IOC3/IOC4 serial port: tty7
IOC3/IOC4 serial port: tty8
IOC3/IOC4 serial port: tty9
IOC3/IOC4 serial port: tty10
Graphics board: V10
Gigabit Ethernet: tg1, module 001c02, PCI bus 1 slot 4
Integral Gigabit Ethernet: tg0, module 001c01, PCI bus 1 slot 4
Iris Audio Processor: version EMU revision A4, number 2
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
PCI Adapter ID (vendor 0x1102, device 0x0004) PCI slot 1
PCI Adapter ID (vendor 0x1102, device 0x7003) PCI slot 1
PCI Adapter ID (vendor 0x1102, device 0x4001) PCI slot 1
PCI Adapter ID (vendor 0x1033, device 0x0035) PCI slot 2
PCI Adapter ID (vendor 0x1033, device 0x0035) PCI slot 2
PCI Adapter ID (vendor 0x1033, device 0x00e0) PCI slot 2
IOC4 firmware revision 83
IOC4 firmware revision 83
IOC3/IOC4 external interrupts: 2
IOC3/IOC4 external interrupts: 1
Location: /hw/module/001c01/node/hub
HUB in Module 001c01/Slot 0: Revision 2 Speed 200.00 Mhz (enabled)
Location: /hw/module/001c02/node/hub
HUB in Module 001c02/Slot 0: Revision 2 Speed 200.00 Mhz (enabled)
Location: /hw/module/001c01/node/prom
IP35prom in Module 001c01/Slot n0: Revision 6.210
Location: /hw/module/001c02/node/prom
IP35prom in Module 001c02/Slot n0: Revision 6.210
USB controller: type OHCI
USB Human Interface Device: device id 3 type keyboard
USB Human Interface Device: device id 1 type mouse
USB Human Interface Device: device id 2 type keyboard
USB controller: type OHCI
USB Human Interface Device: device id 1 type tablet


and gfxinfo

Code: Select all

Graphics board 0 is "ODYSSEY" graphics.
Unmanaged 1280x1024
BUZZ version B.1
PB&J version 1
32MB memory
Banks: 2, CAS latency: 3


recondas also asked me if I could post some more info since it's quite a unique beast - so without further ado-

serial all:

Code: Select all

Data                            Location      Value
------------------------------  ------------  --------
Local System Serial Number      NVRAM         M1234567
Reference System Serial Number  Attached L2   M1234567
Local Brick Serial Number       EEPROM        NGLxxx
Reference Brick Serial Number   NVRAM         NGLxxx


EEPROM      Product Name    Serial         Part Number           Rev  T/W
----------  --------------  -------------  --------------------  ---  ------
INTERFACE   2U_INT_53       NGL666        030_1809_005          A    00
IO9         IO9             NST803         030_1771_005          B    00
ODYSSEY     ASTODYB         MLV782         030_1725_001          F    00
RISER       2U_RISER        NRP608         030_1808_006          B    00
NODE        IP59_2CPU       NMM411         030_2059_002          A    00
SNOWBALL    no hardware detected
PS 1        no hardware detected
PS 2        DPS-500EBE      XPD0514006096  060-0178-003          S4

EEPROM     JEDEC-SPD Info           Part Number        Rev  Speed  SGI
---------- ------------------------ ------------------ ---- ------ --------
DIMM 0     7F7FFE000000000012003413 CM2203B1            2     8.0  N/A
DIMM 2     7F7FFE000000000012003412 CM2203B1            2     8.0  N/A
DIMM 4     no hardware detected
DIMM 6     no hardware detected
DIMM 1     7F7FFE000000000012003417 CM2203B1            2     8.0  N/A
DIMM 3     7F7FFE000000000012003416 CM2203B1            2     8.0  N/A
DIMM 5     no hardware detected
DIMM 7     no hardware detected


env:

Code: Select all

001c02:
Environmental monitoring is enabled and running.

Description    State       Warning Limits     Fault Limits       Current
-------------- ----------  -----------------  -----------------  -------
1.8V    Enabled  10%   1.62/  1.98  20%   1.44/  2.16    1.763
12V <not present>
12V #2    Enabled  10%  10.80/ 13.20  20%   9.60/ 14.40   12.000
3.3V    Enabled  10%   2.97/  3.63  20%   2.64/  3.96    3.320
12V IO    Enabled  10%  10.80/ 13.20  20%   9.60/ 14.40   11.938
5V AUX    Enabled  10%   4.50/  5.50  20%   4.00/  6.00    5.044
3.3V AUX    Enabled  10%   2.97/  3.63  20%   2.64/  3.96    3.268
PCI 5V AUX    Enabled  10%   4.50/  5.50  20%   4.00/  6.00    5.044
PCI 3.3V    Enabled  10%   2.97/  3.63  20%   2.64/  3.96    3.285
PCI 2.5V    Enabled  10%   2.25/  2.75  20%   2.00/  3.00    2.483
PCI 5V    Enabled  10%   4.50/  5.50  20%   4.00/  6.00    4.966
XIO 12V BIAS    Enabled  10%  10.80/ 13.20  20%   9.60/ 14.40   12.000
XIO 5V    Enabled  10%   4.50/  5.50  20%   4.00/  6.00    4.966
XIO 2.5V    Enabled  10%   2.25/  2.75  20%   2.00/  3.00    2.470
XIO 3.3V AUX    Enabled  10%   2.97/  3.63  20%   2.64/  3.96    3.320
IP59 3.3V AUX    Enabled  10%   2.97/  3.63  20%   2.64/  3.96    3.285
IP59 5V AUX    Enabled  10%   4.50/  5.50  20%   4.00/  6.00    5.044
IP59 12V    Enabled  10%  10.80/ 13.20  20%   9.60/ 14.40   12.000
IP59 VCPU    Enabled  10%   1.14/  1.40  20%   1.02/  1.52    1.297
IP59 SRAM    Enabled  10%   2.25/  2.75  20%   2.00/  3.00    2.483
IP59 1.5V    Enabled  10%   1.35/  1.65  20%   1.20/  1.80    1.480

Description     State       Warning RPM  Current RPM
--------------- ----------  -----------  -----------
FAN  0  EXHST 1    Enabled         1980         2311
FAN  1       PS    Enabled         3200         5192
FAN  2    PCI 1    Enabled         1980         2721
FAN  3    PCI 2    Enabled         1980         2556
FAN  4      ODY    Warning         1679            0
FAN  5  N0 LEFT    Enabled         1980         3191
FAN  6  N0 CNTR    Enabled         1980         2857
FAN  7 N0 RIGHT    Enabled         1980         2970

Advisory   Critical   Fault      Current
Description       State       Temp       Temp       Temp       Temp
----------------- ----------  ---------  ---------  ---------  ---------
0 INTERFACE 0       Enabled    [Autofan Control]    70C/158F   43C/109F
1 INTERFACE 1       Enabled    [Autofan Control]    70C/158F   45C/113F
2 INTERFACE 2       Enabled    [Autofan Control]    70C/158F   34C/ 93F
3 PCI RISER         Enabled    [Autofan Control]    70C/158F   36C/ 96F
4 ODYSSEY           Enabled    [Autofan Control]    70C/158F   44C/111F
5 NODE              Enabled    [Autofan Control]    70C/158F   37C/ 98F
6 BEDROCK           Enabled    [Autofan Control]    70C/158F   51C/123F

Zone Temp     Target    Current   Zone Fan   Curr/Min
Zone Name  State     Sensors       Average   Average   Index      Fan %
---------  --------  ------------  --------  --------  ---------  ---------
NODE        Enabled     0,1,2,5,6  47C/116F  42C/107F          0   18%/ 18%
PS          Enabled     0,1,2,5,6  47C/116F  42C/107F          1   55%/ 55%
PCI         Enabled             3  45C/113F  36C/ 96F        2,3   55%/ 55%
ODY         Enabled             4  48C/118F  44C/111F          4   55%/ 55%


In addition, I discovered something new about the Origin 350: It can have one of three types: Chimera Server (Origin350), Chimera Blade (Onyx350 IP?) - happens when V10 is inserted, and Rackmount WS (I assume this is a Tezro) - Activated by inserting the V10 and running "make rmws 1" on the L1.

This status can be viewed from the brick command, for example:

Code: Select all

rack: 001, slot: 01, partition: none, type: Rackmount WS [2MB flash], serial:NGLxxx, source: EEPROM
rack: 001, slot: 02, partition: none, type: Chimera Server [2MB flash], serial:NRTxxx, source: EEPROM


I was wrong - Rackmount WS sytems *can* learn serials from L2s - as long as the serial begins with a P rather than an M. Thanks to recondas for noticing this.

When a headless O350 has make rmws 1 set on it, its type is still "Chimera Server" but it gains the ability to also accept a P-prefix, allowing it to be linked to a headed system for a NUMA-linked Tezro. Sadly I think this configuration won't extend beyond 2 systems due to r-brick serial security - but I may be proven wrong again. I don't have an R-brick or enough O350-bricks to test with.

Details on the V10 hack can be found at: viewtopic.php?f=3&t=16719768 for the curious.
Hahah man, I could have avoided going thru this entire process...

I guess you learn about a new tool every day :)
For those that don't know, I managed to mess my O350s up something amazing:

viewtopic.php?f=3&t=16719038

Thankfully I should have an L2 on the way soon and I'll be able to fix everything up (still looking for the L2 emulator, though, because it'd be nice to have around)...

Anyway, attaching a pic...
I'll benchmark the crap out of it as soon as I get it working again (whenever the L2 arrives... should be this week or early next...)

The L2 speed discrepancy is curious... I wonder why they did that, maybe the L2 barely doesn't run at 500Mhz or something so they had to use divisor 3 instead of 2 (that's totally stupid if it's true though)...

I might be getting IR4 for it as well (although it would probably end up being IR2 since part of me getting the IR4 involves selling the RM and getting a cheaper one)... we'll see how that goes.
Glad to see you got that beast up, pretty nice graphics too. :)

Agreed, though, you should try to distribute the memory as evenly as possible so that some CPUs aren't starved for RAM. Even memory distribution works best for most workloads.
Pretty... shame it doesn't have any logos on it. The debadged look isn't so good for the Fuel (or SGIs in general), imo.
Broadcom still make workstation-class multicore mips64 CPUs, but the interconnects are far more modern and so I doubt they could be shoehorned into SGI hardware. Irix could be ported to them though, if the source was ever to be released. Rumor has it it may have even been done internally at some point.

For now though, I think the MIPS Inc 1ghz r16000 is the fastest we'll see in sgi hardware.

_________________
:0300: <> :0300: :Indy: :1600SW: :1600SW:
They're baack!

Got my L2 controller hooked up (after finding the power pinouts) and gave them new serials - running like a charm.

NUMALink still won't work though - I blame my cable; it's a NUMALink cable from Origin 2000, and I think NUMALink 3/4 cables might be different somehow. The L1s see each other and * pwr on from one L1 will power up both (even without the L2 involved or connected), but when the PROM probes NUMALink it just says "Network down" and only finds one node (itself). I've tried clearing partitions and everything but to no avail :(

Weirdly there's nothing about any kind of NUMALink error in any error log... you'd think that if I had a bad cable it either a) wouldn't work at all or b) would error somewhere, but instead it just works until the PROM tries it, then silently doesn't find the other system.

Here's what the L2 and L1s have to say:

Code: Select all

Iceberg-001-L2>cfg s
L2s: 1
L1s: 2
C Bricks: 2

Iceberg-001-L2>cfg v
L2 192.168.1.103: - 001 (IR 80a80167, C 00000000) (LOCAL)
L1 192.168.1.103:1:0     - 001c02     (b2;p1;d2 /dev/sgil1_1)
L1 192.168.1.103:1:5     - 001c01     (b2;p1;d2 /dev/sgil1_1)
L1 192.168.1.103:0:0     - 001c01     (b1;p1;d2 /dev/sgil1_0)
L1 192.168.1.103:0:5     - 001c02     (b1;p1;d2 /dev/sgil1_0)

001c01-L1>cfg v
:0  * 001c01 (local)
:1  - not connected    (attached I/O)
:5  * 001c02 (attached C)
:6  - not connected    (attached I/O)

001c02-L1>cfg v
:0  * 001c02 (local)
:1  - not connected    (attached I/O)
:5  * 001c01 (attached C)
:6  - not connected    (attached I/O)



So the L1s and L2 are definitely communicating amongst themselves properly - the L2 sees both L1s, the L1s see each other as attached C-bricks via NUMALink, and all should be well.

But when I issue a pwr up, everything appears to be working until...

Code: Select all

Local hub NUMAlink is down.
*** Local network link down


And then both PROMs operate independently of each other and the systems don't acknowledge their connection (which confuses the crap out of the L2 system console function as well).
Well, like I said, I did, and the plugs fit, and it halfway works!

Basically once the pins on the side of the "huge" NUMALink 3 port are removed the "little" NUMALink2 cable will fit. And my O350s, for some reason or another, arrived with the pins in plastic baggies instead of actually screwed into the port, thus why I was able to plug my NUMALink2 cable in.

And, like I said, the L1<->L1 communication works, just not the whole transferring data part xD
JacquesT wrote: I believe the Fuel V12 won't work in the Octane XIO slots. But I could be wrong...but think not!


You're right. The Fuel V12 also doesn't just "work" in Origin 3xxx or 350 - even with an XIO brick. You need a special (and unbelievably rare) InfinitePerformace V-Brick to use it with these systems.

So basically the Fuel V12 is for Fuel, and not much else.
schleusel wrote:
bri3d wrote: So basically the Fuel V12 is for Fuel, and not much else.

and Tezro..


:oops: yeah
Judging from the inside of my O350s, there's nowhere to put a Fuel-style V12 (or anything but PCI cards, for that matter)... I just don't see where it'd fit. Do you know if the InfinitePerformance O350s had a special backplane as well?
OK - well that explains where it fits, but, like you said not how it connects... I think there must have been some kind of differing backplane option, unless someone with an O350 is seeing something I'm missing (I do tend to be blind sometimes ;) ).
hmm... hinv doesn't have any extra parts over my system listed beyond the ODYSSEY -

Maybe I didn't look closely enough last time I opened it up; I think I'll try that now.

The ability to put a V12 in my system without having to find anything *too* rare would be very cool.
Huh? Here's the inside of my O350s - that's pretty clearly the connector for a Tezro/Fuel-style V12, but how would a V12 occupy the same space as the node box (that's the box to the bottom/left of the picture; I know that the blower at the top is removable)?

I *really* want to see the inside of Performance now - did they rearrange the inside of the system or what?

UPDATE: Just had another theory - my system is IP59 / R16K @ 1GHz; maybe 1Ghz O350 was never produced with graphics, and the node box is bigger.

If someone has pics of the inside of another O350 from this angle or especially one with V12, I'd appreciate it.
Read down the whole thread to learn how this was done - basically if you can make an ODYSSEY board physically fit into an Origin350, it'll become an Onyx350 InfinitePerformance.

Hey - kind of hijacked this thread with questions about this earlier... found some more information though, so I thought I'd compile everything I've learned thus far here:

Moderator Edit: Merged the related posts from the topic mentioned above to consolidate the subject matter. <recondas>

The Origin 350 seems to have a slot for a V12 ODYSSEY graphics card, with connection that looks very similar to that used in Fuel and Tezro. SGI made a supported config, the Onyx 350 InfinitePerformance that had this slot filled with a V12. However, the V12 used in this slot had a part number which differed from the V12 in Fuel and Tezro.

My Origin 350s, dual 1Ghz R16ks, seem to be physically unable to take the ODYSSEY card - the (slower) Origin 350 shown here: http://www.nekochan.net/wiki/gallery2/v/SGI_ ... G.jpg.html , seems to have space around the slot to fit a card, whereas mine, shown in the attachment, seems to be lacking enough room to throw a V12 in.

So the remaining information I'd like is:
    Pictures of the inside of an Onyx 350 with a V12, just for reference purposes on how it slots in / fits...

    Anyone who's tried putting a Fuel or Tezro V12 in an Onyx or Origin 350 - does it work, or is that part number difference really significant?

    Any information on a 1Ghz Onyx 350 - I think maybe with the giant metal box around the node board removed, a V12 might fit even in my 1Ghz, but removing the metal box requires quite literally taking apart the entire system (it's obvious SGI *really* didn't want this done - there are screws that can only be removed by unseating the entire CPU + memory board assembly, removing it from the case, and taking it apart). Was there perhaps a model made with a different metal box?

I think as more Origin 350s show up on eBay/auctions/craigslist and in the hands of eager Nekochanners, we'll start to see a lot more interest in this subject - an Origin 350 with a V12 would be basically a very cheap Tezro...

I'm going to try buying a Fuel/Tezro V10 (as they're dirt-cheap) and somehow shoehorning it into my system (I think if I take the entire system apart, I can get that gigantic metal box off of the node board, and then if I can invent some alternate cooling I think I can make the board fit - it'll be a pretty complex project but nothing especially dangerous), and seeing if it works (the chances are lower, since V10 in O350 was never a supported SGI config, but we'll see...)
recondas wrote:
japes wrote: Do you mean InfinitePerfromance? Not UltimatePerformance.
I'm pretty sure he did, UltimatePerformance is truly a horse of a different color - it's ATI based.


I actually just totally butchered it, I think, the ATI thing is UltimateVision. D'oh.

Anyway, there seem to be a variety of "Fuel/Tezro" V12 part numbers listed as well, so maybe it's just different board revisions of some sort - does anyone know the difference between any of these in the first place?

Code: Select all

Silicon Graphics   030-1726-003   Fuel/Tezro V12 Graphics Board; 128MB - 030-1726-003
Silicon Graphics   030-1726-004   Fuel/Tezro V12 Graphics Board; 128MB - 030-1726-004


Like I said, I'm just going to buy a V10 in the coming weeks, put it in there, and see what happens - as long as it doesn't fry my O350, which I see no way it will (unless I goof up the cooling mods I'm going to need to make), I'm happy with whatever outcome I get... we'll never learn anything if nobody tries :) I know my chances are better with a V12, since it was the real supported config, but V10s are extremely cheap, since they came standard config in Fuel and Tezro so they're not an upgrade, wheras V12s are still several hundred USD.

loonvf wrote: Does the Origin350 have possibilities for keyboard and mouse?

Via an NEC USB OHCI controller in a PCI slot, yep, just like Origin3xxx. Audio, too, via one of the IRIX-supported audio cards (M-Audio Revolution, Audigy2 ZS, etc.). If this graphics mod works I'll have a pretty nice workstation setup - basically a cheap Tezro :)

loonvf wrote: In the end someone else on this forum solved it
by adding a PCI card with keyboard, mouse & ethernet card to it and then it worked.
Also replacing the IO6 by an IO6G did the job.

I'm actually running one of these setups right now (Origin2000, CADDuo in a PCI carrier, and SI graphics) - nice job pioneering it :)

loonvf wrote: So maybe we can do this trick again and convert Origin350s into Onyx350s
Please keep us updated!


Will do, I think the differences are even less significant between Origin350 and Onyx350 - as a matter of fact, I think Onyx350 InfiniteReality was quite literally Origin350s with different text on the case, since you can hook an Origin350 up to a G-Brick and obtain an Onyx350 just fine this way.

It's interesting to see the Tezro though, I'm beginning to thing that maybe Tezro rackmount was just a rebranded Onyx350 IP... the cooling setup in that looks very different from mine though (ducts over the RAM and an open box over the CPUs to let air blow all the way over the graphics), so I think my suspicions about having to take apart my node box and redo the cooling are 100% correct (thankfully, it's not too hard, SGI just made it a pain by putting half of the mounting screws on the bottom of the board, so I have to remove the board from the case).
I'm pretty pleased with Windows 7 - but it's years too late.

Windows 7 is what Microsoft should have released as Vista - it's basically a reliable, stable, solid version of Vista. So, I quite like it, and I plan on running it daily, but it's not exactly a tour de force from MS or anything, since it's long overdue.

There's not much reason to run it over XP right now, and if I didn't like being on the bleeding edge I'd stick to XP. It's certainly a *huge* upgrade from Vista, though, and once more apps start requiring Vista/7 only features like DX11 and silly Presenter stuff, it'll be a must-have, and not a terribly crappy one either (unlike Vista).
Quantum disk is always loud - Quantum Fireballs were the standard for low-end workstations with SCSI for years, and they're some of the most notoriously obnoxious drives ever manufactured. I'd go with a new Seagate - they're quite quiet. Pretty much the newer the drive is the quieter it will be, with a few exceptions.
japes wrote:
sybrfreq wrote: ok, I want one now ;)


No you don't. You think you do, but you don't.

Unless you need graphics, hold out for a half rack. Actually I'd love a half rack prism, altix or onyx 4, from a looks standpoint.

Seriously though, moving a full rack is a pain.


Quoted for truth. So much truth.

The only kind of huge rack stuff I have any desire for after having my O2Ks is an Onyx of any sort - having a G-Brick would be worth the space.
recondas wrote: The differences in heat dissipation and exhaust fan capacity is probably the reason the L1 env output <and fault temperatures given> for the headless and IP graphics systems are different. The When an Odyssey board is detected the L1 uses a different table of fan speeds, temps and thermal zones.


The different fan speeds and thermal zones are almost certainly due to the Odyssey - but the different thermal cutoffs are probably to do with that I have my L1 in High Altitude mode (as I'm at altitude). I have another chassis with no Odyssey, and altitude mode can be toggled - so I'll check all that when I get home.

UPDATE: The altitude setting moves all of my fault thresholds *down* by 5C - so high altitude's fault is at 70C and low altitude's is at 75C.

My system without the ODYSSEY has the same environmental thresholds - so it might be PROM versions or it might be the Autofan thing.
Cool - yeah, if someone gives me some EEPROM dumps I can probably sort things out - I've got some experience with goofing around with EEPROMs, and I can't imagine they're very obfuscated.

BTW - some marginally relevant info from the LinuxMIPS Wiki - there's a Number in a Can on the card, I doubt it's used to identify model though. Ideally we'll never have to touch those controller init registers (SDRAM initialization usually sucks enough to be hard to disassemble, so I'm hoping we can just convince the driver that the card is a V12 at the lowest possible level and then let the driver do the rest).

LinuxMIPS wrote: There is also a standard issue SGI MicroLAN controller at 0x0010dc used to identify the card through its NIC. Equally unsurprising is the set of XIO widget registers at 0x000000. There are also some other registers, still unknown, that are extensively utilized during the initialization sequence and are probably related to SDRAM controller initialization. Possibly also DMA is realized in these registers.


Re: hacking - LOL as well, you make it sound like a bad thing! Sure, it's a "hack" per se, but no licenses are being violated and nothing is being illegally transferred - there's nothing wrong with (or illegal about) using this hardware to its fullest potential!
This is what I hope to turn my O350/Onyx system into - all I'm missing is my NUMALink cable (on the way), a V12 (to replace my V10), and a DM3 (I probably won't end up getting one, as I don't have much use, but...) and I've got it :p

@indyman007 - would probably be used as a Discreet system in "the real world" - there's not much else that uses a DM3 and that much power.
hamei wrote: DM3 is the SDStationOEM ?


Pretty sure that was DM6 - the DM3 is XIO, not PCI. There was some speculation that DM3 might also be a DVE product but as far as I know only SGI ever sold XIO cards, so I doubt they ever directly sold any.
Interesting - your Onyx350 has plastic airflow guides over the RAM while my Origin350 didn't. I would say it might be CPU-configuration dependent, but I just took a quick look and TechPubs also shows Origin350s always having no RAM covers and Onyx350s always having them. Weird.

Anyway nice job on the install - I still haven't gotten around to reworking my rear cover, so you did a far better job than I :)

Let us know how the environmentals hold up - I see there are fewer fans in that system.
Welcome to the club! - I might be trying some of your cooling ideas later on :)

_________________
:0300: <> :0300: :Indy: :1600SW: :1600SW:
Someone needs to get a V12 in one of these - I think that might be part of how the PROM and software recognizes the difference - I know, for one, that Discreet licensing recognizes my system as a "fuelv10"

Gerhard Lenerz's SGIStuff table lists Onyx350, Onyx4 (this was the UltimateVision configuration), Tezro, and Origin350 as having the exact same IP numbers - I'm guessing the recognition is just based on the graphics option, since it seems to be the only solid difference between them.

_________________
:0300: <> :0300: :Indy: :1600SW: :1600SW:
nekonoko wrote:
bri3d wrote:
Someone needs to get a V12 in one of these - I think that might be part of how the PROM and software recognizes the difference - I know, for one, that Discreet licensing recognizes my system as a "fuelv10"


That's probably the key - Tezro never shipped with a V10 so it makes sense in that respect.


The Tezro was codenamed Chimera, and so is the O350 (according to PROM settings).

In addition, there's a PROM flag to switch between a "ChiBlade" and a "Rackmounted Workstation" (which seems to have no effect on my system - I've tried both settings and they stick but don't seem to do anything) - so I think we've got it.

Now someone just needs to grab a V12 and try it!

_________________
:0300: <> :0300: :Indy: :1600SW: :1600SW:
mapesdhs wrote:
Anyway! Back to more cheery things. Any more upgrades planned for Iceberg?

Ian.


Not at the moment. Money is tight as I move on July 15, so I get to join the fantastic rent paying real world.

Upgrades I am looking in to eventually include a V12, (this is top priority as it would let me drive my displays at a decent resolution, but is also the least likely as it is the most expensive), getting a router and some O300s for fun, and getting a DM3 (mostly for completeness, although I am teaching myself Discreet software I really would have nothing to connect it to, my HD camcorder to Final Cut to Flame workflow is working well as is ).
hamei wrote:
bri3d wrote: Upgrades I am looking in to eventually include a V12, (this is top priority as it would let me drive my displays at a decent resolution, but is also the least likely as it is the most expensive) ...

There's the incentive for more eeprom investigation ! You probably have 99.5% of a V12 right now.


Nope - my V10 has only 32MB of RAM chips, and not 128MB like some other V10s that have been spotted. So converting mine would be quite an ordeal at best, and impossible at worst.

I'm still interested in investigating, though - I just don't have any of the required hardware, I can do software only.
Alternatively you can just encode sections of the video simultaneously - that's what I do on my PCs. Just split the video into x chunks of total/x frames where x is the number of CPUs, and tell each mencoder which frames to do. If you want to get really fancy you can even pick the nearest full-screen change (that would require a full frame anyway) so you don't even lose any compression performance.

_________________
:0300: <> :0300: :Indy: :1600SW: :1600SW:
Even my quad-1Ghz r16k system can't play back H.264 1080p (the most common format for it), because the decoder isn't properly optimized. It'll do uncompressed, but there's no way the external I/O on an O2 is fast enough for that, much less the graphics/bus/CPU layer.

_________________
:0300: <> :0300: :Indy: :1600SW: :1600SW:
Bump - as is detailed in the first post in this thread, recondas helped me find out that my theories regarding make rmws 1 and serial security were incorrect. make rmws 1 (and the Rackmount WS) type *do NOT* prevent the system from taking L2 serials - they just need a new prefix, the letter P instead of M.
The systems can then be NUMALinked to each other with matching P serial numbers.

So now I have a pretty Tezro Rackmount Workstation! :)
hamei wrote:
bri3d wrote: So now I have a pretty Tezro Rackmount Workstation! :)

Does that mean that Tezro owners could choose the Onyx3 Infinite Performance supercomputer option ?


Tezro Rack owners, with an L2 controller probably could - I see no reason they couldn't. Not sure what benefits you gain and it does require a serial change, but I bet it's doable. I don't think anyone here has a Tezro Rack, though, at least I've never seen one posted.
I'm about 95% sure that TestDisk is designed for x86-MBR systems, and not SGI disklabels, so it wouldn't be a port, but rather a rewrite.

The listed XFS support appears to be for Linux XFS on an MBR-based disk, not IRIX XFS (they differ, sometimes significantly) on a disklabel-based disk.

_________________
:0300: <> :0300: :Indy: :1600SW: :1600SW:
Nekochan runs fine - why mess with something that works?

vB tends to scale better in my experience, and for those early years when the phpBB developers seemed to have missed 99% of coding practice and not getting SQL injected via every single file, it was a far more stable and secure option. At this point, phpBB has matured to the point that it's not a liability to run it, and it's free and seems to be working fine for Nekochan.

vB might be a little faster, scale a little better, or be a bit cleaner-coded, but unless there's a plugin you want or something, I don't see a reason to spend $180 and try to do a migration.

_________________
:0300: <> :0300: :Indy: :1600SW: :1600SW:
My first PC was also an Aptiva - the older 486 model though.
I don't know where it ended up - there's a system with no skins in my parents' garage that I suspect might be it. I think it might even have gotten 16M of RAM in it at some point.

_________________
:0300: <> :0300: :Indy: :1600SW: :1600SW:
Or an enhancement in hardware rendering.

There's no reason that widgets should slow Flash down on as badly as they do even a rudimentary GPU - even embedded platforms like the iPhone and the PSP's GU are perfectly capable of handling some transparent overlays, and they should only need to be rendered once.
The problem is that in order to support different browsers Flash needs to run in a control context that varies greatly, which makes it really hard to use the GPU properly when there's no consistent way to get a GL/video API of choice context. That's also why the browser has a huge effect on Flash performance - if you don't get what I mean try to grab a Windows box and run Flash in IE8 and then Firefox. Prepare to be amazed.

Anyway as far as the PowerBook goes I'm going to go against the consensus here and say it's not a great idea - Mac OS X will soon stop supporting these systems, and it's really hard to avoid updating OSX (I had a friend swear he'd hang on to Tiger forever on his G5... that lasted about 4 months until he needed a newer version of some app!). The only alternative OSes that would run on one would be Linux or some kind of *BSD - and at that point why not just get some used x86 kit of similar quality, like a used ThinkPad?

If you especially love the formfactor, case, or looks (and I must admit - they are a pretty solid machine!) it becomes more of a toss-up though...
silicium wrote:
As the DM/VBOB costs cannot be avoided


Not *strictly* true - Flame will run fine without one. Then you just need a different capture/acquisition solution (I go 720p off my cheap camera kit to TIFF sequences, which is ghetto but works fine), which if you're using non-SDI kit you would need anyway.

The thing is finding a licensed system without one, if you want to stay on the licensing straight-and-narrow.

_________________
:0300: <> :0300: :Indy: :1600SW: :1600SW: