NetBSD support for Suns with dead IDPROM batteries
Erik Fair
However, a dead IDPROM battery doesn't mean a dead computer - it just means the computer has got alzheimer's and can't remember its name (hostid) and Ethernet MAC address ... or a boot device other than the default. Very often, what one gets out of that situation is all zeros, or all ones (broadcast) Ethernet MAC address.
NetBSD, of course, doesn't care what the MAC address is. However, we know that broadcast (all ones) is nonsense and will not work (in fact, will likely cause other problems). We could, as a matter of extending the useful (well, operational) lifetime of these systems, sanity check the MAC address of Suns at boot time to make sure they're not broadcast/multicast (or all zeros), and if they are, assign something somewhat more sensible (e.g. 8:0:20: + the last 24 bits of time_t from the root filesystem (since the TOD clock is likely to be wrong, too)).
I recognize that this won't help diskless, netbooted systems - they have to have a sensible MAC address as a condition of booting. It also makes the MAC address of these systems relatively unstable (I suggested (time_t & 0xffffff) as a way of avoiding MAC address collisions if there is more than one such system on the same LAN - if you've got a better suggestion for a source for additional bits in such a system, I'm ready to entertain it), so if you're providing IP addresses per MAC address with DHCP, or filtering on MAC addresses, you lose.
For those systems that have disks in the default boot configuration (e.g. appropriate internal SCSI bus id), this small change will extend the life of such hardware ... until something else fails.
What have I missed?
submitted for your consideration,
Erik <fa...@netbsd.org>
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Martin Husemann
> So I really, really don't see any need to to clobber NetBSD to work
> with defect hardware that is easy to fix.
Yes, but "clobber" could be a five line hack at the end of
src/sys/arch/sparc/sparc/promlib.c:prom_getether()
that does something like:
#ifdef SPARC_ETHER_OVERRIDE
static const u_char my_ether[] = { SPARC_ETHER_OVERRIDE };
memcpy(cp, my_ether, 6);
#else
/* Fall back on the machine's global ethernet address */
idp = prom_getidprom();
memcpy(cp, idp->idp_etheraddr, 6);
#endif
}
and you would add options SPARC_ETHER_OVERRIDE="0x08,0x...."
to your kernel config. (Not sure what syntax would be easiest to pass
through config here)
Martin
Erik Fair
On May 24, 2011, at 14:47, Jochen Kunz wrote:
> Even if you don't want to hack the hardware, you can reprogramm the
> ID-PROM after power up. It takes only a few simple Forth words, see the
> Sun NVRAM FAQ. The machine will run fine with a real Ethernet MAC
> address until powered down.
My suggestion obviates the need to reprogram the IDPROM manually at every power up. Further, according my research, the IDPROMs themselves cease to be programmable after a time.
der Mouse
> [...] sanity check the MAC address of Suns at boot time to make sure
> they're not broadcast/multicast (or all zeros),
I dunno; I think forbidding non-broadcast multicast addresses would be
preventing stupid things at the price of preventing clever things.
> and if they are, assign something somewhat more sensible (e.g.
> 8:0:20: + the last 24 bits of time_t from the root filesystem [...])
Hijacking Sun's vendor prefix is not my idea of sensible.
If you really want to do something of the sort, I'd strongly
recommending using locally-administered addresses (bit 0x02 of the
first octet set), at least by default; this strikes me as exactly the
kind of thing they're for.
> For those systems that have disks in the default boot configuration
> (e.g. appropriate internal SCSI bus id), this small change will
> extend the life of such hardware ... until something else fails.
No more than just adding a battery to the clock chip will. I wouldn't
call it "trivial", but it's certainly not all that hard for anyone who
knows which end of soldering iron to hold - which, I suspect, includes
almost everyone still trying to use Suns that old.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Jochen Kunz
Erik Fair <fa...@netbsd.org> wrote:
> the IDPROMs themselves cease to be programmable after a time
This never happened to me and as der Mouse pointed out this situation
is very unlikely to happen.
--
\end{Jochen}
\ref{http://www.unixag-kl.fh-kl.de/~jkunz/}