[weblacky]

So I was doing the final check on a Indy I've been working on.  It has a normal DS1386-8K-150 RTC IC in it, keeps time, boots fine (though I bought the system last year...so fraudulent Dallas ebay seller during previous owner isn't ruled out).  Originally, I saw the machine was complaining about a bad MAC address...but had something like 08:01:69:....  So I said to myself, "Ah I guess the previous owner didn't set the MAC address correctly after replacing the RTC in the past...no biggie".  So I then tried to set it.  It took several methods/struggles but after a cold start and checking using SINGLE mode with netstat -ia...it matched the label.  I shut it down and unplugged it for the night.

I came back this afternoon and rechecked the MAC address.  Booting without error, but the GUI System Info and netstat -ia both say 08:00:69:XX:XX:XX...where the Xs are NOT FF but something different!!!

I have now witnessed this happen 3 times!!!!  The first part (first 3 values) are solid and don't seem to change, but the final 3 keep changing!!!  I'm running 6.5.19 (because I have the CROM media for now).

Has anyone seen this symptom before?  I'm moving ahead to another Indy that must have a BAD RTC as it doesn't know the time and I have to double-bump the reset (with rebuilt PSU, even) to get it to chime and start (and sometimes it errors on a CPU mem error).  I think it's bad NVRAM values messing up booting on the last one so I'll be drilling an RTC anyway.  But the previous Indy (the one I mentioned in the beginning) boots all the time, knows the time I set, and keeps the SGI-specific MAC address values...but keeps changing the last three values.

What the heck?

[wroteafaq]

I haven't seen any such, but have limited experience with Indys (I'm running one on my bench and have a few more on the shelf, but haven't needed to futz with it much).

The MAC address is kept in a Dallas part in that thing? That's weird enough that my first guess would be "bad RAM", so if you have another one that's behaving, swap it in.

[weblacky]

Yes, I thought it was a RAM issue at first, no change, also still required a double-bump of the PSU to restart, also I forgot to mention the PSU INSTANTLY tries to turn on when you plug it in (when fully wired to Indy). I’ll try removing the cover to see if it’s something as stupid as a button jam on the front, but I turn it off with the power button using unit 0 and that works fine (so it’s no permanently jammed, but I’ll try anyway).

Since the Indy mainboard is the only thing preventing the PSU from starting while plugged in it’s a mainboard issue but that could be corrupt NVRAM too.

I’ll check simple stuff when I have time, but also swapped out ALL the RAM, no affect.

I was consider swapping PROMs too, but I’ll fix the RTC first and then see what happens.

[Raion]

Fixed your initial post, which was formatted wrong.

[vishnu]

The 08:00:69 octet is the SGI "organizationally unique identifer" that they bought from IANA. The last three octets don't really matter but yeah that is weird that they're changing apparently of their own volition.

In the 90s, when we were first sneaking Linux boxes onto our corporate network (at the time the only "officially" allowed Unix boxes on the network were our SGI and Sun workstations), we weren't querying the network's dhcp server for an IP address, we were just assigning static addresses, but even back then the Linux networking stack was smart enough to tell us "hey you're not the only node on this subnet with that IP address."

[weblacky]

The 08:00:69 octet is the SGI "organizationally unique identifer" that they bought from IANA. The last three octets don't really matter but yeah that is weird that they're changing apparently of their own volition.

In the 90s, when we were first sneaking Linux boxes onto our corporate network (at the time the only "officially" allowed Unix boxes on the network were our SGI and Sun workstations), we weren't querying the network's dhcp server for an IP address, we were just assigning static addresses, but even back then the Linux networking stack was smart enough to tell us "hey you're not the only node on this subnet with that IP address."

Yeah, I was a Sysadmin in another life, vendor identifier was a thing I fooled with, I still think it could work quite well for a Roboinst server to live on my home network (only respond to SGI NICs).  But they aren't stored in a separate memory IC nor is it hard coded...I don't have a rational explanation for this behavior.  I'm hoping that a battery transplant is the answer...but I MAY decide the RTC is somehow unreliable as-is.