| View previous topic :: View next topic |
| Author |
Message |
summonbaka
n00b
Joined: 30 Jul 2009
Posts: 11
Location: Tokyo
|
 Posted: Wed Feb 02, 2011 4:20 pm Post subject: Sys and Hw Clock problem: Sysclock goes 3 days into the past |
 |
|
As in subject, the system clock is acting crazy and erratically. This is a clean gentoo install on a new ASUS-ION motherboard.
The detailed problem is that the time displayed with $date is always wrong at system startup. I noticed this some time ago and i can't find the pattern, at first it was less than a day so I thought that /etc/localtime was incorrectly configured. I deleted localtime and recopied as per the gentoo manual but the problems persisted. Today (after some days without using it) before booting I checked the BIOS to see whether it was the hwclock that was drifting, but it was within acceptable range (~1 min) of the UTC time [2011/02/02 - 13:07]. But after booting the system time went to [2011/01/29 - 10:??] (!!!) and the output of #hwclock --show showed the same problem. I fixed the time with #date -u -s $currenttime and then #hwclock -systohc and only the the output was correct.
I've checked everything I know could be affecting it and I can't find the source. The only thing I haven't checked yet is if the problem is within the kernel, but I can't think where could something give that much problem to the hwclock.
What could be the cause? |
|
| Back to top |
|
 |
Bones McCracker
Veteran
Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.
|
| Posted: Fri Feb 04, 2011 7:07 am Post subject: |
|
|
Off the top of my head:
What happens when you boot it from a CD? (If the problem occurs there too, then it's not a problem with your Gentoo installation and it's probably a problem with the hardware.)
Do you have any initscripts or services running that change the date (e.g., are you running ntpdate at startup, or are you running ntp or something like it)? If so, try disabling them and see what happens.
Do you have RTC_DRV_CMOS enabled in the kernel? If the motherboard has a hardware clock other than that provided by the CMOS, is the correct driver enabled for it?
Did you update your BIOS? If you did, are you absolutely certain that the BIOS you installed is for the exact motherboard you have?
Are you booting into a desktop environment, such as KDE or Gnome? They have utilities that can adjust the date. If so, try booting without X to rule that out as a possibility.
That's all that comes to mind. Maybe others have more ideas. |
|
| Back to top |
|
|
alkan
Guru
Joined: 06 Aug 2004
Posts: 385
Location: kasimlar yaylasi
|
| Posted: Fri Feb 04, 2011 6:49 pm Post subject: |
|
|
I had the exact same problem a while ago. The reason was i compiled rtc (real time clock) drivers as modules in the kernel. And /etc/init.d/clock script was trying to load non existend rtc modules.
| Code: | /etc/init.d/clock
line81:
if [[ ${fakeit} -ne 1 && -e /proc/modules && ! -e /dev/rtc ]] ; then
modprobe rtc &> /dev/null || modprobe genrtc &> /dev/nulll
fi
|
I changed it to
| Code: | /etc/init.d/clock
line 81:
if [[ ${fakeit} -ne 1 && -e /proc/modules && ! -e /dev/rtc ]] ; then
modprobe rtc &> /dev/null || modprobe genrtc &> /dev/null || modprobe rtc-cmos &> /dev/null
fi
|
that solved the problem for me.
As far as i see, there aren't any rtc and genrtc modules anymore in the kernel. |
|
| Back to top |
|
|
Bones McCracker
Veteran
Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.
|
| Posted: Fri Feb 04, 2011 8:09 pm Post subject: |
|
|
Nice one alkan. 
I suppose we might have zeroed in on that using the fault isolation process I laid out, but that sound like it's probably the culprit.
By the way, the "clock" initscript is completely replaced in baselayout2 / openrc with a new "hwclock" initscript (which, incidentally, does include the logic alkan recommended, except in a different sequence which assumes rtc-cmos but provides for older kernels that might depend upon the rtc or genrtc modules):
| Code: | if [ ! -e "${rtc}" ]; then
modprobe -q rtc-cmos || modprobe -q rtc || modprobe -q genrtc
fi
|
My philosophy as it pertains to kernel modules is this: unless the hardware in question is itself modular (i.e. removable from the machine -- something you're likely to pull out and replace or disable at times), or unless you're configuring a kernel for use on multiple machines that may have different hardware of that type, there's really no reason to compile a particular driver as a module.
In the case of the RTC drivers, it's not like you are going to be disabling, removing, upgrading, or adding RTC hardware; it's basically part of the motherboard. So unless you're compiling a kernel that needs to be generic across multiple machines that have different RTC hardware, there really isn't a good reason that I'm aware of to make the RTC driver a module. If the driver is built-in, rather a module, the modprobe command in the initscript is bypassed. The new hwclock script does the same thing, although a bit more efficiently. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
