Nekochan Net

Hey, so I tried connecting my O350s together today, and it turns out they have the L1 PROM with system serial security (PROM 1.38.9) flashed on both PROMs.

So here's the bad part:
I went to boot them (* pwr up), and there was a serial number mismatch error (obviously). So I figured "oh, okay, I guess I'll run them by themselves". Disconnected them and... boom. Somehow they'd both set their serial numbers to M000000 (blank serial) and now won't boot at all (independently OR together).

Does anyone know how to fix the serial number, in any way (I don't have an L2 controller or anything, the only relevant hardware I own is two Origin 350s, a NUMALink cable, and serial)? I don't even care if they work together, just that they boot again...

_________________
<>

So the serial number isnt even on the casing anywhere?

_________________
R4600PC 133 MHz

Mac Mini 2.5GHz 8GB RAM
Raspberry Pi
Dell XPS M1530

whiter ran into a similar issue some time ago. Doesn't look too encoursging though

With those machines being rather recent 1GHz R16ks according to your signature - any chance they are still under support or at least you still have some contacts within SGI?

Well the only other thing to do is phone sgi support I prosume!

_________________
R4600PC 133 MHz

Mac Mini 2.5GHz 8GB RAM
Raspberry Pi
Dell XPS M1530

I'm going to ask around and see if I can find someone within SGI willing to help me out... I think that's pretty much my only hope.
I don't have any L1 PROM updates or I would reverse them and see if I could figure out how to bypass or fix the serial numbers somehow.
Pretty annoyed though, now I have two very fast bricks

_________________
<>

You have two L1 images, A and B. Maybe the non-default one is old enough? The idea would be to reboot the L1 into the older image on both systems, connect the two systems into one, and then (eventually) upgrade each of them. Or not.

_________________
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: (2x)
In the museum: almost every MIPS/IRIX system.
Wanted: GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)

Thanks, that was my first idea too.
But, sadly, it didn't work out, what I meant in my first post by "both PROMs" was both part A and part B of the flash

_________________
<>

Update, for anyone interested: tried emailing SGI, got a support ticket and one email asking who owned the systems and what their serial #'s were, told them, and ... nothing back (it's been a day now, so I'm guessing they don't plan on responding).
I think I might try calling, although really I'm still hunting for some SGI employee I can speak to directly (i.e. not via a support ticket where they'll try to bill it). According to a friend, all they need to do is go into a web-based secret generator on their Intranet and punch in the brick serials and target system serials and they get the secret back, so I should be able to convince someone to do it...

_________________
<>

godspeed.

_________________
(8x3.0ghz) (2x1.4ghz)

Guess that sgi only support their new machines apart from the octane 2 ( The support runs out in 2009)

_________________
R4600PC 133 MHz

Mac Mini 2.5GHz 8GB RAM
Raspberry Pi
Dell XPS M1530

Origin 350 is still firmly in support (last new ones were sold in 2006), I just don't have a contract

_________________
<>

Yeah, I know it's too late now, but I would have left them connected and attempted to clear one of the serial numbers. I've done this with both O300 and O350 and so far, managed to get at least one of them to clear its serial so the link would take. And yes, in both cases I received "serial number mismatch" errors and no power up - that's standard stuff.

The solution in my case was to enter the L1 of the brick I wanted to update and enter "serial clear". The brick then wiped its local serial, looked over the NUMAlink for the (valid) serial in the other brick, grabbed it and reprogrammed itself to this new number.

With both bricks wiped, you probably do require intervention from SGI though

_________________
Twitter: @neko_no_ko
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.

So a third, working system would do the trick?

I don't know if it's possible to hook up an O350 to an O300. In that case it might be worth sourcing an entry level O300 to do the trick. It would almost certainly be cheaper than getting hardware support on a 350, and SGI probably won't do much for you until you get a support contract.

_________________
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: (2x)
In the museum: almost every MIPS/IRIX system.
Wanted: GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)

I haven't tried that, but it sounds viable. If you could get one of the blanked bricks to gain a serial from a third O300 or O350, you might be able bring up the second brick against it.

Just make sure you do the "serial clear" from the L1 of one of the blanked bricks

_________________
Twitter: @neko_no_ko
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.

Hello all together,

I hope it's not too late to say please don't "serial clear" anything again. The system serial on a O 350 is saved two times in the system. One time in EEPROM and second time in the Dallas Chip DS1742 under the IO9 Board.
Some time ago I had a similar problem and the solution is to insert a DS1742 Chip with a legal SSN to your System.
(so if you have any friend how could send you his O350 Dallas Chip your problem is solved )
If the SSN in the EEPROM is clear it will be rewritten by the the Dallas Chip to the EEPROM, or if you have a factory
new Dallas Chip the EEPROM will will write the SSN to it. (It's bidirectional).
Another way is to get a L2 controller on which you can set manually a SSN which will be written to all atached, cleared Brick.

You can check that with the L1 command "serial all". And also with the entries in the log.
By the way there is no need to power up the system.
The only relevant command is reboot_l1.

I hope I haven't been too late to prevent you from more trouble by erasing the third SSN maybe.
And be careful about the O300 system I belive that these SSN starts with an L and the 350 with a M but you can check that with serial all.

Greets