The collected works of SAQ - Page 3

I think the big issue would be actuating the XIO locking hardware. If you can figure out a way to do that it should work just fine, since ODYSSEY+ODYSSEY is supported. My guess is that the dual-Vpro carrier is mainly to actuate the XIO locks, anyway, since there wouldn't be any support screws on the chassis, right?

Perhaps look into the way the Origin2k handles XIO locking and then take a file to the metal plate..

Depends a great deal on your experience level. Switchmode PSUs are very touchy about component values, sometimes even to the point of values that aren't readily publicized. Inductors and transformers are very often custom, and many times there's an avalanche effect where one component (often a chopper) fails and takes out a couple of others with it.

If you're lucky (and can get something to compare), the failure will be in a section of the PSU that is the same in both the KW and the .7KW supplies (i.e. supplies a rail that has the same capacity, and is made by the same company, and shares the same design) so you'll have a set of parts that are known good to transplant (it's really difficult to figure out what a blown SOT is, I'm trying to figure it out right now. Fortunately my PSU has dual sections with the same design - but it's still no walk in the park).

The bad news is that it looks like an inductor or transformer might be blown. While PSU makers will sometimes/often skimp -erm "ensure economy and value by not using excessively rated parts" on the ratings for capacitors, actives and resistors, I've yet to see a SMPSU where they skimped on the inductive parts. I haven't looked at the latest "1KW PSU for your PC for only $50" type ones, though. Before you despair, look around for any other possibles for the failed component.

It wouldn't look as nice, but could you hack in a sufficiently powerful "PC-ish" PSU to confirm operation before getting too involved in fixing the one you have?

Are you sure that's a tant? It looks like it might be a MOV (metal-oxide varistor - most of the time if you can see the leads extend into the package like that it's a MOV [but what I see as leads could be something else]), and a dead MOV probably means the PSU was exposed to significant overvoltage.

MOVs usually come in herds - look for another one or two. They're almost impossible to test, but you can compare them and get part numbers to search for.

bplaa.yai wrote: There is an identical thing just next to it.
If I have time tomorow I'll unsolder these to have a better look at it, but from what I can see there is no label on it... But if they are MOVs, their physical dimension gives their "specification", right ? I also read interesting fire hazard things about these components...

The dimensions can "kind of" give the spec, a MOV with higher current rating will be larger in diameter, and a MOV with a higher voltage rating will probably (but not necessarily) be thicker. It's not the sort of thing that you can choose a replacement based on, though. MOVs are usually in the first part of the power supply to shunt transient voltages, so you can base your calculations on the line voltage (remember to use 240V for autosensing PSUs). I'd expect ~300-375V is common, but not having designed or replaced one in a computer PSU it's just a guess.

Which brings me to point 2: Something produced sustained overvoltage, and the MOV stopped doing its job (obviously), unless it was a MOV failure where it shorted on. There will be something else knocked out on that PSU, almost guaranteed. A quick test would be to remove the bad MOV (the PSUs don't need them to run) and try it out, but don't be surprised if something doesn't work.

iKitsune wrote:

theinonen wrote: If I had been in a cave for the last 5 years, came out, and saw a server with that goofy logo on it, I would think it was someone passing off, which is pretty much what's going on here - Rackable bought a brand, and ruined it as soon as they had it.

As far as I can see, Rackable has only changed the logo somewhat. Saying that they ruined SGI is a bit premature at this point.

For some reason (probably connected with writing a "haiku" error message for a web thing I was doing yesterday) my mind drifted to the old O2 Haiku page which, as it points out, is not in fact haiku (neither really was my error message, but I did draw in nature).

So, what about real haiku about SGIs? I'll start with a bad example:

In the cold winter
Onyx purrs, an outsize cat
House warm, program built.

Anyone else up?

More nature! More seasons! More measured expositions of how ElectroPaint reminds you of autumn leaves in a windstorm!

Good show so far.

MIPS is unusual in that it tends (in the SGI processor module implementations, anyway) to scale pretty linearly with clock speed (most CPUs slow down in effective work/MHz as the MHz increases). What you'll get is bigger Rx000 numbers as the MHz increases (since that was the big reason to rev the processors), and the performance goes up as the MHz increases. A bit rambling, so I guess I'll say it again:

As the clock speed of the processors increased, SGI/MIPS needed to revise the processors to allow them to function at that speed (shrink, tweaks to logic to fix timing problems, etc.) At the same time, SGI/MIPS tweaked other bits (cache interfaces, TLBs, branch prediction) to improve performance at the new speed, with the net result that a 400MHz Octane processor module is roughly twice as fast as a 200MHz processor module.

In short, look at the MHz ratings.

A 250 MHz PM20 is a good upgrade from a 175/195/225 and possibly even 250 MHz R10k, but for your machine I'd save and look for a 360-400MHz PM10 (single processor) or PM20. A dual but slightly slower processor module is probably not worth a $40 upgrade.

Put the drives in a ZFS pool - it will make your life much easier.

If you do a text console install you can put the root/boot on ZFS as well, and you can't do that under interactive (GUI).

I think that it might be easiest to label the disks (format program) from the GUI though - just bring up the root menu (right click on the desktop) and select "terminal"

sybrfreq wrote: ...I presume step one is to put the MXI back in for now to get it to boot the OS again. Although, should it be able to boot in single user mode without graphics drivers?

Seems like it should, but SGIs need to have some graphics support for the graphics console textport to work. The PROM graphics driver doesn't work once IRIX loads. As Wolflord pointed out, a serial connection will work.

The other thing you can do is boot a miniroot and install the necessary files (keep *, install hardware [I believe]) from the miniroot, which provides the necessary drivers/microcode to use the graphics console textport. Just make sure you have an "installation tools and overlays" disk from a version of IRIX that supports Odyssey.

You will need to swap back or use a terminal if your Octane has a very old PROM that doesn't have Odyssey support. Flash the PROM to a newer version and then reintall the V6.

kramlq wrote: I think its only going to get worse. Assembly isn't really considered important enough to teach anymore, and universities often teach virtual machine based languages like Java from day one of the course now. So the correlation between code written and what happens at lower levels is not something future programmers are very aware of anymore.

That requires time in school, which will translate into higher salaries. Given that most end-users seem to expect terrible performance and either be OK with it or blame themselves (I think I need to get a new machine ... mine is two years old and it's getting a little slow running the Internet. Also I think I need to upgrade my DSL - it's only 7Mbps and it's slow... ) why would you, as a software company, want to bother paying money for someone who really knows what they're doing for "consumer" stuff. Perhaps for professional apps, I suppose.

The state of computers nowadays is an industrialist's daydream, with many users thinking "it doesn't work right... it must be my fault"

I seem to be channeling Hamei. Or Dogbert.

strandedinnz wrote:

porter wrote:

strandedinnz wrote: or I could buy you a beer should you ever come to New Zealand, your choice

Been here for quite a while now......

doh I should really learn to read those little boxes on the right so I can't fob off children onto you ? And I have to pay for beer ? Bugger!

Mark

You'll note how he quoted your post so you can't go back and change it, too.

The guy really wants his beer.

I have yet to attain Inst guruhood, but would the command sequence you entered (keep*, install fresh, go) do the "install hardware" (which tells IRIX to reexamine the hardware and install any newly necessary files) part of it?

I've always seen the sequence as "keep *, install hardware, go"

Unusual set of boards for a deskside Onyx as well. Let's hope that they made a mistake in inventorying them, as a deskside machine stuffed with IO4s and MC3s with no IPs doesn't do very much.

They also have too many EBUS boards for the available slots, methinks.

jan-jaap wrote: With two MC3's and no CPU card listed, there's either an error in the inventory or the system is incomplete. It is also in unknown working order so the value is very very limited.

That and there appear to be two or three IO4s, which would again be difficult in a deskside Onyx.

Looks like they corrected the inventory then - I saw at least 2 IO4s (checked part numbers on them because I thought they might be counting HIO cards as IO4s).

Still no IP19, IP21 or IP25 boards, though. Probably a parts box.

MisterDNA wrote:

silicium wrote:

fzalfa wrote: too far from france !! :,(

Has anyone searched for slower shipping options from USA to Europe ? Cargo boat should be cheaper than air.
Then how much taxes are there in the EU for importing scrap metal ?

Scrap metal. That... is positively brilliant!

My grandpa's wife comes from Fiji and they often ship stuff back there for her extended family. I don't recall anything about the price other than "spectacular deal" coming to mind.

The best story about shipping that I've heard comes from my grandpa. He was stationed on Midway at the end of WWII. The government didn't want to spend the money to ship all the stuff back from Midway to the US, so they abandoned it. Servicemen were allowed to mail stuff for free. Connect the dots - the US Government wound up paying to ship a big chunk of it back to the US anyway, they just didn't get to claim it at the other end.

It is odd that Windows is somehow considered less proprietary than UNIX or OpenVMS, when in fact it's almost the opposite - at least almost everything is documented for UNIX/VMS, and for several of the Unices it's cross-platform (Solaris, xBSD, Linux). Come to think of it, OpenVMS is semi-cross platform, too (reports are that it works on non-HP standard (i.e. no fancy stuff like Altix) Itaniums).

Contrast that to Windows which is not open and not fully documented.


Triumph of MS whitewashers (marketing).

porter wrote: .... and don't forget how much was written at universities rather than commercial environments. ( I'm taking the stand that Universities aren't just in it for the money )

The CSRG definitely wasn't (unless you count the tax dollars).

Hmm - "open architecture" as applied to software: UNIX was the original "open system" - all parts were documented, and the sources were available to anyone who wanted them from AT&T (provided you could pay) and Berkeley (originally required license from AT&T to get BSD, but later not).

"Open architecture" as applied to hardware: SPARC. Anyone can build a SPARC processor, and SPARC international will provide stuff to help you do it. Sun even has an open core that you can grab and build onto (with some restrictions). Open Firmware is a standard, and there's even a FOSS implementation in development now. Same with SBUS...

Compare this with x86 and Itanium, which are available from a few vendors but aren't "open standards". BIOS is provided by only a few companies, and not completely documented. EFI is a bit better, but things still are generally proprietary.

Sounds to me that the new SGI must be moving to SPARC-based hardware running Solaris/xBSD/Linux if they're really "... moving from antiquated RISC/proprietary Unix to an open architecture"

Although I suppose that MIPS is open enough to count.

Too bad, though - I would have hoped that someone would have picked up Alpha again, but that is pretty proprietary. Even more proprietary than Itanium and Intel x86... .

Build started for MIPS3.

Did you have the "I only want to build on one processor" problem with yours? ("cannot contact jobserver, using -j1" or something similar).

Makes me glad I didn't spend a bunch of time today getting the 6-way Challenge ready to blitz through the build. The O200 is taking forever.

Interesting - my box had a different static-config.mk file.

nekonoko wrote: That's just a patch, not the whole thing

Correction - when I went to look at the relevant lines from static-config.mk on my box to see how they would change they were different than the ones listed in the patchfile. Not a big deal, as it was easily hand-edited, but interesting that they would be different.

Yep, not doing as much as I should (no Internet at home so I have my boxes at my parents), but there are a few MIPS3 builds still current, and a few (fontforge and xfe) that I don't think have made it into the MIPS4 tree yet.

IRIX 6.5 will still run o32 just fine (O32 is a subset (?) of the MIPS ELF ABI).

What has been removed is ECOFF format, an ancient binary format that sort of supports shared libraries in a roundabout way and has debugging support tacked on. That short description should give a hint of how Frankenstiney the format is (it's derived from the pre-R4 SysV binary image format, Tru64 uses it and Windows uses a variant (PE)).

Pretty much everyone moved to ELF shortly after it was introduced, and SGI was no exception. ECOFF support was installable through IRIX 5.3, but then was phased out through IRIX 6.0 and 6.1, and finally dropped with IRIX 6.2 (when the n32 ELF ABI was added, which was more efficient on modern (R4k and above) hardware than the old -32 (o32) ELF ABI.

The reasons for cancelling ECOFF probably revolved around the difficulty of maintaining many sets of libraries (IRIX 6.2 has /lib (o32), /lib32 (n32), and /lib64 (n64) already, ECOFF would be a whole other set), and the general superiority of ELF.

Question (not having an IP35-derived system yet):

Why haven't you re-flashed the first image back so you have a failsafe again?