Q: Bad ethernet adress for ec0:ff:ff:ff (SGI INDY destroyed??)
Stefan Söllner
My brother has an old SGI INDY. Whenever the system start an error occurs:
Bad ethernet adress...
Is that a configuration or a hardware problem?
When the system is running and the configuration manager is started, the
loading stops by: object manager not found. Can anyone give me some help?
The system is IRIX 5.2.
Another question belongs to the upgrade. I have 2 CDs with an upgrade to
6.2, but it doesn´t seem to work. Multiple errors after installation let the
system stop. Is it possible to upgrade the INDY (32MB) to ver. 6.2?
Thank you very much!
Stefan (bloody new...)
Emmanuel Florac
It's hardware problem, the Dallas chip is dead. Look in deja.com for
dallas chips in newsgroup archive to find sources to change it; by the
way there is a method to rewrtie the values in RAM before booting, that
follows privately....
You probably can't get the system to install properly without a valid
eth adresss.
--
------------------------------------------------------------------------------
Emmanuel Florac | Kreode technologies
------------------------------------------------------------------------------
Gl...@canit.se
+Emmanuel Florac <efl...@kreode.com> wrote
>It's hardware problem, the Dallas chip is dead. Look in deja.com for
>dallas chips in newsgroup archive to find sources to change it; by the
>way there is a method to rewrtie the values in RAM before booting, that
>follows privately....
Is this a common problem ? if so, is it possible to take a "safety copy" of
the chip with, let's say an EPROM burner ?
--
___ | Email 姣 Sha...@bay-watch.com
/ __\ __ | Homepage 姣 http://www.canit.se/~glenn
__ / /__ / /__ ____ ____ __ | IRC 姣 XT600 @ IRC-net
(__/ /_ // / -_) _ ) _ )__) | Amiga - Silicon Graphics - 8bit comps.
\___//_/\__/_//_/_//_/ | T h e K i n g d o m o f S w e d e n
Per Ekman
> > + On 24-Jun-00 00:11:30
> +Emmanuel Florac <efl...@kreode.com> wrote
>
> >It's hardware problem, the Dallas chip is dead. Look in deja.com for
> >dallas chips in newsgroup archive to find sources to change it; by the
> >way there is a method to rewrtie the values in RAM before booting, that
> >follows privately....
>
> Is this a common problem ? if so, is it possible to take a "safety copy" of
> the chip with, let's say an EPROM burner ?
Shouldn't be a problem, many medium-end EEPROM-burners work with
the DS-1386. But since the Indy can initialize a new chip itself
all you need is the undocumented PROM-monitor command that enables
you to twiddle the NVRAM-bits by hand to set the MAC-address.
*p
John Bokma
Per Ekman <p...@pdc.kth.se> wrote in article
<mjeaeg8...@toby.pdc.kth.se>...
What I find disturbing is that people in this group consider this "illegal"
and
act in a "contact me private" and "I should not tell you this" manner when
this question is asked. A while back I found the following page:
http://www.squirrel.com/squirrel/sgi-sysid.html
This should be in the FAQ. Repairing your system is *not* illegal. Setting
the address to something different is *not* illegal only weird. Setting it
to
something different to enable an unlicensed copy *is* illegal. The latter
however,
should not be used as an argument to "hide" the method of repairing the
ethernet address. People willing to use software illegaly do so. They
always
find somebody that can do the trick.
So put it in the FAQ, where it should be!
John
--
C A S T L E A M B E R http://www.castleamber.com/
software * development mailto:jo...@castleamber.com
David Williams
> The question which remains is how it is possible that this 'Dallas' chip
> is erased while the rest of the system is undamaged.
>
> -- Hans van der Voort
Hans,
The battery in the Dallas chip may have gone dead
long ago, you didn't notice it until the system was
powered off.
David Williams
> John Bokma wrote:
> > This should be in the FAQ. Repairing your system is *not* illegal. Setting
> > the address to something different is *not* illegal only weird.
>
> And breaks the ethernet segment you're on, possibly. This thing is used
> for MAC addresses for the ethernet as well, and while SGI guarantees the
> ones *it* burns are unique...
SGI may guarantee to make it good but that does not mean
that they have always shipped unique IDs.
I had to troubleshoot a wierd problem
where 2 IO4s had the same address! SGI had a database
problem for a time (so I was told) and DID make mistakes.
Alexis Cousein
> This should be in the FAQ. Repairing your system is *not* illegal. Setting
> the address to something different is *not* illegal only weird.
And breaks the ethernet segment you're on, possibly. This thing is used
for MAC addresses for the ethernet as well, and while SGI guarantees the
ones *it* burns are unique...
--
<standard disclaimer: these are my personal views, not SGI's>
Alexis Cousein a...@brussels.sgi.com
Systems Engineer SGI Belgium/Luxemburg
Hans van der Voort
>
> Hello!
> My brother has an old SGI INDY. Whenever the system start an error occurs:
> Bad ethernet adress...
> Is that a configuration or a hardware problem?
> When the system is running and the configuration manager is started, the
> loading stops by: object manager not found. Can anyone give me some help?
> The system is IRIX 5.2.
> Another question belongs to the upgrade. I have 2 CDs with an upgrade to
> 6.2, but it doesn´t seem to work. Multiple errors after installation let the
> system stop. Is it possible to upgrade the INDY (32MB) to ver. 6.2?
>
I had the same problem with our Indy after a mains power problem, I
thought
the ethernet hardware vaporized.
Fortunately Emmanuel Florac's tips to rewrite the ethernet address
worked fine: the system has its proper sysid again and the ethernet
works ;-).
John Bokma
Alexis Cousein <a...@brussels.sgi.com> wrote in article
<39577BB5...@brussels.sgi.com>...
> John Bokma wrote:
> > This should be in the FAQ. Repairing your system is *not* illegal.
Setting
> > the address to something different is *not* illegal only weird.
>
> And breaks the ethernet segment you're on, possibly. This thing is used
> for MAC addresses for the ethernet as well, and while SGI guarantees the
> ones *it* burns are unique...
The probability on a clash is 1 / (2^32), isn't it? However, what I try to
say
was: people who want it to use software illegaly always find a way, so
don't
give people who want to fix a hardware flaw a hard time... This should be
in the FAQ IMHO. I haven't had this problem yet, but I've seen this
question
very very often in this group and always there is some answer of the kind
"Pssst, I can help you but only via email....".
Kind regards,
Alexis Cousein
> where 2 IO4s had the same address!
That's an entirely different matter -- that's usually the result of
these having been installed with empty flash PROM on a system with the
same system controller (the logic for flashing IO4s has always been
extremely contorted, yes, and has given more snafus I'd care to mention,
so much so that on repairs I usually took two with me just in case ;) ).
We were talking Indies here, and I can assure you SGI never shipped two
identical sysids there -- and that the *official* procedure to get an
already assigned sysid reburned on a (new) motherboard+NVRAM when an
NVRAM lost its address was paranoid to the extreme ;). In other words,
that someone lurking on this forum knows more than what 99.9% of the SGI
field peons know, *really*.
David Williams
> David Williams wrote:
> > where 2 IO4s had the same address!
>
> That's an entirely different matter -- that's usually the result of
> these having been installed with empty flash PROM on a system with the
> same system controller (the logic for flashing IO4s has always been
> extremely contorted, yes, and has given more snafus I'd care to mention,
> so much so that on repairs I usually took two with me just in case ;) ).
Nope, the ethernet MAC address has nothing to do with the flash proms on
the
IO4 (maybe you're thinking about the serial number). The chip at location
C1L9 is where the IO4 gets the MAC address and that chip was burned by SGI.
--
Dave Williams - Technical Director - minicomputer exchange inc.
dav...@mce.com http://www.mce.com
TEL:408-733-4400; TOLL FREE:888-733-4400; FAX:408-733-8009
Alexis Cousein
John Bokma wrote:
> However, what I try to say was: people who want it to use software
> illegaly always find a way,
All the ISVs who now rely on FLEXlm on our systems disagree (rather
violently, in my own experience with the local ISVs) with you there.
In other words, if the SGI stuff behind the lmhostid wasn't deemed to be
relatively secure, you'd all be stuck with three dongles out the back of
the parallel ports (as I usually have to have on the 320s when I have
apps to demo -- obviously, no ISV trusts the flexlm id of any *other*
dongle that's installed, no, you need lots of them -- and, of course,
just as NVRAMs get erased, dongles break ;) ).
I find that a much "harder time", and it's also a gruelling and unending
pain, unlike what I have to endure to get an NVRAM reprogrammed (which
*is* a gruellingly paranoid procedure, yes, and I *do* have a 'support
contract', I'll give you that).
Frank
address was bad on the board. I opened the box, repaired the MAC address and
installed 6.2. it took about 15 mins. The person I got it from thought it
was useless and sold it for parts, (still didnt have a damn sled) If it
wasnt for that little trick the indy would be just a great monitor stand.
I guess because of the battery backed nvram this is problem is pretty much
unique to the indy? Could this happen to any other SGI system?
I understand software companies want to protect their products and SGI makes
it easy on them by using this method which the software compaines do not
have to add the overhead of dongals. Actually I have never seen any other
license system like SGI and have no idea what i am talking about when it
comes to FLexIM. but it sounded good. Maybe a process to change the mac
address renders the fLExIm useless and software companies would choose a
different platform?
and for the love of god , ADOBE let us download your old sgi software.
Frank
in article 3957EE39...@mce.com, David Williams at dav...@mce.com wrote
on 6/26/00 7:58 PM:
Hans van der Voort
>
> > The question which remains is how it is possible that this 'Dallas' chip
> > is erased while the rest of the system is undamaged.
>
>
> long ago, you didn't notice it until the system was
>
> powered off.
So I shut it off for a couple of hours more than during the power
problems. The system booted fine when I switched it on again...
Alexis Cousein
> Nope, the ethernet MAC address has nothing to do with the flash proms on the
> IO4 (maybe you're thinking about the serial number).
Yes. This thread had been talking about MACs and serial numbers for some
time (and while these are from an identical source on Indy, they are not
on Challenge).
gtx...@my-deja.com
(Indytech?) that had the procedure listed. I was under the opinion that
the serial number on the back of the Indy and the ethernet address were
the same... That is what I programmed into the NVRAM and I must admit
the system worked much better with a valid address :)
Aren't the two numbers the same?
BTW, I use my Indy for personal use with freeware only, so I haven't
encountered any of the software issues that have been discussed here.
Mike Harrington
g...@triad.rr.com
Sent via Deja.com http://www.deja.com/
Before you buy.
Walter Roberson
:I was under the opinion that
:the serial number on the back of the Indy and the ethernet address were
:the same...
:Aren't the two numbers the same?
Dave referred to the IO4, which is an important board for the
Challenge/Onyx L/XL series. The serial number for Challenge/Onyx is
NOT not ethernet address, it's a 5 digit number prefixed with 'S'.
(I don't know why 'S' was chosen.)
The serial number for the 4D/[23][05] was a 7 digit number prefixed
with 'E'. (The CPU board for the PI series was known as the 'EMOD'.)
The serial number for the Origin 2x00 series is a 7 digit number
prefixed with 'K'. (I don't know why 'K' was chosen.)