Ping Paul - Old CMOS issue?

Evening, Paul. Acouple of years ago you helped me understand (alittle)
how the ASUS Motherboard in my relatively
new ASUS build might contribute to the premature failure of the CMOS
battery. Based on your advise and my
unwillingness to try to return my new motherboard for this
characteristic, I Rearranged my rig to ensure that the PS was
always powered, thus ensuring that the CMOS battery was not strained.
Worked fine for almost a year until the other night when we
had an unwarned power failure. The Comp was not on at the time, though
the PS was. The lights flickered a few times and then went went dark
for some failure
underground a block away. When power was finally restored, some of the
USB accessories were lighted, though not
all. After that, I noticed the time/date was again wrong. Thinking that
I once again might have a CMOS battery
issue, I replace it. (getting very good at that)

Would still seem to resume at boot up where it had been turned off. I
now notice that after I reset to internet
time, that my RTC will move up to the point where I walk away and the
system "sleeps". I then takes up where it
left off at wake up.

Question: Do I need a new motherboard or a new power supply or what?

T2

MrTsquare wrote:
Evening, Paul. Acouple of years ago you helped me understand (alittle)
how the ASUS Motherboard in my relatively
new ASUS build might contribute to the premature failure of the CMOS
battery. Based on your advise and my
unwillingness to try to return my new motherboard for this
characteristic, I Rearranged my rig to ensure that the PS was
always powered, thus ensuring that the CMOS battery was not strained.
Worked fine for almost a year until the other night when we
had an unwarned power failure. The Comp was not on at the time, though
the PS was. The lights flickered a few times and then went went dark
for some failure
underground a block away. When power was finally restored, some of the
USB accessories were lighted, though not
all. After that, I noticed the time/date was again wrong. Thinking that
I once again might have a CMOS battery
issue, I replace it. (getting very good at that)

Would still seem to resume at boot up where it had been turned off. I
now notice that after I reset to internet
time, that my RTC will move up to the point where I walk away and the
system "sleeps". I then takes up where it
left off at wake up.

Question: Do I need a new motherboard or a new power supply or what?

T2

From your description, it sounds like write cycles to
the RTC aren't working.

It could be:

1) A failure of the ACPI object the OS uses, to get the BIOS
to load the new time value in the RTC. An OS issue ?
Maybe the call is made, and no error code comes back
or something.

2) A problem with the RTC inside the Southbridge/PCH.
Most of the failure cases I can think of, would cause
scrambled data. I don't know which clock the RTC uses
for register updates. Could be the 33MHz of the LPC
(low pin count) bus, as an example. I don't really know
architecturally, what bus the RTC is supposed be connected
to.

I would test the time setting capability from another OS.
Boot a Linux LiveCD, have it "update the time from the Internet".
Shut down from the LiveCD, boot up Windows... and the only
error at that point, would be in the time_zone hours (as Linux
uses UTC and Windows uses local time). But at least the
minutes and seconds should closely match the correct time,
and that would tell you the RTC got the writes properly.

Time keeping is kept in at least two places. The OS software
clock. The RTC. The RTC interface doesn't have a low enough
latency, to actually participate in computer operation, which
is why it's kinda a "write and forget" kind of thing.

Another idea comes to mind:

3) Something at boot time, has remembered the "original" time,
and at shutdown, that time is being used to over-write the
RTC value. Who or what would do such a thing ?

I wouldn't be buying a new motherboard quite yet, until I'd
completed an evaluation with an unrelated OS. And see whether
it cannot write the RTC either.

Paul

In article , lid says...

MrTsquare wrote:
Evening, Paul. Acouple of years ago you helped me understand (alittle)
how the ASUS Motherboard in my relatively
new ASUS build might contribute to the premature failure of the CMOS
battery. Based on your advise and my
unwillingness to try to return my new motherboard for this
characteristic, I Rearranged my rig to ensure that the PS was
always powered, thus ensuring that the CMOS battery was not strained.
Worked fine for almost a year until the other night when we
had an unwarned power failure. The Comp was not on at the time, though
the PS was. The lights flickered a few times and then went went dark
for some failure
underground a block away. When power was finally restored, some of the
USB accessories were lighted, though not
all. After that, I noticed the time/date was again wrong. Thinking that
I once again might have a CMOS battery
issue, I replace it. (getting very good at that)

Would still seem to resume at boot up where it had been turned off. I
now notice that after I reset to internet
time, that my RTC will move up to the point where I walk away and the
system "sleeps". I then takes up where it
left off at wake up.

Question: Do I need a new motherboard or a new power supply or what?

T2

From your description, it sounds like write cycles to
the RTC aren't working.

It could be:

1) A failure of the ACPI object the OS uses, to get the BIOS
to load the new time value in the RTC. An OS issue ?
Maybe the call is made, and no error code comes back
or something.

2) A problem with the RTC inside the Southbridge/PCH.
Most of the failure cases I can think of, would cause
scrambled data. I don't know which clock the RTC uses
for register updates. Could be the 33MHz of the LPC
(low pin count) bus, as an example. I don't really know
architecturally, what bus the RTC is supposed be connected
to.

I would test the time setting capability from another OS.
Boot a Linux LiveCD, have it "update the time from the Internet".
Shut down from the LiveCD, boot up Windows... and the only

Well, first of all, Win7 appears to be able to update the RTC since I
can update it from the InternetTime option in the DateTime settings in
control panel. Second, puting the comp to sleep also stops the RTC from
running as it picks up where it left off when it wakes up. Thirdly, I
don't have and don't know how to use a Linux LiveCD. How about the
Macrium Recovery CD?

T2

In article ,
says...

In article , lid says...

MrTsquare wrote:
Evening, Paul. Acouple of years ago you helped me understand (alittle)
how the ASUS Motherboard in my relatively
new ASUS build might contribute to the premature failure of the CMOS
battery. Based on your advise and my
unwillingness to try to return my new motherboard for this
characteristic, I Rearranged my rig to ensure that the PS was
always powered, thus ensuring that the CMOS battery was not strained.
Worked fine for almost a year until the other night when we
had an unwarned power failure. The Comp was not on at the time, though
the PS was. The lights flickered a few times and then went went dark
for some failure
underground a block away. When power was finally restored, some of the
USB accessories were lighted, though not
all. After that, I noticed the time/date was again wrong. Thinking that
I once again might have a CMOS battery
issue, I replace it. (getting very good at that)

Would still seem to resume at boot up where it had been turned off. I
now notice that after I reset to internet
time, that my RTC will move up to the point where I walk away and the
system "sleeps". I then takes up where it
left off at wake up.

Question: Do I need a new motherboard or a new power supply or what?

T2

From your description, it sounds like write cycles to
the RTC aren't working.

It could be:

1) A failure of the ACPI object the OS uses, to get the BIOS
to load the new time value in the RTC. An OS issue ?
Maybe the call is made, and no error code comes back
or something.

2) A problem with the RTC inside the Southbridge/PCH.
Most of the failure cases I can think of, would cause
scrambled data. I don't know which clock the RTC uses
for register updates. Could be the 33MHz of the LPC
(low pin count) bus, as an example. I don't really know
architecturally, what bus the RTC is supposed be connected
to.

I would test the time setting capability from another OS.

Tried the Macrium CD. Couldn't see any way to either look at or set the
RTC.

T2

MrTsquare wrote:
In article , lid says...
MrTsquare wrote:
Evening, Paul. Acouple of years ago you helped me understand (alittle)
how the ASUS Motherboard in my relatively
new ASUS build might contribute to the premature failure of the CMOS
battery. Based on your advise and my
unwillingness to try to return my new motherboard for this
characteristic, I Rearranged my rig to ensure that the PS was
always powered, thus ensuring that the CMOS battery was not strained.
Worked fine for almost a year until the other night when we
had an unwarned power failure. The Comp was not on at the time, though
the PS was. The lights flickered a few times and then went went dark
for some failure
underground a block away. When power was finally restored, some of the
USB accessories were lighted, though not
all. After that, I noticed the time/date was again wrong. Thinking that
I once again might have a CMOS battery
issue, I replace it. (getting very good at that)

Would still seem to resume at boot up where it had been turned off. I
now notice that after I reset to internet
time, that my RTC will move up to the point where I walk away and the
system "sleeps". I then takes up where it
left off at wake up.

Question: Do I need a new motherboard or a new power supply or what?

T2
From your description, it sounds like write cycles to
the RTC aren't working.

It could be:

1) A failure of the ACPI object the OS uses, to get the BIOS
to load the new time value in the RTC. An OS issue ?
Maybe the call is made, and no error code comes back
or something.

2) A problem with the RTC inside the Southbridge/PCH.
Most of the failure cases I can think of, would cause
scrambled data. I don't know which clock the RTC uses
for register updates. Could be the 33MHz of the LPC
(low pin count) bus, as an example. I don't really know
architecturally, what bus the RTC is supposed be connected
to.

I would test the time setting capability from another OS.
Boot a Linux LiveCD, have it "update the time from the Internet".
Shut down from the LiveCD, boot up Windows... and the only

Well, first of all, Win7 appears to be able to update the RTC since I
can update it from the InternetTime option in the DateTime settings in
control panel. Second, puting the comp to sleep also stops the RTC from
running as it picks up where it left off when it wakes up. Thirdly, I
don't have and don't know how to use a Linux LiveCD. How about the
Macrium Recovery CD?

T2

The system software-maintained clock and the RTC are
two separate things.

That makes it harder to tell if or when the RTC gets updated.

All we know, is at boot time, the RTC is copied to the OS clock.

When you set via Internet Time (NTP), the OS clock gets set
for sure. The RTC could get set then (cannot be observed),
or the OS clock could be transferred back to the RTC
at shutdown. Since the time is not corrupted on an emergency
power off, that implies the RTC is updated at the same time
as the OS clock.

Both clocks drift. They could be 50 to 200ppm static error.
And wander as the whim catches their fancy. A proper NTP algorithm,
computes the first order error at least (linear drift), and can
"leak out" corrections during the day (without consulting an NTP
server). So even when you don't "set Internet Time", a previous
drift calculation can be correcting the clocks as time passes.
I don't think the Windows one does that, but the popular
third party ones do.

*******

You can try a Linux DVD as an alternate OS. A Ubuntu one should
have a Date&Time, with an NTP implementation, and you can test
whether every time you boot that DVD, the time is maintained
or set in an intelligent fashion. It probably won't be - but I
haven't really got any good ideas as to how you go about
blocking RTC register access. The RTC reads must be working,
to be able to copy that "consistent/stale" initial value.

When you see a year value of "1970", that used to be an indicator
the RTC was all-zeros and the time value is the "beginning of epoch".
Some of my more modern motherboards here, no longer show 1970
after you change the CMOS battery, but again, I haven't any idea
why they would fiddle with the old 1970 manifest constant. The
date chosen is not the year of manufacture either. It's older
than that.

*******

All I'm trying to do, is save you the money of buying
another motherboard for nothing.

Internal logic in chips, hardly ever fails in service.
DRAM has a much higher failure rate (because it's a large analog
circuit that stores charge on a billion floating gates).
I've had a number of DIMMs fail over the years. Regular
logic has much better failure rates here.

Regular logic circuits are "driven", and even if leaking
a bit, it might not corrupt them. Most all of the failures
you see for regular logic, are I/O pad failures (perhaps
from ESD).

An example of an I/O pad failure, is one of my SATA cables
no longer works properly. That's the first one of those
I've had happen. And I'm not 100% sure it wasn't
a flaw in the hard drive SATA interface that did it.
The drive is quarantined (can only be used when
connected to a $30 SATA card) :-) It won't be connected
to any more motherboard ports.

Paul

In article , lid says...

MrTsquare wrote:
In article , lid says...
MrTsquare wrote:
Evening, Paul. Acouple of years ago you helped me understand (alittle)
how the ASUS Motherboard in my relatively
new ASUS build might contribute to the premature failure of the CMOS
battery. Based on your advise and my
unwillingness to try to return my new motherboard for this
characteristic, I Rearranged my rig to ensure that the PS was
always powered, thus ensuring that the CMOS battery was not strained.
Worked fine for almost a year until the other night when we
had an unwarned power failure. The Comp was not on at the time, though
the PS was. The lights flickered a few times and then went went dark
for some failure
underground a block away. When power was finally restored, some of the
USB accessories were lighted, though not
all. After that, I noticed the time/date was again wrong. Thinking that
I once again might have a CMOS battery
issue, I replace it. (getting very good at that)

Would still seem to resume at boot up where it had been turned off. I
now notice that after I reset to internet
time, that my RTC will move up to the point where I walk away and the
system "sleeps". I then takes up where it
left off at wake up.

Question: Do I need a new motherboard or a new power supply or what?

T2
From your description, it sounds like write cycles to
the RTC aren't working.

It could be:

1) A failure of the ACPI object the OS uses, to get the BIOS
to load the new time value in the RTC. An OS issue ?
Maybe the call is made, and no error code comes back
or something.

2) A problem with the RTC inside the Southbridge/PCH.
Most of the failure cases I can think of, would cause
scrambled data. I don't know which clock the RTC uses
for register updates. Could be the 33MHz of the LPC
(low pin count) bus, as an example. I don't really know
architecturally, what bus the RTC is supposed be connected
to.

I would test the time setting capability from another OS.
Boot a Linux LiveCD, have it "update the time from the Internet".

Well, at this point everything appears to be working except for the time
indications seeming to be retained from the last shutdown rather than
continuing to run through the "darkness". Also, considering that I have
been keeping the PS hot to avoid changing the CMOS battery, the RTC may
not be running at all. Based on that and your thoughts, it appears to
me that the RTC in my box is toast. I am able to reset a "clock" from
internet time and have it run as long as the OS is awake, but going back
to the into-the-"darkness" time when awaken or rebooted. Guess I can
live with that scenario for a while as I'm not running a real time
system here... ;) Thanks for your thoughts and assistance.

T2