The crystal oscillator may or may not be OK, but low voltage can still
cause the surrounding logic in the NVRAM chip to malfunction, or an IO
signal from low to high voltage to be interpreted as the wrong logic
level. Remember -- the claimed problem is not that the clock is slow
but that the time is stuck.
I can't help with the NVRAM on old systems, but FWIW an x86 system I
used to have here at home would randomly change clock times when running
by numbers of hours/minutes/days/years while running, for example
changing the month and year but keeping the rest of the date fields
constant, even when running NTP. So there's definitely a possibility
for the clock to get messed up when the system is running, unless my
issue was an x86-only thing.
If the NVRAM is busted, then presumably boot after minutes or hours of
power off won't keep proper time. And on the other hand, if the system
survives being powered off for a while, the hardware clock may be OK.
Hugh.
On 11/23/13 6:49 PM, Michael Stapleton wrote:
My understanding is that the time is read from the NVRAM chip only once
when booting, then the time is updated by the kernel clock() function by
interrupt 10 while running.
High interrupt rates could cause the clock interrupt to be missed,
slowing time. A lot of serial activity could cause it.
I also do not see how low power could slow down the timer assuming it
uses a crystal oscillator.
All that to say that I bet it is not related to the NVRAM chip.
Mike
_______________________________________________
OpenIndiana-discuss mailing list
[email protected]
http://openindiana.org/mailman/listinfo/openindiana-discuss
