The collected works of SAQ - Page 8

This and the RASC stuff was definitely interesting from a technical standpoint - it seems that this incarnation might be an answer similar to IBM's Cell-based stuff, but it does remain to be seen if it works out in the marketplace.

Really the technical hasn't been a problem for SGI, it's more of the "what will sell, and at what price" that has nailed them.

You forgot the price breakdown:

$1.25 hitting the machine
$95.00 Knowing where and how to hit the machine.

The fact that there are errors on both SCSI HBAs (internal and external) does point to something else besides a single disk failure. What is your setup? Are you using both SCSI channels?

Both SCSI HBAs on Octane are fed from the same BRIDGE chip and XIO connector, so you might want to try removing the IP30 board and gently blowing the compression connector (from the side and using dry air) then reseating to see if it's an odd intermittent connection thing. SCSI 0 goes via an internal connector to the drive backplane, and reseating the board will also reseat that. Bus 1 is soldered through to the external port - not sure what could be causing your error there. Is it in use?

That's a 4Sight machine there - 4D1-3.3.x. My /25 is at my parents' so I can't confirm exactly where it comes from

Is NFS running? Try telnetting in on the NFS port. Run TCPdump or other sniffer and see what's going on (both client and server). Can you get in on other allowed services?

What auth are you using, and is it working properly?

IBM FRU-marked 72-pin SIMMS could very easily be proprietary RS/6000 memory.

Silly question, but - what's the purpose of the O3200 vs the O300/350? Looks like almost everything the O3k can do the O.3k series can do. Slight memory advantage for O3k vs O300, but that was fixed in O350.

I suppose that leaves future expandability (provided you bought from SGI so they could re-serial the R-brick when added/expanded upon) and XIO connectivity, but it seems like you're paying a noticeable space premium for the O3k in a 2 C-brick config (2xC brick + I brick + power brick rather than 2xO300/350). Perhaps it was cheaper? Though I doubt that...

Have a bunch of Origin2000/Onyx 2 XIO to single PCI shoehorns. Tested/working. $25, quantity discounts available.

2x -003 revision (IP31-capable for 250MHz and up nodes) full rack routers. Again tested/working. Make offer.

1 Origin2000 Compute Module midplane with XBOWs and mounting hardware. Make offer.

Definitely when you go to large scale installations the O3k would be cheaper than the O300/350, because the O3k's C-bricks aren't hauling around I/O and power and the other O300 stuff.

CX is slick. CX+I-brick+G-brick or CX+O350 with V12 (provided a hack can be done) would be very nice.

FOSS is terrible at this - it's as if the programmers were saying "it's free, so whats the problem with you needing to install 5 different toolkits with their ancillary support libraries, oh and by the way we've broken compatibility between major releases so you need to have 3 different versions of each library . . . Oh, and there's the KDE/GNOME/whatever else support daemons . . . but it's free, so what's the problem?"

That and the projects that don't list all the prerequisites. You'd think they'd realize that something such as "Linux 2.6.27 or better" is all but meaningless for a userland app.

OTOH, the willingness to shake things up can be a good thing - how many computer people complain about something on $PLATFORM that is an idiotic way of doing things, but it's been that way since 1992 and changing it would be difficult. The key is finding the golden mean between the two.

This discussion makes me wish I had downloaded Matador when it was available. I think I was still on dialup, though.

Hence the admonition to use dry air (forgot to note that it shouldn't be high-pressure, so don't grab your tank compressor).

SGI has a manual on how to clean CPAPs on TechPubs - http://techpubs.sgi.com/library/dynaweb ... l/apb.html .

Try reseating your RAM as well, as not-too-good-but-good-enough-to-pass-the-RAM-diags connections in RAM can show up as many different errors.

That's because the POWERs are really checking things out, whereas the 386 sizes memory, runs a parity check (maybe), and calls it good.

Big SGIs, Suns and HPs take a while, too. Diags are usually toned down on the workstation models (except for IBM).

Get a SS20. The -10 has a smaller PSU and nowhere near the cooling capacity of a SS20. The -20 also has a faster MBus and SCA drive connectors (much easier to find larger/newer drives).

SX graphics aren't bad, either.

The PROM "off" command is model-specific. I thought it worked in Indigo2, but evidently not. Remote power-off works on Indy, Octane, O2 and the models with a system controller, but the method of powering down is different for the system controller models.

Don't think any of the FastForward and derivative boxes support remote power-up. O2 has the jumper, but that's a model-specific peculiarity. You could possibly wire up something using a state machine or one-shot to trigger the power-up circuit if you wanted.

"installment plan"



CX will probably be pricey for a long time. Last-generation SGIMIPS and lots of compute power squished into a small box. Couple that with the numbers sold (not many, comparatively) and things are looking difficult for the hobbyist. Same thing will probably be the case with Tezro quaddies.

There are a number of things that never made it out of Classic (or even 68k for that matter), and also some things that I use occasionally but not enough to warrant paying big bucks for new versions.

Mostly not daily drivers, but things that are used a couple of times a year.

For IRIX it required a customized kernel which Stanford couldn't distribute, so it never was useful unless you had an IRIX source license and access to the SimOS modifications.

It's a DS3691 RS-422/423 line driver with tri-state outputs (on IP22 anyway). Datasheets are available, here's one http://www.datasheetcatalog.com/datashe ... 3691.shtml

The riser is all passives except for the system serial number/MAC chip (uncanned NIC - does this make it perishable?)

For the moment let's ignore any questions of "IRIX is going to be worth millions again someday" and concentrate on the liabilities of releasing the source.

First thing to keep in mind: releasing IRIX nets SGI nothing. Zip. Goodwill from hobbyists about something that you don't sell anymore and won't sell again isn't worth anything.

Second, what's going to happen if you release the source and someone thinks that you compromised their trade secrets/copyrights/etc. Yep - big lawsuit. Even if it's something stupid ("Hello, I'm the general counsel for SCO or it's successors, self-styled owner of UNIX. We noticed that you released source that looks very similar to our proprietary UNIX source. Let me draw your attention to the top of strcall.c. You will note the repeated use of #include, which we notice is also used in several files in our proprietary source code which we won't show you. Since #include doesn't come up in English very often, the only logical conclusion is that you have illegally misappropriated our confidential IP and trade secrets. Please send us $80 million.")
Yes, it's stupid. Yes, you'll probably get it dismissed. Yes, it'll cost you big bucks to get to that point. Imagine what would happen if it were another company with a valid concern? The only way to get around that is to have someone go line by line through IRIX and redact anything that is a problem. This too is expensive. Your shareholders/board/etc will ask why you are doing this. See point 1.

When you're done what will you have? See point one.

The only thing that could possibly work if SGI is amenable (though what do they have to gain?) would be for an organization to "buy" IRIX , inherit all the encumbrances, licenses and confidentiality clauses, take the liability on themselves and then sanitize it. Will this happen? Not likely, what does SGI leadership have to gain? What do they have to loose? As Hamei said, it's possible that someone's going to pay big bucks for SASH, and would you like to be answering the board's and shareholder's questions when it comes out that you released it open source? Safer to let it disappear, because the questions aren't nearly so scathing when the reply is "we seem to have lost the code you're interested in".

But it's cheap and as for the problems, well, "we'll fix those in an upcoming release..."

The availability of the Internet was one of the things that ruined the quality because companies now could cheaply issue updates and fixes. Nice in that the fixes were available and fast, but for some reason things seemed to be checked much better back when the companies knew that any serious bugs would require them to dispatch service people with new PROMS, or send out disks, or something else that cost money.The proliferation of firmware bugs, especially, is inexcusable - especially when combined with the attitude of certain companies "oh, you need to update your BIOS/PROM to have it work right. BTW, if anything happens to your machine while you're doing the upgrade or because of the upgrade we won't cover it."

Bravo! What a coup!

Did that come in the shipment with your LispM?

Just out of curiosity, is it an upgraded Sun-1, a Sun-2, or a prototype in-between model? The 100U was the Multibus -010 CPU board, right?

Count your blessings - I've seen too many sites where nobody understood what that little piece of pink paper was all about.

I wonder if they teach software librarianship in those 2-year fast-track AA-compsci programs yet?

I probably should have picked one up - my High board has a solder blob on one of the chips so I'm not sure if it's working yet (haven't turned it on).

If the drives are SCA then you can just run them off your Octane's internal bus. If they're 68-pin you can violate shielding for a short bit and use an internal cable (the ones for LVD should have an integral terminator) and plug it in your Octane's external SCSI port.

Another forward from the SunHELP Rescue list (not my stuff)

He notes off list is OK, so I gave the Rescue people a day or so exclusive before posting here.

Note the Indys, PI, O200 and O2.


His e-mail is the last line of the quoted passage at gmail.com

That would only be people who don't know what he does with the stuff. He's probably second only to Al Kossow in ancient computer help sainthood.

The return of the shark!. You "eclipsed" VAX, which might cause some grumbling amongst a certain set of DEC devotees who would much rather see Integrity blotted out .

Depends on the component. Often caps go, and usually (unless they're the big main filter caps) they don't take anything out with them. Actives (semiconductors) going is much more unusual - you should take a look around and see what is up if it's really a diode that went.

Do you know about where in the supply "chain" the diode was? Since the computer went on running it (if it was really a diode) was probably in a lesser-used rail such as the -12V.

Check out to see if it might have been a tantalum "blasting cap" or a paper cap - these are often used as small filter/ground shunt caps and can fail spectacularly without much additional damage. The tants are either surface-mount boxes or the sort of capacitor that looks a little like a pillow.

Other than the fact that I don't have one yet? Technically little, but they are the first truly commodity boxes where VMS didn't enter into the design process at all (really they were HP9000 replacements). Granted, it probably made for a "stronger" VMS (in that it can now be pretty easily ported anywhere), but the synergy of the Alpha/VAX platforms and VMS was slick and led to some neat hardware/firmware innovations. True, they're now in software and thus more portable, but I do have a soft spot for solutions other than "throw more processing power and software at it", both electronic and mechanical.

Also, Integrity is not not DEC. On the other hand that means that they don't quite have the DEC ego either.

Definitely a diode. Diodes tend to fail spectacularly for one of two reasons: excessive reverse voltage and excessive current, and in both cases the overload needs to be significant for there to be anything noticeable.

Look very carefully at the caps in that section of the PSU to see if one has failed. A large cap shorting can drag a diode with it easily before going open-circuit, whereas the small caps generally don't need too much juice to burn out a connector wire.

Most PSUs use the diodes in a bridge configuration, so provided that there is enough filter capacitance available it will still look like it's working, but something went bad. Go over that area with a flashlight and magnifying glass.

A big diode near a fuse rating is probably in the main (~320V) section before the choppers/regulators.

Very nice looking Mac. Up there with the SE as one of my favorite designs.

The bad part is the limited RAM capacity. Too bad they didn't have higher capacity VSIMMs so they could have had 2 banks of system RAM - or better yet used the Quadra 800s memory subsystem (supports interleaving!) in the 700s case (admittedly that would have been a chronological challenge... )

The spiral thing doesn't make much sense, but HP seems to like it. I guess it's supposed to show the continuity of the OpenVMS Experience or something similar. It's hard to read, doesn't give much of a temporal feeling (the VAX section is too short for reality or aesthetics), and the turns are convoluted.

Vernon is cool in a "rogue" way, for the reasons given. I think he was generally only "semi-official" and early to mid '90s birthdate, so the age and the fact that the full weight of the marketing department wasn't behind him explains a bit of the FOSS logo look.

It's DEC, so it will take a serial console. With DEC operating systems you won't notice much of a difference between local graphics console and network use. OpenVMS will require a bit of alternate key fiddling, but if you're running UNIX there won't even be that.

DEC graphics aren't great. DEC wasn't known for graphics and for the most part they weren't very interested in graphics, so it's the dancing dog phenomenon.

DEC 3000/300s use the same RAM as Indigo2/Indy. DEC 3000/400s and up use proprietary RAM, so specs may be more of an issue. Both use Fast Narrow SCSI drives, and the processor speed is indicated by the model number - strangely, the -300 is a bit faster at the CPU, but the -400 has a more efficient design (crossbar-based similar to the Sun UPA).

The big ones in PSUs can also leak around the bottom without appearing bulged, so look for evidence of something getting on the board around the cap.

Yep. For many years DEC used the same keyboards on their workstations as on their VT* terminals, and the VAXstation/DEC3000/DECstation are no exception. They use LKA[x]01 keyboards, and on the 3ks they are attached via a breakout box (similar to the NeXT concept with the keyboard plugging into the sound box, but on 3ks the pigtail only does KBM).

These tend to get lost and then thrown away by people who can't figure out what they are in the absence of the Alpha (in organizations), so unless the machine comes with it you're probably better off ignoring it. The keyboards are easy to source, and the mouse is middle (common to the 3k, VAXstation and DECstation).

They should work if you put the "installation tools" disk (that supports Fuel) in the CD drive and select the diagnostics option - that's the way it works for the IDE diagnostics, anyway.

Yep, all UltraSPARCs are in-order superscalar, and as far as I know no SPARC has been at the top of the heap for technical computing. It was a intentional move by Sun to do in-order, as they determined that their market wouldn't benefit much from OOO.

If you want an OOO SPARC you can get a SPARC64 (Fujitsu).

Absolutely not.

VAXstation is the proper name for a VAX equipped with a graphics console, MicroVAX were the small minicomputers/servers (and VAXserver was a limited-lifetime name for a MicroVAX with limited licenses to only function as a network server rather than allowing terminals. This was before MS had the bright idea to require a license for each network user, otherwise DEC probably would have followed along).

In order to have a VAXstation from the MicroVAX 2000 it is very easy - you flip a switch. MicroVAX 2000 is, however, quite slow (slower than an 11/780), memory-limited, and requires a MFM/RLL type of hard drive (the built in SCSI is really only for the tape. Efforts are underway to hack in disk support, but I don't think they've born fruit yet).

DECstations are interesting - they're MIPS-based little-endian UNIX workstations (the VAXen will run either UNIX or VMS). Get the highest numbered model you can find (the /240 was R4k based, others were R2k/R3k). Make sure you get the mice and keyboards if you want local graphics consoles, although DEC machines don't suffer from remote connections at all (the UI is ... primitive ... and there really isn't anything in the way of whizz-bang graphics h/w).

You'll probably much prefer a newer MicroVAX 3100 series to the 2000. SCSI disk interfaces, much faster processors (CVAX and better rather than MicroVAX-II), and bigger memory capacity. /40 and up are the best - 5VUPS or better and no disk size limit under VMS (UNIX can take bigger drives with proper partitioning). The -2000 is good for formatting VAX MFM/RLL disks (for that it might be worth snagging if they're dumping it), but that's about it.

The "single-user/multiuser" limits was DECs way of creative income adjustment via licensing. Under VMS you had to buy a "bigger" and therefore more expensive box to enable you to add more user licenses. Thus, one user could run on the VAXstation 3100/76 (with Rigel and a bit over 7 VUPS), but to add two terminals you needed a VAX 4000-300 (exact same processor, more expensive) or MicroVAX 3100/40 (slower processor, probably more expensive). With VMS Hobbyist licensing the "type designation" is meaningless now, so you could run many users on any VAX. Note that DEC's idea of a user is different from Microsoft's, so network users don't count against your licenses.
I wish I had known this before you came down - we could have arranged a trade!

Origin 200 and Origin 2000 cables are electrically equivalent, the only difference is the stiffer "conduit" on the O200 cables (these cables are sold on the O2000 as Crosstown cables).

AFAIK you need to have expanded directory memory for all installed memory banks on O2k for it to work in large CPU setups. The directory memory allows the O2000 to keep track of where in the global space things are, and if you have too many nodes it overflows the space on the standard DIMMs. I'm not even sure it would be possible for a NUMA system to have private local memory - sort of defeats the purpose .

If it is cracked (rather than pulverized) you can try using ketone (methyl ethyl ketone, MEK) to solvent weld it - most SGI plastics are styrene.

Assemble the top dry like a jigsaw puzzle and then bead the solvent down the cracks - it will wick into place.