hwclock (BIOS): time set wrong during shutdown and also reboot.
 

System time was drifting ahead increasingly for several days time in the end. This is what I did with the clock about 6 hours "in the future":

i.e. I got the (more or less) exact time from the time server and set the hardware / BIOS timer with this value. I renamed "/etc/adjtime" to beginn with a clean slate.

During reboot (shut down phase) I noticed a message saying something like: "hwclock set to system time". I checked in the BIOS and there was a new time about one hour early(!).

The boot phase then reset the time again, this time several hours forward (usually two to six hours).

This is an iterating process, with a net gain of several hours per boot. It is not always whole hours -- like in a time zone error but it involves also minutes. System is set to UTC as affirmed by the "date" command.

What could be the cause of this behaviour of the clock / timer?

Hi

May sound counter-intuitive - are you switching the system OFF between reboots?

E. g. doing complete shutdowns and restarts?

'cause I once had this due to a CMOS battery on the motherboard that was going down. Replaced the battery, and the problem stopped.

Also, I encountered clock slowdowns on older kernels (FC3 and Red Hat 9) while raytracing. Raytracing tends to up the load average to 1 quite easily, depending on how heavily those older kernels were loaded with raytracing jobs (PovRay) (at least on my system / environment) they tended to slow down the clock more and more.

Hope this helps some. If I were you first place I'd look would be the motherboard CMOS battery - IF you are shutting down your system completely between reboots.

As I hinted in this post in your other thread on the same subject, the problem could be a defective real-time clock -- that's the slow-access, battery-backed clock that Linux saves the system clock time to during shutdown. Because this clock is usually incorporated in the Southbridge chip in current three-chip chipset designs and Southbridge chips are usually soldered to the motherboard and therefore are very difficult to replace, the most likely explanation of the symptoms you describe is a defective motherboard so the solution is to replace it.

The clock went fast when the battery was run down?

EDIT: @JZL240I-U: if so, it's got to be worth trying a battery change first -- it's a lot cheaper and easier than replacing the motherboard -- but the very variable time change you have reported is not typical of batteries running down when they run progressively slower (AFAIK, could be wrong) until they no longer hold the time and reset to beginning of epoch or BIOS release date.

Not always. These symptoms also occur when I do a "shutdown -r now".

I'm not but I can try it anyhow, I'm desperate enough.

Thanks for your input.

@catkin I realize that this is the same problem. In that other thread I asked the wrong question: "Clock jumps hours ahead after boot". That doesn't include the weird behaviour during shutdown, the combination of which I hoped would point the experts in the right direction. Nor can I change the title / thread name at this point, so I started an other thread, hopefully with a topic better corresponding to the problem.

BTW. when I switch the battery will the CMOS not forget everything?

Then it's not the battery.
Sorry if I came across as critical; it wasn't intended; I just like to link these things together for the benefit of anyone who finds these posts in a netsearch. It's a good idea to start a new thread with a more appropriate title when the problem area shifts.

BIOS settings used to be lost on changing the CMOS battery but more recent BIOSes have a save and restore facility that does automatic "last known good" saves. The motherboard manual should give details or you could enter the BIOS setup and see what options are listed.

Good idea :). It is a fairly modern Gigabyte board (see my "sig). On the other hand, since you think it's not the battery at all... Phew, and now?

Nice boards, Gigabyte. I'm using a GA-MA770-DS3 which is one of the very few which support ECC memory (so it will be nice when the EDAC project supports Athlon64 processors!).

It has the BIOS save and restore facility but it is not documented in the manual.

Now? If I were you I'd be looking to beg, borrow or ... a known good similar motherboard (or just any motherboard that will accept your devices that plug into the motherboard -- Linux is pretty good at adapting as long as you don't have a customised kernel that only supports the actual hardware). If I couldn't find one I'd just get a new one -- they're not so expensive and I'm 95% sure that's where the problem lies.

If necessary I still have warranty on that board. I'll give it another try tonight, after that I'll have to contact my dealer. Thanks for your input catkin.

On the other hand ... I'll do a long term test (overnight is enough) and have a look whether the hardware clock runs stable. If so, it must be some service during boot and shut down what is causing this...

That will not test the real-time clock (RTC) -- that's the slow-access, coarse-resolution, battery-backed clock -- because the system will be running on one or more of the system clocks -- the fast-access, fine resolution, non-battery-backed clocks (such as the HPET clocks) which are read so frequently that they are built into the CPU chip itself for performance reasons.

Indeed. But I could access the hardware clock with

But that was not necessary after all. I booted into my old SuSE 11.2 and did some work there -- with no adverse effects on the time whatsoever. Next I booted 11.3 and *blam* all that hassle began again at once: proof that it is a software effect after all, the clock is not lagging but jumping. I then rebooted without correcting the time and it jumped an additional whole day (24 hours).

I then did a

To get time back to reality. And the BIOS time was still fine :scratch: What's next?

I guess I could re-install but I'd hate to do that without understanding the cause of the current problem...

SuSE 11.2 was a good test and suggests that the truth is my 5% uncertainty :redface:

I empathise with your desire to understand the cause of the current problem but don't know how you can dig deeper ... there are probably ways, I just don't know them.

No reason to blush, I only had the idea late yesterday evening after now several days of delving into the problem.

Well, I'll probably open yet another thread, probably in the "kernel" forum, I'll just have to think on a good title to get the knowledgeable people attracted.

Btw., I followed your HPET-link and compared it to the German version, where it says
Tonight I'll have a look whether my board offers this choice...

It doesn't.

The solution to the problem is described here:

http://www.linuxquestions.org/questi...hutdown-844592

For those in a hurry: I had a custom initrd not of my making, which lacked some ingredients. Read all about it in the linked thread ;).

Thanks for your efforts and input catkin :).