CMOS clock corrupted after reboot
 

Hi everybody,
I have a problem with a Panel PC having the following characteristics:
CPU Intel Celeron M 1GHz, SRAM 1GB, HDD 80GB, intel GMA graphic card, touch screen.
OS: Linux kernel 2.6.32-gentoo-r7

The problem is that random we found the CMOS clock corrupted: the time goes several days back.
This causes an error saying that "last boot was in the future" during the boot and requiring a disk consistency check.

Service ntpd is not enabled

In /etc/conf.d/clock we have the following settings:
CLOCK="UTC"
TIMEZONE="Europe/Rome"
CLOCK_SYSTOHC="no"

There is someone able to explain me how to fix the problem?

Regards

Is the battery OK? If it isn't, you will have problems.

The battery seems OK. I'm expecting to see the time set to 01 Jan 1970 if the battery is not OK or to have the date of the last shutdown. Isn't it?

Since the move to OpenRC, the clock settings are in /etc/conf.d/hwclock and the timezone information is in /etc/localtime and /etc/timezone. See here for details:

http://www.gentoo.org/doc/en/handboo...ap=7#doc_chap1
http://www.gentoo.org/doc/en/handboo...ap=8#doc_chap3
http://www.gentoo.org/doc/en/openrc-migration.xml

My system doesn't have the openrc, but in any case I'm wondering how it could affect the clock on the CMOS

Regards

If the battery is gone, it normally doesnt keep the time/date of last shutdown.

With most BIOSes, the date wont go back to 1970, it goes back to the date of BIOS version (so if the BIOS version you are using is from 25-12-2005, thats the date it will go back to with no battery).

If in the last CMOS versions we could have as default value the BIOS date, this is not a problem. The problem is that the wrong date I found was even not the BIOS date.

The strange behavior I found is the following:
I had the PC with the correct date inside working on it without problems. I didn't use it for 1 month, more or less, and when I switched it on again (in this case the system started correctly) I found a new date 2 months back with also a wrong time. Then I did a reboot and at the new boot I received the error of date inconsistency I reported in my first post and the system asked me to do a check of the disk. At this point I did a new reboot and I changed the date in the BIOS. This time the system did the boot properly, and I worked without problems.
After few days I switched on the PC and checking the BIOS I found the time back of some hours. Again I adjusted the time into the BIOS. Starting from that moment the device seems to work properly.

In the past I had a the same behavior doing a software change of date. I fixed the problem using the command "hwclock" (instead of the command "date") to change the date and time, doing an immediate reboot of the device after the change and avoiding the writing of the local time into the CMOS at the shutdown (CLOCK_SYSTOHC="no" in the etc/conf.d/clock file). This because I thought that something wrong was happening during the time writing on the CMOS.

Now the problem is back even without a change of date or time and happens randomly.

So I need to understand why this behavior happens to fix it because I have to use such type of PC on medical devices and I cannot accept that it is stopped in a such way having a wrong time and date.

Any ideas about it?

Your CMOS battery is probably just getting old and that's what's causing your time to jump around like that when you leave your system switched off for a while.

PC CMOS clocks do not keep time very well. That's why you should run something like ntpd to keep good time.

I don't know what you mean by a "software" change of clock. "hwclock" is a computer program, so you're still using software to set your time.

I know that CMOS don't keep time very well, but unfortunately I cannot have an internet connection (the device has to go in the operating room) to use ntpd, thus the only way is to let the user adjust the time acting through the user interface (this is the meaning of "software change of clock").
What I don't want is to see the device stopped with a command line screen asking for a disk control.
Is there a way to avoid this?

Regards

Checking the dmesg for errors I found these rows:
So I'm wondering whether this message could have impact on the clock precision and could create my problem.