The collected works of recondas - Page 13

Nolis wrote: Hey all my disks are original from SGI with release date and serial number on !!! So means that I already paid for it, and I just lost 2 disks of it... just want to get it done.. ! I mean this is just old stuff and not a new distribution, by the way it's just working to SGI.. so I also had to buy a SGI for it right ?

A single individual provides, maintains and pays out of his personal pocket for you (and everyone else) to have access to the largest repository of freely available SGI information and technical support in the world. In return he asks that you abide by just a few user guidelines, one of which is not making requests to pirate, buy sell or trade commercial software on this forum.

So at this point the issue isn't where or how you obtained your copy of IRIX, but whether you intend to respect the rules of the forum.

Have you tried making those adjustments with the IRIX Audio Control Panel ?

agkbill wrote: Maybe this is the way it works with this sound card and the Fuel, I do not know.

Good point - can (or have you) tested it in a PC?

smj wrote: I was pointed at the older Audigy cards and warned off the Audigy 2s. The Fuel (IP35) Hardware Aggregator indicates either the Audigy or Audigy 2 ZS should work, but notes that the 2 ZS requires IRIX 6.5.25 or higher, and specifies part number "SB00090" for the older Audigy card. I believe recondas has had success with an Audigy.

Only with the aforementioned Audigy(1) SB0090, and then not much beyond shuffling it in-and-out of a Fuel just to confirm that it made an appearance in an hinv (already had a mAudio in there).

This recent topic turned up on the top of a multi-page list of similar topics concerning O2 video issues. Perhaps one of those topics might prove helpful to your situation.

Since your question is border line VFAQ, if any of those nekochan posts do prove helpful, please consider consolidating your findings to add to or create a wiki topic (you could pay that helpfulness forward). You might simplify the process for the next O2 owner who has the same question.

Perhaps the difference might be for which graphics platform the VBoB to be connected to - Odyssey or InfiniteReality?

There's a revision of the DMediaPro VBoB with a TOI daughterboard intended for use with DG5-2/TVO. The TOI/TMDS daughterboard has two TMDS ports (as opposed to the three DVI ports seen on the Odyssey-intended DM5 daughterboard). I have an TOI/TMDS equipped example with a 013-2746-007 Rev.A chassis part number (and an MTP-211 serial number), while a DMediaPro VBoB with a DM5 option board I had here briefly had a chassis part number of 013-3646-006 Rev A and an NSY256 serial number. Both ran the same 1.3.22 firmware/1.1 bootloader.

Two examples probably aren't a large enough sample to say the different serial numbers indicate the target graphics platform, so if anyone else has a DMediaPro VBOB that differs from that part number/option board configuration please post a follow up.

But you're right, there's very little DMediaPro VBoB info available on TechPubs. Since there's so little documentation, please consider adding anything you find to the nekochan thread on the subject: viewtopic.php?f=3&t=16724197

Updated to include part and serial numbers (recondas).

Nice system kais58.

If you have the opportunity to get a few unobstructed shots of your Onyx4 and the rack, please post them. That SGI sort rack is an interesting configuration, with the top-mounted badge panel and no door.

Do you have any other IRIX-based SGI systems? I'd be curious to hear if you noticed any differences in the function of the x-servers. To accommodate the ATI graphics boards used in the Onyx4, SGI used an IRIX port of xfree86 rather than the usual XSGI. If it's possible to add to my request for additional photos, a few screen captures of the Onyx4's desktop with some of the OpenGL based apps running would be much appreciated.

BTW, you're welcome to post reasonably sized photos as attachments to your post - the nekochan UI will automatically display a small-device friendly thumbnail (for those with limited-resolution systems, pad devices or smart phones).

Just got back from another motorcycle trip. Eleven days, 25 states, 8,000 miles. A fair number of miles to ride in the time I had, but it allowed me to finish riding my current bike to all of the lower 48 states from my home in North Carolina (needed Oregon, Washington and North Dakota to finish).

I haven't unpacked my camera yet, but here's a camera-phone photo from Crater Lake National Park in Oregon:

While it's been unseasonably hot in North Carolina, most of the northwestern US was just the opposite while I was there - most days it was raining and the temp never got out of the 50's (Fahrenheit), and it was in the 30's a couple of days (got caught in a snow-storm while riding through Mount Rainier NP).

Here's a Google Earth snapshot of the route (though we did end up making a few minor on-the-fly adjustments). Each day's ride is a different color:

EDIT: Unpacked the camera. Here's a few more photos - most were shot blind from a moving motorcycle, so forgive the less than carefully-framed subject matter:

josehill wrote: That's a whole lot of awesome, recondas!

Thanks!

josehill wrote: A few of those photos bring back some terrific memories from years ago for me.

I understand that, I have some that will last a lifetime. Even the colder days were spectacular. It was 39F/4C and raining when we passed through Butte Montana, and cold enough at the higher elevations in Mt. Rainier NP for the snow to fall and stick to us, the bikes and the roadway (first time I ever had to wipe snow off of the windshield while riding so I could see where I was going).

kshuff wrote: We didn't ride bikes out, but took almost the same route. I'll have to post some pictures also.

I'd love to see some of your photos. I took less than I would have liked - it started to rain in Reno Nevada, and only occasionally stopped through California, Oregon, Washington, Idaho and Montana.

dingofarmer wrote: Looks like fun, I can wait to take a long trip at the end of July, quick run to monterey for the motogp race, from denver through salt lake and renno. The trip home will be up the west coast to washington the long way and through boise and then eventually back home. Only 3500 miles or so, but an FJR1300 is only so confortable.

That ought to be a great trip - sounds like you'll be riding a few of the same roads we did. Not that you don't have some great asphalt to ride on near home - the stretch of I-70 in Colorado that passes through Glenwood Canyon is hands down the most beautiful piece of Interstate I've ever been on.

87Porsche wrote: The State of Kansas would like to formally apologize for I-70. But at least I-70 in Colorado makes up for it.

Not this trip, but I've been to some beautiful places in Kansas too (posted a photo of the Tall Grass National Prairie a couple of pages/years back in this thread). Because of the heat in the southeast, we left central North Carolina at 9:30PM Wednesday and rode to Lawrence Kansas the first day. The second day we left Lawrence at 2AM and rode to Salina Utah, so most of the Kansas portion of I-70 went by in the dark.

pierocks wrote: Hey recondas-
Did you take I-74 through Indiana and meet up with I-39 in Illinois? If so, you went right by Champaign. If you had stopped I would have bought you a beer

Thanks for the offer! Went right thru Champaign on the way back. Would have loved to take you up on the beer, but the first few and last few days are always long ones so we can burn off some miles (in places that are easier for us to ride to than the west coast). So that day's ride was around 1,000 miles (Fargo ND to Greensburg IN) - didn't leave much time for a cold one till real late in the day.

Passed pretty close to a number of nekochan locales. Just of the top of my head there'd be 87Porsche in Kansas, nekonoko near San Francisco, SAQ in Washington (did an oil change in Olympia WA, which didn't look to be too far from Renton), and a few others I'm sure I've overlooked.

tingo wrote: Nice trip, recondas. Sadly, my FLSTC (1997) haven't seen much road (other than between home and work) this year. Too busy. I still have fond memories from the long trip last summer; Oslo (Norway) to Åre (Sweden), then over to Trondheim (back in Norway again) and up to Svolvær (Lofoten) in northern Norway, and back home again via the scenic route (Røros in this case).

Norway and Sweden sound like a great ride (I'm envious, a ride across Europe and maybe Australia are on the short end of my bucket list). Your Heritage is a great bike to travel with. I used to travel on an FXSTB (if you'd like to see it I sneaked a couple of photos into my nekochan gallery ).

ajerimez wrote: Very nice Recondas! I'm planning a similar route for a road trip in July, the only difference is I'll be departing & returning from/to New York. Want to see San Fran, Yellowstone, Yosemite, Sequoia, Crater Lake, etc. Will be driving a Nissan Pathfinder. Any recommendations regarding route or attractions?

I'd suggest making a north-to-south loop (or south-to-north if you prefer). If you went north first I'd catch the Bad Lands, Devil's Tower, Yellowstone, Glacier NP, Mt. Rainier, Olympic NP and Crater Lake, then take 101 south (and as much of Hwy 1 in California as you have time for) as you move south. After you get to San Francisco you could catch Yosemite and Sequoia/Kings Canyon, then hit Death Valley on your way through Vegas/Hoover Dam. From there it's a short run to the Grand Canyon. If you don't have time for both the North and South Rims of the GC, my personal recommendation would be the North Rim (be sure to stay at at least one night at the North Rim Lodge or one of the cabins they have there). Which ever rim you pick, I'd recommend a drive up US 89 through the Painted Desert/Vermilion Cliffs (on the section of 89 that runs along the east side of the Grand Canyon). From there it'd be hard to pick a bad direction (the mountains in New Mexico are spectacular), but Monument Vally, the Utah Canyon Lands, Zion, and Bryce would be hard to pass up - and if you go that way be sure to get to Arches NP.

ajerimez wrote: Very impressed that you packed all that into 11 days - you really covered a lot of ground!

We do it every year, and I wouldn't trade the experiences I've had for anything. I always manage to find more gotta-see places for the next time I'm out that way. Got a dog-eared travel journal in the saddlebag that I use to write 'em all down - I'll probably run out of time before I run out of places (or pages ).

Fabian wrote: First question, is this correct R4600 is not a Mips4 CPU?

While the naming convention might be superficially clear as mud, the man page for MIPS4 ( man mips4 ) offers a little additional insight in to what MIPS processor hardware is supported:

DESCRIPTION

The MIPS4 instruction set extensions consist of a backward compatible superset of the MIPS3 instruction set. The MIPS4 extensions are intended primarily to provide better performance in floating point numeric processing. These features are currently supported under IRIX6.2 running on machines with the R8000, R10000, or R5000 microprocessors.

(Note: The on-line man page is obviously a little dated, while it specifically mentions IRIX6.2, in the case of MIPS4 nekoware that would be IRIX6.5.21 or higher.)

Fabian wrote: So SAQ suggested me to try Seamonkey. I downloaded the Mips3 release and installed it too. For Seamonkey, I do not find the Icon to start it. Is there something I missed?

Try starting seamonkey from the command line: If that works, you can drag the icon for the seamonkey executable from /usr/nekoware/bin to the icon catalog in Toolchest, your Desktop (or anywhere else you have writable access) to make a shortcut.

Fabian wrote: I gave a try to seamonkey and even if I installed all the required files, there is something apparently missing into my installation:

Code: Select all

INDY 19# /usr/nekoware/bin/seamonkey
969:/usr/nekoware/lib/seamonkey-1.1.8/seamonkey-bin: rld: Fatal Error: Cannot Successfully map soname 'libintl.so.9' under any of the filenames

Do you know what is this? I searched into Nekoware mips3 but didn't found libintl.

My nekoware installation might be slightly different (I'm running the MIPS4 stuff), but it looks like my version was a part of neko_gettext:
If you already have neko_gettext installed, you might try it again, but this time select the "Custom Installation" tab (in Software Manager) and expand the selections list to make sure the libintl.so stuff was selected. BTW, If you haven't already, it also might not hurt to download and run the neko_fixpath utility (it's a shell script, so just expand it and run it from the command line).

recondas wrote:

smj wrote: I was pointed at the older Audigy cards and warned off the Audigy 2s. The Fuel (IP35) Hardware Aggregator indicates either the Audigy or Audigy 2 ZS should work, but notes that the 2 ZS requires IRIX 6.5.25 or higher, and specifies part number "SB0090" for the older Audigy card. I believe recondas has had success with an Audigy.

Only with the aforementioned Audigy(1) SB0090, and then not much beyond shuffling it in-and-out of a Fuel just to confirm that it made an appearance in an hinv (already had a mAudio in there).

As a follow-up for future reference, Soundblaster Audigy (1), part number SB0090 does work correctly in a Fuel (and probably the rest of the IP35 family as well). In my tests the SB0090 produced stereo output that could be controlled from within Audio applications or the IRIX Audio Control Panel.

The SB0090 is a first generation Audigy board. The sample I have is a two-board set; a PCI board with the audio jacks and a firewire port on the bulkhead, and a ribbon-cable connected daughter board that provides midi/game and firewire ports on an additional PCI bulkhead. The complete Audigy SB0090 two-board set uses only one PCI slot, though if used the bulkhead on the daughter board would block another. To my knowledge an IRIX driver for the SB0090's firewire, midi or game ports doesn't exist, so the daughter board was omitted during my installation.

The SB0090 appears in an hinv -vm (IRIX 6.5.30) and produces three entries in the table of PCI devices Where vendor code 0x1102 is Creative Technology LTD (makers of the SB Audigy), device code 0x0004 is the Audigy (EMU) Audio Processor, device code 0x7003 is the Creative Labs SB Audigy MIDI/Game port, and 0x4001is the Audigy IEEE1394a Firewire Controller.

Probably because the SB0090's firewire, game and midi ports aren't supported by IRIX (and the firewire, game and midi ports communicate through the same PCI slot), the SB0090 does generate a non-fatal error message when IRIX loads Other than consuming seven lines in the syslog, the error seems to be harmless. The audio-related portions of the Audigy SB0090 work as expected once IRIX is loaded, without problems or additional error messages.

Additional info concerning the Audigy/IRIX EMU Audio Device can be found in the alResources man page ).

There's been a recent discussion concerning the use of SoundBlaster Audigy boards in the Fuel you might find interesting: viewtopic.php?f=3&t=16725195

Dr. Dave's post in that topic describes issues he discovered with the Audigy2 ZS while watching videos - as a result he suggested using the first generation Audigy SB0090. I did some follow up testing of an SB0090 in a Fuel with good results.

The Audigy SB0090 seems to be readily available (and relatively inexpensive) on eBay: http://shop.ebay.com/?_nkw=SB0090&

I've got a box full of 'em I'd be happy to sort through, but you'll have to give me a clue as to how much room there is behind the door of an onyx.

I've got a 3 meter SGI 13w3<>13w3 cable - SGI part number 018-8094-001. Google seems to think the part number is from the PI/Power Series era (which sounds right since the sheathing is white rather than gray). In addition to the three coaxial RGB pins, the only other pins are 2, 6, 7, and 8 (the number of pins appear to be the original as SGI intended config - the same ones are present in this eBay cable with the same part number.

Yours for postage if you think it'll do what you want.

Titox wrote: Nice machine.

Thanks

Titox wrote: I see you have a Seagate DAT drive. I thought only Sony models were compatible with SGI. Can anyone add to the Fuel Hardware aggregator a list of compatible DDS's?

That's easy enough - they're *all* compatible (with a minimal amount of end-user effort). This nekowiki article explains the basic process of modifying or adding to IRIX's list of tape definitions (or drivers. If you prefer) . There's also a list of definitions for a few higher capacity tape drives (LTO, SDLT and DTF) in this thread: viewtopic.php?f=3&t=16724885

gambonyx wrote: Nice fuel!

Thanks

gambonyx wrote: I have a question to ask, but the Rams should not be in ascending order on the bank? Does nothing if the bank 0/1 is - 256 and the bank 2/3 - 512?

As long as they're installed with a matching pair in either bank, size order isn't an issue (take a look at the memory configuration rules in the Fuel User's Guide ), and the Fuel seems pretty happy with the arrangement - it even announces it's "running in DDR mode" during power-on diagnostics:

GL1zdA wrote: Which EMU card is it? I assume it's EMU10K2 based (Audigy 2 ZS like)?

It's an SB0090 - a first generation Audigy Platinum EX: viewtopic.php?f=3&t=16725195&#p7340993

gambonyx wrote: Very nice fuel!

Thanks

gambonyx wrote: We would like to ask another curiosity 'I'd like to know:In Hinv ram and premium type,the other fuel that you have the standard type, but this depends on the density 'of a type of RAM modules or and a different brand?I've onyx2 of the standard type, but I also modules kingston 256mb, SGI original kits 1 of 16/4096mb origin. (I have only 12 of them) then the others are all to be 64mb but always sgi NEC I wanted to know if there is also the kind premium.

The difference in premium and standard memory is essentially the same for your Onyx2 as it is for the later generation IP35 stuff. Premium memory includes additional logic called directory memory, necessary in larger Cray/NUMA linked configurations. In the O2K/Onyx2 directory memory is a physically separate entity that gets installed in the smaller memory slots (just below the standard DIMM slots on the O2k/Onyx2 node board). In the IP35 systems, the directory memory is incorporated into the standard DIMM itself. I've seen 512MB and 1GB Premium IP35 DIMMs, and there might also be 256MB premium DIMMs (but I've never seen one). So Premium memory serves no useful function on the Fuel and tower version of the Tezro (or an Onyx2 Deskside). The Fuel and Tezro Tower can't be NUMAlinked, and as far as SGI was concerned, a Rack-mount Tezro couldn't couldn't be configured with enough processors to need directory memory (though I suspect the processor limitation is more of a marketing distinction than a hardware limitation).

gambonyx wrote: I was also interested to know if I can ask Onyx2 also on how to see the speed 'of the individual fans in real time, if there' some command like # l1cmd env

Unfortunately, no. The Onyx2 Deskside uses an MSC (module system controller) rather than the L1 (level one) controller used by the IP35 family. While it doesn't report real-time temperatures or fan speeds, the MSC in your Onyx2 does monitor both, will display a warning via the MSC display and operating system, and will even shut the system down when pre-set levels are exceeded.

Ryan Fox wrote: What? The proverbial offsping of MIPS server rack meets PC? I wonder what you get when you combine a Compaq ProLiant with a Tezro... -shudders-

They're safely surrounded by IRIX-speaking relatives - there's a Tezro and an Onyx350 InfinitePerformance inside the short rack, and an Onyx300 InfiniteReality in the tall rack (it's just behind and at a right-angle to the short rack). The only non-sgi system in the room is a very-light weight linuxpc that I use as a NFS/L3/Synergy/DINA server, and he keeps his distance (not to mention being headless most of the time).

jan-jaap wrote: You left the half rack too close to another system and Fuels started popping out ?

I'd suspect the Tezro and O350s - they only recently started cohabitating inside the short rack..

smj wrote: Now why d'ya have to go and tempt me like that? I haven't yet put the 8x600MHz O300 to good use, and you've got me thinking about upgrading. No damn justice, mumble mumble grump grump...

You could always add a router and NUMAlink all four of them together. Then add a couple of V10s or V12s and have a 16P Onyx InfinitePerformance system.

[[C|-|E]] wrote: They are really nice, both of them .

Thanks - I didn't originally plan to end up with two, but could pass these by - largely because they both have late-production components; 460W power supplies, 030-1707-004 system boards, and even SD-M1711 DVD drives. Some early production Fuels had 430W power supplies and 030-1707-00 3 system boards. The 430W power supplies received some notoriety for premature failure , and the -003 system boards are prone to developing failures with the ICs that control environmental monitoring .

Though these Fuels came from different sources, I found it interesting that the local brick serial numbers and local system serial numbers (MAC addresses) didn't appear to be all that far apart - NCL381 / 08:00:69:10:72:F2 on the V10, and NCL405 / 08:00:69:10:72:D9 on the V12.

[[C|-|E]] wrote: The Fuel is the MIPs SGI I like the less (do not ask me why, maybe because of the PC-like case they have) but those guys of yours look great!

The Fuel offers a very capable IRIX system for not too much money, especially when compared to other graphics-capable IP35-generation hardware (like the Tezro, O350 or any of the IP35-based InfiniteReality systems). There are some advantages to IP35-era hardware - faster processors, memory and I/O access - native U160 LVD SCSI, the option to use USB keyboards/mice, firewire access to compact flash cards, SATA hard drives, GigE networking, and a native DVI graphics port (so you can stop running that LCD panel in analog mode).

Added photos of the power supply, processor and system boards (scroll back a few posts).

Since the preferred M-Audio Revolution 7.1 boards often command a premium price, and the list of fully working third-party PCI audio alternatives seems to currently be limited to the Creative Audigy SB0090 (and the Audigy2 ZS has received mixed reviews).

The Audigy SB0090 uses an EMU10k1 chipset and the Audigy2 ZS uses an EMU10k2 chipset, so I thought I'd post a link to a list of other PCI audio boards that use the those same EMU chipsets on the chance someone might have (or cheaply acquire) a sample to test.

The list is from an FAQ for a project to provide a Win7 driver for EMU-based boards. So only consider the boards listed if you're willing to experiment/take the risk they won't work with IP35/IRIX (and some of the older EMU-based boards may only support 5V PCI slots, so check closely if you're attempting to acquire one): http://kxproject.lugosoft.com/faq.php?language=en#cards

There's a slightly more concise list (but without part/model numbers) in another forum concerning the same driver project: http://www.sevenforums.com/sound-audio/ ... u10k1.html


If you do discover an alternative PCI audio board for IRIX, please post a follow up.

smj wrote: I installed the SB0100 in a Fuel with a basic 6.5.30f installation, and while the card showed up in 'hinv -v' output, it didn't appear to be recognized as a compatible audio card - no "Iris Audio Processor" line, but the PCI IDs were present. When I would try to run the audio control panel it would refuse to start claiming there was no recognized audio device. When running the Confidence test app, no audio test was offered.

Steve - thanks for taking the time to test that board. I spent a little time browsing google images and it looks like pretty much anything older than the board you tried requires a 5V PCI slot, which excludes almost everything in the IP35 generation (except perhaps one of the O3x0 PCI Expansion Modules with both 3.3 and 5v slots).

deBug wrote: If you are only interested in sound out you can use an USB sound dongle.

Harry - thank you for adding USB audio to the the list of alternative IP35 sound devices. The USB Griffin iMic and the PCI DM8/M-Audio Revolution both got added to the IP35 family tree at the same time (with IRIX 6.5.20) . When I originally set up the Onyx300 it had a single compute module (with no empty PCI slots), so I picked up a Griffin iMic to have audio .

I wouldn't pass up any of the PCI audio options to run an iMic (high fidelity it ain't) but it was cheap, painless to configure, and functioned reliably.

Update: Finally found a second V12. The original post has been revised to reflect the changes: viewtopic.php?f=14&t=16722294

As soon as I get enough 75ohm BNC plumbing on hand I'll try out the Compositor.

If it's a just-completed install windows is probably indexing the contents of your hard drive (to make future searches faster). For more info on Win7 and indexing, select 'Help and Support' from the start menu and search the help database for "index".

Depending on the size/speed of your system/hard drive, it could take a while. If it doesn't seem to finish in a reasonable time you can always do a "control-alt-delete", select "Task Manager" from the menu and take a look at what processes are (or aren't) running in the background (or set up hard drive monitoring in the Win7 Performance Monitor).

smj wrote: you might want to check out this thread on Fuel PSUs for general info and possible alternatives.

The ATX specs have allowed (but not required) PSU fan and power monitoring since 2.1. (see subsection 4.2): http://www.formfactors.org/developer/specs/atx2_1.pdf

There's a little more info on the function of those optional ATX power supply signaling here: http://www.freeopenbook.com/pc-hardware ... 6-TABLE-14

ATX Optional Power Supply Connector signals perform the following functions:

FanM

FanM is a 2-pulse/revolution signal generated by the power supply fan that notifies the system of current fan speed. If this signal drops, the motherboard realizes immediately that the power supply fan has failed, and can shut down the system in an orderly manner.

FanC

FanC is an optional signal generated by some motherboards to control fan speed for power supplies that are designed to allow this. The signal can range from 0VDC to +12VDC. A signal of +1V or less is recognized by the fan as an order to shut down, and a signal of +10.5V or more is recognized as an order to run at full speed. Intermediate voltage levels, which are supported by some motherboards and some fans, allow the system to instruct the fan to run at some intermediate speed. If this signal is left open (0VDC), properly designed fans run at full speed.

Sense

This is a supplementary +3.3VDC remote sense line, which allows the power supply to monitor the actual voltage at the motherboard connector of the nominal +3.3VDC rail and adjust it to stay within specifications.

and even more in this document: http://ww1.microchip.com/downloads/en/A ... 00764b.pdf Whether or not the Sparkle or any of the other Fuel power supplies provide (or use) any of these optional ATX signalling functions remains to be discovered.

The Fuel env, serial all, and hinv commands don't return anything related to the power supply that are part number specific (like some previous models have done), so there's at least a remote chance the optional ATX 2.1 PSU monitoring might provide the necessary info to the L1.

The strongest argument for an SGI-only power supply is jan-jaap's experience with the PS in his prototype Fuel becoming unrecognized after a firmware upgrade - which strongly suggests there's additional outside of the ATX-spec monitoring going on. But it might also be possible that j-j's pre-production prototype Fuel didn't include a PS with ATX2.1 fan and power monitoring capabilities. Monitoring capabilities that weren't expected by his original prototype firmware, but were expected by the later general-release firmware he flashed in. I only suggest this possibility because it seems improbable that Sparkle would have made two different power supplies with the same part number, one with I2C or similar circuitry, and another without this modification. If they'd made a one-off PS for SGI you think they'd have given a unique part number and raised the price accordingly.

Additional background reading - power supplies are discussed but I didn't catch a mention if any were the non-SGI Sparkle FSP460-60PFN (or included the optional ATX2.1 monitoring circuitry):
viewtopic.php?f=3&t=10849
viewtopic.php?f=4&t=14990&

So the unknown elements are how the L1/environmental monitoring circuitry in the Fuel obtains sense info from the PS, and whether the Sparkle FSP460-60PFN sold to SGI differs internally (beyond the MB connector pin-out) from the non-SGI Sparkle FSP460-60PFN sold to other vendors/the public.

Until that can be determined I wouldn't throw any serious money at a non-SGI ATX/EPS power supply. A Sparkle with the same model number as the one used in the Fuel (FSP460-60PFN) just sold on eBay for $9 - perhaps there'll be more with similar prices. http://cgi.ebay.com/460Watts-Power-Supp ... 0725423723

jan-jaap wrote: I googled a bit for the NMB PSU. It looks like it was also sold as the 'it002a430wsw' for the Tyan S2603 dual Xeon board .

It seems the it002a430wsw is a WTX PSU, a larger form factor for e.g. dual Xeon boards . Pinout of WTX is different but ATX-WTX adapter cables exist(ed).

Of course no guarantees that (1) the SG 002a430wsw is WTX and/or (2) that a reverse WTX-ATX cable would enable an ATX PSU to work in a Fuel.

Thanks for posting that info jan-jaap.

I'm sure jan-jaap has already spotted it (or he wouldn't have included the pdfs), but the WTX specification also supports fan monitoring via FanC and FanM (see pages 23 and 29 of the WTX-Power-Supply-DG-10.pdf document provided by jan-jaap), and the data sheet he provided for the it002a430wsw specifically mentions connections for FanC and FanM functions - on pins 12 and 24 of the main 24-pin connector (though SGI might have opted for a different pin-out).

It might be interesting to see if there's any data/pin-out info available for the hipro power supply. Pontus could you post any Hipro model number info that appears on your PS (or attach a photo)?

astouffer wrote: If the extra pins are for fan monitoring/data lines will a fuel run without them? I'd go as far as making a small adapter for normal ATX supplies if there is a market.

Thanks for the offer, but based on some of the nekochan discussions (linked above) on the use of standard ATX power supplies, the answer seems to be the Fuel won't run (or even attempt to power up) without an active connection that reports the power supply fan speed/status (and possibly other bits of feedback from the PS).

If we can discover a working alternative Fuel power supply, a wiring adapter might still be a very viable (and needed) option, so please stay tuned in.

Outstanding!!

Very nicely done Pontus - Fuel owners worldwide you you a debt of gratitude.

Pontus wrote: And after figuring out the fan wasn't giving any RPM readings, I swapped it out for the original fuel psu fan.

It might not be related your fan issues, but when I added low noise fans to the O350/V10 I recently set up, I got fan failure messages. The "quiet" fans I used included a temperature sensor, and wouldn't even spin up until the O350 generated enough ambient heat - so they always generated a fan fail message at start up. I used a similar fix by adding a fan without a thermostat. Perhaps the original fan from your WTX power supply has a similar "low noise" feature.

jan-jaap wrote: nor did anyone bother to mention 'l1cmd version' output in the 'hinv' forum ...

Guilty as charged However there are several that included the output of "flash status" run against the L1 - which gives the same info for both L1 firmware images. smj's 700MHz is at 1.44.4 , and both of Fuels I have are at 1.26.5:
viewtopic.php?f=14&t=16725501
viewtopic.php?f=14&t=16725486