Hi Don,

Thanks for the advice. Sorry I've taken a week to reply.

I didn't expect it to make a big difference, because I thought that most
of the programs being loaded into RAM during the boot process would be
staying in the RAM. Also, once my old machine was up and running, it
often didn't use all the of the 1280 MB RAM. But I don't know of any way
of looking at RAM usage during the boot process.


Well -- you might be able to start "top -S -d1 -u -d1 40" from
one of the rc start files to capture the top 40 processes.

That's starting to sound complicated. For something which is a matter of
curiousity, anyway :-).

This means that perhaps my old NVRAM chips are worth preserving. You
mentioned a piece of software which could be used to stop the NVRAM
clock. I searched but couldn't find it online. Looking at the NVRAM
datasheet, it seems like it is not something which can be done with a
crocodile clip. The only reference I could find was for modifying the
contents of an ancient sun4c machine's NVRAM at the "ok" prompt, and I
couldn't immediately see how to use this information with a sun4u Ultra
2. Do you know of a source for software which can be used to stop the
NVRAM clock?


I don't remember for sure where I read about it, but it was
probably in the first hit on a Google search for "Sun NVRAM FAQ"

http://www.squirrel.com/sun-nvram-hostid.faq.html

That's the information that I had seen, too. I was just thinking that
there might be a piece of software which makes the process easy, but I
could not find any mention of it on that page.


This one was posted in February of 2004, FWIW.

And I see that the procedure only mentions the Sun 3/80 (68030
CPU) and the sun 4C (SS1 SS2 IIRC).

I'm not sure whether it would work on the Ultra-2 but I don't
see any reason why it should not, if you can get to the "ok" prompt.

I tried the method intended for sun4c machines on my Ultra 2. I get the
error "Fast Data Access MMU Miss" after the second command.


O.K. The Ultra-2 (and the rest of the ultra systems) at the
"ok" prompt are working with a FORTH interpreter, so you need to write a
program in that to get access to the EEPROM addresses. (Examples are
used for resetting the HOSTID and MAC address on Sun4u machines.)

That's useful to know. The "ok" prompt has always been something of a
mystery to me, even though I've figured out how to use it for a few
basic things.

My best guess is that the addresses for the Write and Stop bits given in
that document for the M48T02 chip are not the correct ones for the later
M48T59Y chip, which contains more memory.


Also -- there may need to be a different starting address when
you are working in that NVRAM on those systems.

Indeed. I was trying to figure this out from the data sheet, but failed.

From the M48T59Y datasheet I can understand the structure of the
register in which the Write and Stop bits are held, but I cannot
understand the syntax used at the "ok" prompt (or perhaps not: the
prompt is indicated by ?) to modify the contents of the register. I
cannot find any information online about this syntax other than the
NVRAM FAQ, which does not explain the syntax used to program the NVRAM
at bit level, as opposed to byte level.


It is working at byte level. You write 0x80 to set the
write-enable bit, then after you have entered the stop bit, you re-write
the contents of the time field, with a 0x0 where you had 0x80, so you
don't really care about the lost information in the lower bits.

How does 0x80 correspond to setting the write-enable bit to 1?

I'm sure that someone with more knowledge could figure this out, but I'm
reluctant to experiment with my working machine in case it ceases to
work. It also seems that the two failures which I thought were caused by
dead NVRAM batteries were not, so perhaps the M48T59Y has a longer
lifetime than the M48T02.


Or -- perhaps those machines are not old enough to have problems
yet. Remember -- as long as the machine itself is powered up, the
battery gives effectively its shelf life. Only when the machine is
powered down is the clock running from the battery instead of from the
system power.

Quite likely. Maybe I just need to wait a few years for the information
to appear.

If you really want to protect them, wire wrap a board which does
nothing but apply power to the power and ground pins for the chip. Feed
it 5V and forget about it. (Even add a battery to provde power if you
lose power to another hurricane. :-) If you wire-wrap multiple sockets
(for multiple NVRAM chips) put a sticky-note on each one to tell which
system it belongs in.

You might want to wire the address lines, and other inputs to
ground, so it won't pick up noise and get weird possible settings.

Good idea. This might be a simpler solution. I think I have a 5 V "wall
wart" adaptor somewhere. Or I guess I could just power up the unused
machine now and then, but that might not be so effective at preserving
the battery life.

Incidentally, what exactly does the phrase "wire wrap" mean? I think
I've followed your meaning, but I've not come across that phrase before.

There do not seem to be any documents
referring to NVRAM problems with the sun4u machines using the M48T59Y chip.


They just aren't old enough to have been sitting around
*unpowered* for ten years or so. :-) Start counting from when the
computer center retired the macines, not from when it was made.


Check the contents of your NVRAM chips (HOSTID and Ethernet MAC
address) and keep a hardcopy version in case you need to perform the
battery surgery which is documented in the website above.

For both the working motherboards I have, I've written down the details
displayed on the screen when the machine boots, such as the serial
number, ethernet address and host ID.


Good. Tape a copy to the machine itself.


For the machine I'm using at the
moment I've also saved a copy of the output of the command "eeprom -v".


What does the "-v" option do? It is present on my Solaris 10
one, but it is not documented in the man page under Solaris 10.

Same behavior in Solaris 2.6 on a SS-5.

I thought "-v" was a verbose option, which listed all the data stored in
the NVRAM. But it actually seems to give the same data as "eeprom"
alone, so the verbose option probably doesn't exist. I am probably
confusing it with "prtdiag -v", "prtconf -v" and "psrinfo -v".

Whether or not I need the extra details such as the system board serial
number, I don't know.


I think that the serial number is read from the board itself,
not from the NVRAM. In any case, it is present on the barcode label on
the system board.


I think that's all there was of importance in the post. I speculated a
little about whether common applications such as Firefox and Nautilus
are able to make good use of multiple processors on Sun workstations.
I'm still not certain. But I think that's all.


I depends on whether they are multi-threaded. Though they will
probably use other CPUs for plugins.

I did a bit of reading online and came to the conclusion that Firefox is
multi-threaded, but that one thread handles the user interface,
JavaScript, layout and image decoding. Probably this thread sometimes
gets bogged down!


O.K. Try moving to a Sun Blade 2000 with dual 1.2 GHz CPUs, and
8GB of RAM. You'll *still* find a browser coming to a halt from time to
time -- based on net delays to/from whatever site you are visiting.

The thing is, with a web browser, you often can't be sure what's causing
the delay.

At least with Sun machines, they don't seem to get slower with time like
Windows machines. One of my friends once said that Windows had a half
life of six months: i.e., the speed of your computer for most practical
purposes halves every six months.

Best wishes,

Chris