GentooThis forum is for the discussion of Gentoo Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
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:
There is someone able to explain me how to fix the problem?
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.
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?
[ 0.082924] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
[ 0.082931] pci 0000:00:1d.7: PME# disabled
[ 0.082981] * The chipset may have PM-Timer Bug. Due to workarounds for a bug,
[ 0.082983] * this clock source is slow. If you are sure your timer does not have
[ 0.082986] * this bug, please use "acpi_pm_good" to disable the workaround
[ 0.083057] pci 0000:00:1f.0: quirk: region 0400-047f claimed by ICH4 ACPI/GPIO/TCO
[ 0.083064] pci 0000:00:1f.0: quirk: region 0480-04bf claimed by ICH4 GPIO
[ 0.083091] pci 0000:00:1f.1: reg 10 io port: [0x00-0x07]
So I'm wondering whether this message could have impact on the clock precision and could create my problem.