SGI: hinv

^^ I think I'm gonna chrome mine .... should be good for another 50 hz.

Do we know if this fuel was a prototype for the fuel that came out and that we all use or is it the prototype for something above the fuel we have now?

Oh great. Do I have to go and make a signature for this now?

no, you don't. Just recolor the red one.

sybrfreq wrote: no, you don't. Just recolor the red one.

The logo is still on the front.

pentium wrote: Oh great. Do I have to go and make a signature for this now?

Can I have one for the x350 ?

With out the logo.

How can I ignore that?
You have to appreciate the irony though: I have too many systems of my own to list them in a .sig, and now the only one shown isn't even mine

pentium wrote:

sybrfreq wrote: no, you don't. Just recolor the red one.

The logo is still on the front.

D'OH!

Updated with L1 data.

Meh, this system is sick

The CMOS battery (ST Micro M4T28-BR12SH1) ran out a while ago, and now it doesn't just complain about preposterous time and kernel in the future, it actually forgot it's serial number. The MAC address changed to 12:34:56:78:9a:bc so it was promptly kicked off the network. This also invalidated the FLEXlm licenses installed.

I don't use this Fuel very often, but I still ordered a new CMOS battery for it. Looks like I'll have to borrow the L2 form the O350 to fix this?



The PIMM info in EEPROM seems off as well, although that's maybe caused by the failed MAC read before it? Otherwise it seems to function just fine.

*sigh* Seems like SGI really didn't think ahead with respect to having a cleaner way of fixing these issues.
I've been supplying parts to companies globally who are still using SGIs after more than 20 years, back to
Personal IRIS. There are still loads in use out there (mainly medical, industrial control, defense and infrastructure
setups, though a few for performance-related tasks where sw license issues preclude a move to newer kit); Fuel
is used for medical scanners. Atm it's just power supplies and the odd RAM module problem cropping up (I sent
a PSU to a hospital in India last month), but eventually such institutions are going to be in a right old bind trying
to sort these things out when they the kind of problems jan-jaap is going through.

IMO SGI should back-release some kind of fix for this, eg. a program to sw-override the lic code setting, etc.,
and then declare the old IRIX systems as defunct and 'open' or somesuch. I'm sure it's possible.

In some cases companies can eventually move to newer PC-based systems, despite the signicant
expense, but others just can't for other reasons, eg. original sw vendor is gone, or support hw isn't
compatible, etc.

Ian.

Well, at least on this system I won't have to dremel anything when the battery inevitably runs out. Although this design is probably because of environmental rules that dictate that all batteries must be removable, and had nothing to do with easier service in the long term.

Now, if only they would have used CR2032 cells like everyone else.

So I replaced the yellow M4T28-BR12SH1 RTC timekeeper backup battery. I reset the time and now it doesn't complain anymore. But my problems are far from over. First of all, I realized this thing has a DALLAS chip as well (DS1742W), plus an ATMEL chip which is assumed to hold the SSN .

So it has not one, but two batteries which can (and probably have) run out

When the L1 boots, it spits out:

This may be a 'genuine' failure. The CPU works so I don't really care. A much bigger problem is that the MAC address is still 12:34:56:78:9a:bc

I have the last L1 firmware installed, so serial number security is 'on'. No 'l1cmd serial set xxxxxxx' for me.

I thought of setting it via the L2, but a MAC address is not an acceptable SSN for the L2:

How am I supposed to format an SSN to result in a valid MAC address? Can a Fuel be hooked up to an L2 at all? It has an L1 USB connector ...

Then I tried

....ehm, RIGHT

But anyway, there are two batteries. What if it's not just the yellow battery that ran out, but the DALLAS as well? And the DALLAS is what backs up the L1, while the yellow one is only for the timekeeper? Even if I could change the SSN, it would be gone the first time power is disconnected.

Think I'll leave it disconnected over the weekend to see which functionality it looses -- L1 or RTC. I have the feeling it's going to be the L1 and some DALLAS surgery is due I mean, it had been complaining about preposterous times etc etc for a year or so before all of this went belly up.

Which leaves the question: how the hell am I supposed to change the SSN and restore my MAC address??

Battery backed RAM is a bitch

jan-jaap wrote: I realized this thing has a DALLAS chip as well (DS1742W), plus an ATMEL chip which is assumed to hold the SSN.

So it has not one, but two batteries which can (and probably have) run out

Hope this is peripherally useful ... it's been quite a while but I'm pretty sure that you have to move the Atmel and the Dallas to change mac addresses. I think I discovered that when trying to put together a frankenfool with a few nodelocked licenses.

The yellow M4T28-BR12SH1 is just a battery and a crystal for the real time clock, maybe some nvram. The Dallas chip is all in one with the rtc and ram. And annoying.

I just replaced the one in my Tezro, all happy now. Trying to decide if I want to pick up a couple of those yellow batteries for the tezro, fuel and origin future failures.

OK, it seams that
1. The L1 controls the SSN
2. The L1 is backed by a Dallas 1742W and an Atmel 24C04 EEPROM .

But the good news is: despite serial number security, you can change the serial number . Well, for a Fuel, at least.

First the current situation:

Continuing:

So the L1 is happy, L1 version is latest and greatest, security is 'ON' and 12:34:56:78:9A:BC is a valid SSN. As far as the L1 is concerned, at least. Me, I'm not too happy with it

Serial number has been restored!

I still have to replace the Dallas, because I guess the next time the power is disconnected for more than a couple of seconds it will start acting up again.

I even tried a 'serial clear', something which can cause great pain on O350/Tezro etc, and it did absolutely nothing . I still don't recommend you try, though.

Oh, and the first I2C read to the PIMM seemed to have worked, and later it doesn't. Ah well, I don't think this is related.

If I get a chance I'll read the i2c 24C04 eeprom.