I've got an odd problem with my motherboard - the BIOS clock (the RTC when the system is powered) runs twice as fast as it should - for each second that passes you see the system time in the BIOS getting incremented by 2 seconds. So you'll see 11:04:05, then 11:04:07, then 11:04:09, etc. So if you sit in the BIOS for a period of time, say n minutes, the BIOS would think that 2 x n minutes have passed.

This only happens if the system is powered - when the system is powered down (and no power is supplied to it) and the RTC is running off the battery, time progresses at the pace you would expect it to - if the system has been shutdown (and power removed from it) for 12 hours, when you turn it on the BIOS clock thinks that it's 12 hours later than it was when you shut down. All normal.

Both Windows and Linux have their system time (the software clock) running normally, with each second being counted as a single second.

Under Windows some investigation with a little utility called ClockWatch (from http://www.beaglesoft.com/clwahome.htm), allowed me to display both the system time (the software clock) and the BIOS time (as shown here http://www.beaglesoft.com/clwabiosclock.htm). If I do this I can clearly see that every second, system time gets incremented by one second while the BIOS time gets incremented by two. Using hwclock under Linux this same behaviour can be seen.

The motherboard in question is an Asus M3A AM2+ board. I inherited this board after it's owner bricked it via a bad BIOS flash. I recovered it by manually flashing the EEPROM using the onboard SPI header. This was successful and the board runs well, but it's had this issue with the RTC every since I got it working.

So, first thing I tried was a new CMOS battery. Inserting a brand new CR2032 button cell showed no change in behaviour.

Next I tried clearing the CMOS. Successfully cleared, but still no better.

Perhaps a BIOS bug in 1206 (the version I'm running). I reflashed the BIOS back to the first release version (0301) and cleared the CMOS, still no change. I tried four more BIOS versions but all of them had the clock running twice as fast as it should.

Looking around I found an obscure forum post from somewhere (forgotten where now) suggesting that there was once an incompatibility between nVidia cards and certain ATI/AMD chipsets causing odd system clock behaviour so out went the 9600GT and in went an old S3 Virge/DX PCI video card. Still no change.

Okay, how about the CPU: swapping out the Athlon II X2 250 with an Athlon II X4 620 didn't help. How about we reach back in time and try a Phenom X3 8450 (which had to be used for the early BIOS version testing)? No change seen. Trying both the Athlon II X2 250 and the Athlon II X4 620 in another board showed no weird BIOS clock behaviour there.

The internal RTC is made of two parts: one is an analog circuit, powered by a battery VBAT, and theother part is a digital circuit, powered by a main power VDD. Figure 5-5 shows the block diagram of theinternal RTC.

It sounds like the analog portion of the RTC is working correctly, but the digital portion isn't. Now to work out how to diagnose further...

So, that's the story. Has anyone every seen something like this?

Now I know this problem can be worked around in software by a number of different methods: syncing the BIOS clock with the system clock prior to shutdown, using NTP, etc; but I'm really curious to see if the underlying hardware can be fixed, or even to better understand what's causing this. I guess this can be put in the "intellectual curiosity" bucket

I also thought that may be something to look at because the first time I got the board alive and kicking again it was with the latest 1206 BIOS. But when I tried to downgrade BIOS versions with afudos, which I think kept the boot block from the 1206 BIOS, it lead to a few problems with the very old BIOSs (POST was buggy). So I also manually SPI-re-flashed the board with the original 0301 BIOS including boot block, but this didn't make a difference - BIOS clock still speeds along at twice the speed.

It's actually even more irregular than I made it out at the start - it can occasionally get incremented by one which can change it from counting evens to counting in odds, or it can even jump three seconds at times as well. It seems like once the system idles and there's no real activity though it settles to counting in twos (which is by far the most common seen behaviour).

Sounds like the quartz crystal that regulates the RTC is damaged or defective.

I'm not sure what you mean by: "It seems like once the system idles and there's no real activity though it settles to counting in twos (which is by far the most common seen behaviour)." though. If you're sitting in the BIOS looking at the hardware clock, the system is idle by definition.

The years just pass like trains. I wave, but they don't slow down.-- Steven Wilson

I thought that at first too, but when power is removed from the system and the RTC is running off the button cell it seems to track time normally. I'll double check again tonight, but I remember testing it fairly early on...

It would be good if it was the crystal - it's easy to replace.

I suppose I could check the waveform coming from the crystal with a CRO (I should be able to borrow one without too much hassle).

just brew it! wrote:Sounds like the quartz crystal that regulates the RTC is damaged or defective.

I'm not sure what you mean by: "It seems like once the system idles and there's no real activity though it settles to counting in twos (which is by far the most common seen behaviour)." though. If you're sitting in the BIOS looking at the hardware clock, the system is idle by definition.

Yeah, sorry I didn't explain that very well. If I sit there in the BIOS not pressing any keys it will almost certainly count in twos, but if I move around in the BIOS - selecting different options (which is highlighted), or moving between screens it can make the clock count in three or one second increments too (usually just one three or one second increment before it returns to counting in twos).

Ok, that's just weird. I do note that it updates once a second but updates by one, two, or three. Without knowing how the BIOS is reading the RTC, it's hard to say. However, if the RTC is behaving the same once an OS like Linux is running, then the problem is not in the BIOS code and is probably hardware. Since the RTC seems to run fine with power off, the crystal is fine. Could be a bad cap letting noise into the analog section of the RTC causing multiple erronious second ticks.

SecretSquirrel wrote:Could be a bad cap letting noise into the analog section of the RTC causing multiple erronious second ticks.

I seriously doubt that. The RTC crystal oscillates at a fairly high frequency (typically in the tens of kilohertz) and gets divided down by a digital divider. After seeing the video, I think it is safe to say it isn't a problem with the crystal itself either. This has almost got to be a bad CMOS clock chip (are those typically part of the southbridge?), or a problem with the BIOS. I suppose depending on how the clock setting function is implemented in the BIOS it *might* also be possible for bad RAM to cause this, but then I'd expect other stuff to be acting wonky as well.

The years just pass like trains. I wave, but they don't slow down.-- Steven Wilson

I've tried a few different DIMMs in the board but they all have the same behaviour (and they all work and pass memtest in this and another DDR2 board).

I'll double check the RTC behaviour when it's running off the button cell again when I get home tonight and let you know (though I'm pretty sure it was keeping time well on battery power).

It may be completely unrelated but I thought the board ran down the CMOS button cell faster than I was expecting (in a couple of months), but the button cell may have been sitting on the store shelf for years before I bought it...

I believe the CMOS clock chip is part of the southbridge - from the SB600 datasheet:

Last edited by loophole on Tue Oct 25, 2011 5:23 pm, edited 1 time in total.

Re-reading your OP and looking at that diagram, I'd say this strengthens the case for the Analog portion being fine; once the system is powered up, something in the Digital portion is either malfunctioning (hardware problem) or getting mis-configured (BIOS problem). I don't think we can really say much more than that... and you'd already figured this much out when you originally posted.

Which variant of the M3A is this? I have a couple of M3A78-CMs myself. Some early versions of the BIOS did result in some weird timekeeping issues in Linux; it wasn't off by an entire factor of 2, but the clock would routinely lose several minutes over a period of just a few hours. It was so far off that the Linux NTP service wasn't able to achieve a lock with the Internet time servers and would throw up its hands, log an error message, and give up. This was fixed in one of the BIOS updates, however.

Edit: Your link to the Windows vid still points to the BIOS one. I found the Windows one anyway. This is probably completely different from the time issue I was having in Linux with the old BIOS. In my case, it was the system time maintained by the OS that was going off; Linux syncs the CMOS time to the system time at shutdown (so the "bad" time was getting written back to the motherboard whenever the system got rebooted). I suspect that in my case the problem was that the BIOS was mis-configuring the system clock generator which is used to derive the CPU clock...

The years just pass like trains. I wave, but they don't slow down.-- Steven Wilson

SecretSquirrel wrote:Could be a bad cap letting noise into the analog section of the RTC causing multiple erronious second ticks.

I seriously doubt that. The RTC crystal oscillates at a fairly high frequency (typically in the tens of kilohertz) and gets divided down by a digital divider. After seeing the video, I think it is safe to say it isn't a problem with the crystal itself either. This has almost got to be a bad CMOS clock chip (are those typically part of the southbridge?), or a problem with the BIOS. I suppose depending on how the clock setting function is implemented in the BIOS it *might* also be possible for bad RAM to cause this, but then I'd expect other stuff to be acting wonky as well.

I wasn't thinking that it was interfering with the crystal signal, but further down the chain -- mucking with the counter that represents the seconds digit. The read of the RTC from the OS doesn't execute any BIOS code at all. The RTC registers are available in the PCI address space. Once Linux loads, for example, the BIOS is dormant. I would expect a problem in the RTC registers or buffer RAM to cause the time to occasionally run backwards too.

Certainly a bizarre problem, and given what the OP has already done in swap-tronics and BIOS flashes, I would say the only solution will be a different motherboard.

After a bit more Googling around, it seems that other people have had similar issues with M3A/M4A motherboards. A couple of people claim to have fixed it by manually setting the memory timings?!?? (Makes no sense unless there's some sort of bizarre BIOS bug that causes the automatic memory timings logic to sometimes screw up the RTC... but it is worth a try!)

I have to say, I've owned/own a number of Asus motherboards, and other than the clock drift issue mentioned in the previous post I've never seen anything like this.

The years just pass like trains. I wave, but they don't slow down.-- Steven Wilson

As an interesting test, you could pull the CPU and power the board on. Wait some amount of time then replace the CPU and start up the system. If time has run fast, the you know for sure that it is a hardware issue with the South Bridge. Now, if it doesn't run fast, this doesn't rule out anything other than that switching from battery to system power doesn't, in and of itself, cause the problem.

just brew it! wrote:Re-reading your OP and looking at that diagram, I'd say this strengthens the case for the Analog portion being fine; once the system is powered up, something in the Digital portion is either malfunctioning (hardware problem) or getting mis-configured (BIOS problem). I don't think we can really say much more than that... and you'd already figured this much out when you originally posted.

Which variant of the M3A is this? I have a couple of M3A78-CMs myself. Some early versions of the BIOS did result in some weird timekeeping issues in Linux; it wasn't off by an entire factor of 2, but the clock would routinely lose several minutes over a period of just a few hours. It was so far off that the Linux NTP service wasn't able to achieve a lock with the Internet time servers and would throw up its hands, log an error message, and give up. This was fixed in one of the BIOS updates, however.

Edit: Your link to the Windows vid still points to the BIOS one. I found the Windows one anyway. This is probably completely different from the time issue I was having in Linux with the old BIOS. In my case, it was the system time maintained by the OS that was going off; Linux syncs the CMOS time to the system time at shutdown (so the "bad" time was getting written back to the motherboard whenever the system got rebooted). I suspect that in my case the problem was that the BIOS was mis-configuring the system clock generator which is used to derive the CPU clock...

This is actually the original M3A - RX780 with SB600 southbridge.

Or maybe I should say "was" - while playing around last night to make sure that on battery the time keeping is correct, I think the board may have finally given up. After putting a new button cell in there and configuring all the BIOS settings correctly I powered down for a few minutes (and removed power) to make sure that the test was actually going to work (that the time and BIOS settings would be kept), but when I tried to power up the system again I was greeted with nothing at all. Playing hardware swap-sies didn't reveal any bad news about any of the other components but I didn't have time to try and read the SPI ROM externally to make sure that something hadn't happened to it. Maybe the SPI ROM could have lost it's data/state?

just brew it! wrote:After a bit more Googling around, it seems that other people have had similar issues with M3A/M4A motherboards. A couple of people claim to have fixed it by manually setting the memory timings?!?? (Makes no sense unless there's some sort of bizarre BIOS bug that causes the automatic memory timings logic to sometimes screw up the RTC... but it is worth a try!).

I was setting the RAM timings manually early on but I have to admit that while I've played with the system lately the timings were set to auto. If I can revive the board again I'll try with manual timings. One more thing to try

SecretSquirrel wrote:As an interesting test, you could pull the CPU and power the board on. Wait some amount of time then replace the CPU and start up the system. If time has run fast, the you know for sure that it is a hardware issue with the South Bridge. Now, if it doesn't run fast, this doesn't rule out anything other than that switching from battery to system power doesn't, in and of itself, cause the problem.

loophole wrote:This is actually the original M3A - RX780 with SB600 southbridge.

Or maybe I should say "was" ...

I just had an older M2A-VM HDMI apparently give up the ghost a couple of weeks ago as well. All of a sudden the screen just froze, and the system became completely unresponsive. Cycled the power, and it wouldn't even POST. Haven't had time to do much in the way of troubleshooting yet other than swapping the PSU, but it is acting like a dead mobo (the LED that indicates standby power comes on when the PSU is plugged in, but there are no other signs of life when I short the ATX power pins on the front panel header).

The years just pass like trains. I wave, but they don't slow down.-- Steven Wilson

Okay, we're back alive and working again. It seems that the SPI ROM had lost all of its contents. Relfashing the board externally with the latest BIOS brought it back to life. Still, not a good sign...

So, I then tried with all the RAM timings set manually in the BIOS but that didn't change anything - we're still counting in (usually) twos.