View Single Post
  #7   Report Post  
Posted to rec.crafts.metalworking
Christopher Tidy Christopher Tidy is offline
external usenet poster
 
Posts: 599
Default Ping: Don Nichols re. Sun workstation

Hi Don,

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 :-).



Normally, you can just use "top" to see what the most active
processes running are at any given time. The 40 there is to select 40
lines of output (for the top 40 processes), and some of the others are
to redirect a single snapshot to a file instead of constantly updating on
the screen as is the default (You are wanting to see this from before
you probably have a command line to use, which is why you put it in a rc
file so the machine runs it instead of you.


I can't find "top" on my Solaris 9 system. In which directory is it
normally located? It isn't a command that was introduced with Solaris
10, is it? I guess it's possible that its directory isn't in my PATH.

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.



Download a booklet from Sun's site on the commands present in
your major version of the OBP firmware.


Right. I'll have a look for that booklet. I haven't used the Sun
documentation website much since they started requiring a support
contract before you could download much of the documentation. But that
was a few years back. I think it may have changed back to being free.

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.



The problem is that you have no way of knowing where it is
placed in the machine's address space -- it could start anywhere, and be
remapped anywhere else by the firmware.

[ ... ]


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?



The register uses the MSB for the write-enable bit according to
the data which we have. 0x80 is the symbol for hex 80, which in binary
is: 1000 0000 (Broken into upper and lower nybbles corresponding to the
digits in the hex number.) So -- it sets the MSB (the write-enable bit)
to 1, and all others to zero.


I think I see. Does the "0x" indicate that the other two characters
represent a number in hexadecimal?

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.



:-)

And bear in mind that the Sun Blade 2000 (presumably and later
Sun machines) uses serial EPROMS for the NVRAM which does not need
battery backup -- and runs the clock chip from a coin cell in a holder
on the system board, so it no longer matters. :-)


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 provide 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.



Nope -- you need to power the chips *full* *time* to preserve
the battery life -- and they will eventually die just from shelf life
anyway. :-)


I just looked at the data sheet again. I thought at first that the
battery was rechargeable, which would seem sensible, but it seems that
it is not. Thanks for pointing this out!

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.



A method of construction which I like for quick-and-dirty
experiments. You don't have to make a PC board for it. Essentially,
each pin on each socket has a long square shaft with sharp edges. The
wire-wrap tool takes the 30 Ga solid wire and wraps it ten times around
the square pin under tension. There is enough pin length to allow three
wires to be terminated on there. There are tools which you can twirl
between thumb and index finger, or tools which operate by squeezing a
handle to get the 10 turns, or electrically or air powered guns for the
task. I have examples of all but the air powered version, and have
built entire CPU boards for a SWTP 6800 (to separate the baud rate
generation from the CPU clock generation so I could go to the full 2MHz
on the later 68B00 CPU chips). And I have built a special purpose
computer at work with mulitipile dual-port memory boards for a project.

It works quite well, and it is easy to revise the design at
need.


I seem to recall seeing circuits built like this under test in
laboratories before. Actually, I think I've seen one which had solder
over the wrapped wire.

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".



BTW -- for most things, unless you have set unusual things into
the EEPROM settings, such as a special boot device, you can simply use
the command "set-defaults" at the "ok" prompt. This does nothing to
restore the HOSTID and the MAC address, unfortunately. :-)


Shame it doesn't fix the HOSTID and MAC address. Would be a useful feature!

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.



Agreed.

My won favorite browser is Opera -- for the UltraSPARC machines
and several other flavors made by other companies, but not for the older
Sun machines. (Hmm ... it is compiled as 32-bit code, so maybe it will
work with the older systems -- if the needed shared libs are present.
Of course, I download the static version, so it is less sensitive to
changes in shared libs.


My favourite browser is Netscape 7. Unfortunately I've had to switch to
using Mozilla Firefox for daily use as Netscape is no longer updated. I
still use Netscape 7 for Usenet, though. I tried Opera once, but never
liked the look of it much. I preferred the look of Netscape or Firefox,
and there didn't seem to be an advantage to using Opera.

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.



Well ... part of that is that they get bogged down with spyware
and malware which starts chewing up CPU cycles.

Also -- the filesystem needs regular defragmenting.

And Microsoft keeps "improving" them by loading yet more stuff
in there with every service pack. :-)

And -- it all still has to continue working with ancient
programs which make it harder to patch for fixing security holes. :-)


I have never been sure how backward compatible Solaris is supposed to
be. I'm sure that on one occasion in the past I got a program intended
for Solaris 7 or 8 to run under Solaris 9.

Best wishes,

Chris