Nekochan Net

Official Chat Channel: #nekochan // irc.nekochan.net
It is currently Fri Oct 31, 2014 12:12 pm

All times are UTC - 8 hours [ DST ]


Forum rules


Please post your 'hinv' in the following format:

Topic: Kind of machine (O2, Octane, Tezro, Onyx2, etc.), CPU (R10k 250MHz, R12k 300MHz, R16k 1GHz, etc.), RAM, graphics option (Example: Tezro V12 4xR16K 700MHz 4GB)

Body: output of hinv -v (hinv -vm if possible) and /usr/gfx/gfxinfo.

Please wrap the output in BBCode "code" blocks to improve legibility.



Post new topic Reply to topic  [ 73 posts ]  Go to page Previous  1, 2, 3, 4, 5
Author Message
Unread postPosted: Mon Mar 16, 2009 11:31 pm 
Offline

Joined: Tue Feb 24, 2004 5:10 pm
Posts: 9721
pentium wrote:
Oh great. Do I have to go and make a signature for this now? :roll:

Can I have one for the x350 ?


Top
 Profile  
 
Unread postPosted: Tue Mar 17, 2009 12:05 am 
Offline
User avatar

Joined: Wed Aug 20, 2008 5:38 am
Posts: 916
Location: North of England
With out the logo.


Attachments:
Fuelb.png
Fuelb.png [ 253 Bytes | Viewed 7037 times ]

_________________
:Indy: R4600PC 133 MHz

Mac Mini 2.5GHz 8GB RAM
Raspberry Pi
Dell XPS M1530
Top
 Profile  
 
Unread postPosted: Tue Mar 17, 2009 2:01 am 
Offline
User avatar

Joined: Thu Jun 17, 2004 11:35 am
Posts: 3930
Location: Wijchen, The Netherlands
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 :D

_________________
Now this is a deep dark secret, so everybody keep it quiet :)
It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi

Currently in commercial service: Image :Onyx2:(2x) :O3x02L:
In the museum: almost every MIPS/IRIX system.
Wanted: GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)


Top
 Profile  
 
Unread postPosted: Tue Mar 17, 2009 5:44 am 
Offline
User avatar

Joined: Tue Aug 21, 2007 10:12 pm
Posts: 2859
Location: Fantasyland
pentium wrote:
sybrfreq wrote:
no, you don't. Just recolor the red one.

The logo is still on the front. ;)


D'OH!

_________________
"If no one comes from the future to stop you from doing it then how bad of a decision can it really be?"


Top
 Profile  
 
Unread postPosted: Mon Dec 06, 2010 7:13 am 
Offline
User avatar

Joined: Thu Jun 17, 2004 11:35 am
Posts: 3930
Location: Wijchen, The Netherlands
Updated with L1 data.

_________________
Now this is a deep dark secret, so everybody keep it quiet :)
It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi

Currently in commercial service: Image :Onyx2:(2x) :O3x02L:
In the museum: almost every MIPS/IRIX system.
Wanted: GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)


Top
 Profile  
 
Unread postPosted: Thu May 15, 2014 3:47 am 
Offline
User avatar

Joined: Thu Jun 17, 2004 11:35 am
Posts: 3930
Location: Wijchen, The Netherlands
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?

Code:
fuel # l1cmd serial all

Data                            Location      Value
------------------------------  ------------  --------
Local System Serial Number      EEPROM        12:34:56:78:9A:BC
Local Brick Serial Number       EEPROM        MED907
Reference Brick Serial Number   NVRAM         MED907


EEPROM      Product Name    Serial         Part Number           Rev  T/W
----------  --------------  -------------  --------------------  ---  ------
NODE        IP34            MED907         030_1707_002          D    00
MAC         MAC ADDRESS     NA             NA                    NA   NA
PIMM        hardware detected, read error
XIO         ASTODYB         MDG840         030_1725_001          D    00

EEPROM     JEDEC-SPD Info           Part Number        Rev  Speed  SGI
---------- ------------------------ ------------------ ---- ------ --------
DIMM 0     CE0000000000000026BAAE00 M3 46L3313BT1-CA0   0B   10.0  N/A
DIMM 2     CE0000000000000026C3AE00 M3 46L3313BT1-CA0   0B   10.0  N/A
DIMM 1     CE0000000000000028C12601 M3 46L3313BT1-CA0   0B   10.0  N/A
DIMM 3     CE00000000000000269CF500 M3 46L3313BT1-CA0   0B   10.0  N/A


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.

_________________
Now this is a deep dark secret, so everybody keep it quiet :)
It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi

Currently in commercial service: Image :Onyx2:(2x) :O3x02L:
In the museum: almost every MIPS/IRIX system.
Wanted: GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)


Top
 Profile  
 
Unread postPosted: Thu May 15, 2014 4:13 am 
Offline
User avatar

Joined: Mon Nov 10, 2003 5:17 pm
Posts: 2236
Location: Edinburgh, Scotland
*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.

_________________
(05/Aug/2014) FREE! (collection only) 16x Sagitta 12-bay dual-channel U160 SCSI JBOD units.
Email, phone or PM for details, or see my forum post.
mapesdhs@yahoo.com
+44 (0)131 476 0796


Top
 Profile  
 
Unread postPosted: Thu May 15, 2014 7:27 am 
Offline
User avatar

Joined: Thu Jun 17, 2004 11:35 am
Posts: 3930
Location: Wijchen, The Netherlands
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. :roll:

_________________
Now this is a deep dark secret, so everybody keep it quiet :)
It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi

Currently in commercial service: Image :Onyx2:(2x) :O3x02L:
In the museum: almost every MIPS/IRIX system.
Wanted: GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)


Top
 Profile  
 
Unread postPosted: Fri May 16, 2014 2:59 am 
Offline
User avatar

Joined: Thu Jun 17, 2004 11:35 am
Posts: 3930
Location: Wijchen, The Netherlands
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 :evil:

When the L1 boots, it spits out:
Code:
ALERT: PIMM EEPROM read error, no acknowledge

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:
Code:
M2100629-001-L2>serial set 08:00:69:0B:C3:C2
ERROR: invalid system serial number '08:00:69:0B:C3:C2'
System serial number must be [LMNPRTUW]0000000 through [LMNPRTUW]3999999

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
Code:
# l1cmd eeprom Fuel write default
MAC EEPROM already contains valid data

....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 :evil:

_________________
Now this is a deep dark secret, so everybody keep it quiet :)
It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi

Currently in commercial service: Image :Onyx2:(2x) :O3x02L:
In the museum: almost every MIPS/IRIX system.
Wanted: GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)


Top
 Profile  
 
Unread postPosted: Fri May 16, 2014 7:05 am 
Offline

Joined: Tue Feb 24, 2004 5:10 pm
Posts: 9721
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 :evil:

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.

_________________
There is a certain embarrassment at having a madman in the family.


Top
 Profile  
 
Unread postPosted: Fri May 16, 2014 4:24 pm 
Offline
User avatar

Joined: Thu Nov 08, 2007 5:35 pm
Posts: 702
Location: Lynnwood, WA
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.

_________________
:O3000: :Fuel: :Tezro: :Octane2: :Octane: :Indigo: :Indigo: :Indigo: :O2: :1600SW: :Indigo2: :Indigo2: :Indigo2: :Indigo2IMP: :Indigo2IMP: :Indy: :Indy: <--challenge S


Top
 Profile  
 
Unread postPosted: Mon May 19, 2014 7:47 am 
Offline
User avatar

Joined: Thu Jun 17, 2004 11:35 am
Posts: 3930
Location: Wijchen, The Netherlands
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:
Code:
SGI SN1 L1 Controller
Firmware Image B: Rev. 1.48.1, Built 01/22/2007 11:34:20


001a01-L1>serial all

Data                            Location      Value
------------------------------  ------------  --------
Local System Serial Number      EEPROM        12:34:56:78:9A:BC
Local Brick Serial Number       EEPROM        MED907
Reference Brick Serial Number   NVRAM         MED907


EEPROM      Product Name    Serial         Part Number           Rev  T/W   
----------  --------------  -------------  --------------------  ---  ------
NODE        IP34            MED907         030_1707_002          D    00   
MAC         MAC ADDRESS     NA             NA                    NA   NA   
PIMM        IP34PIMM        MDG739         030_1708_002          G    00   
XIO         ASTODYB         MDG840         030_1725_001          D    00   

EEPROM     JEDEC-SPD Info           Part Number        Rev  Speed  SGI     
---------- ------------------------ ------------------ ---- ------ --------
DIMM 0     CE0000000000000026BAAE00 M3 46L3313BT1-CA0   0B   10.0  N/A     
DIMM 2     CE0000000000000026C3AE00 M3 46L3313BT1-CA0   0B   10.0  N/A     
DIMM 1     CE0000000000000028C12601 M3 46L3313BT1-CA0   0B   10.0  N/A     
DIMM 3     CE00000000000000269CF500 M3 46L3313BT1-CA0   0B   10.0  N/A     

Continuing:
Code:
001a01-L1>help serial
serial
   shows secure system serial numbering information only.
serial verify
   test the brick's readiness for secure serial numbering.
serial all
   show system and brick part/serial numbers.
serial all v|verbose
   show system and brick part/serial numbers with EEPROM indexes
serial dimm
   show dimm part/serial numbers.
serial dimm v|verbose
   show dimm part/serial numbers with extended data and EEPROM indexes.
serial clear
   clear the system serial number.
serial <str> <str> <str> <str>
   erases and reassigns system serial number using temporary authenticator.
serial security on
   enables system serial number security.

001a01-L1>serial verify
Brick : OK

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 ;)
Code:
001a01-L1>serial set 0800690BC3C2
system serial number set "0800690BC3C2"
Reboot L1 to take effect.

001a01-L1>reboot_l1
ALERT: PIMM EEPROM read error, no acknowledge

SGI SN1 L1 Controller
Firmware Image B: Rev. 1.48.1, Built 01/22/2007 11:34:20


001a01-L1>serial all

Data                            Location      Value
------------------------------  ------------  --------
Local System Serial Number      EEPROM        08:00:69:0B:C3:C2
Local Brick Serial Number       EEPROM        MED907
Reference Brick Serial Number   NVRAM         MED907


EEPROM      Product Name    Serial         Part Number           Rev  T/W   
----------  --------------  -------------  --------------------  ---  ------
NODE        IP34            MED907         030_1707_002          D    00   
MAC         MAC ADDRESS     NA             NA                    NA   NA   
PIMM        hardware detected, read error
XIO         ASTODYB         MDG840         030_1725_001          D    00   

EEPROM     JEDEC-SPD Info           Part Number        Rev  Speed  SGI     
---------- ------------------------ ------------------ ---- ------ --------
DIMM 0     CE0000000000000026BAAE00 M3 46L3313BT1-CA0   0B   10.0  N/A     
DIMM 2     CE0000000000000026C3AE00 M3 46L3313BT1-CA0   0B   10.0  N/A     
DIMM 1     CE0000000000000028C12601 M3 46L3313BT1-CA0   0B   10.0  N/A     
DIMM 3     CE00000000000000269CF500 M3 46L3313BT1-CA0   0B   10.0  N/A     

001a01-L1>eeprom Fuel write default
MAC EEPROM already contains valid data
001a01-L1>

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.

_________________
Now this is a deep dark secret, so everybody keep it quiet :)
It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi

Currently in commercial service: Image :Onyx2:(2x) :O3x02L:
In the museum: almost every MIPS/IRIX system.
Wanted: GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)


Top
 Profile  
 
Unread postPosted: Mon May 19, 2014 10:20 am 
Offline
User avatar

Joined: Thu Nov 08, 2007 5:35 pm
Posts: 702
Location: Lynnwood, WA
If I get a chance I'll read the i2c 24C04 eeprom.

_________________
:O3000: :Fuel: :Tezro: :Octane2: :Octane: :Indigo: :Indigo: :Indigo: :O2: :1600SW: :Indigo2: :Indigo2: :Indigo2: :Indigo2IMP: :Indigo2IMP: :Indy: :Indy: <--challenge S


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 73 posts ]  Go to page Previous  1, 2, 3, 4, 5

All times are UTC - 8 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group