最近刚升级到X64位linux系统，用的centos 5，升级了内核到2.6.26.8，但发现系统时间总是不对
#hwclock --debug
hwclock from util-linux-2.13-pre7
hwclock: Open of /dev/rtc failed, errno=19: no such file or directory
No usable clock interface found.
Cannot access the Hardware Clock via any known method.
#ll /dev/rtc*
crw------- 1 root root 10, 135 Jan 12 2009 /dev/rtc
crw------- 1 root root 254, 0 Jan 11 19:06 /dev/rtc0
尝试升级内核到2.6.28，不行；
使用网上提供的解决方式，重新编译内核时编译选项：
Device Drivers;
* Real Time Clock;
* PC_style 'CMOS'
将Real Time Clock和其下的选项PC_style ‘CMOS’都直接编译进内核，但在我的尝试中2.6.26/2.6.28都没有成功；
使用CLOCKFLAGS=”–directisa”来执行hwclock
在将/dev/rtc删除后 ln -s /dev/rtc0 /dev/rtc后可以使用hwclock更新cmos时间，但重启后时间仍然不对；
又尝试使用noacpi apic=off应为noapic acpi=off的参数给内核，仍然不起作用；
最后使用32位的hwclock来取代64位系统上的程序后，系统时间终于恢复正常了。
注：hwclock属于util-linux包，将其解开后替换到/sbin目录就可以了。
hwclock在64位系统上的时间同步问题很普遍，希望这篇文章能给同样受困扰的朋友一点帮助。
—————————————————————————-
Update by latteye
我在公司的机器部署中也遇到了这个问题，都是在 CentOS 5.3 使用新内核的时候才会遇到。
实际上这是 Fedora、RH 系列的一个小 bug。
在老式的 mkinitrd 命令工作时，会将 /dev/rtc 生成好，放在 initrd 文件中。
但是新的 kernel 是自己生成的 /dev/rtc 文件的，当 kernel 生成 /dev/rtc 文件时，发现已经有 rtc 设备了。于是就将 /dev/rtc0 创建了出来。
应对这个问题，hwclock 做了调整，新的 hwclock 已经支持寻找 /dev/rtc0 设备。但在 CentOS 5.3 上使用新的 hwclock 时发现系统关闭时硬件时间同步正常，系统开机时并不正常。不过这不影响使用。
从 log 看来，最完美的解决方案就是使用 32 位的 hwclock ，是否使用，大家根据自己的环境斟酌。
apic=off的方式似乎是不对
noapic acpi=off是肯定能用的参数
另外尝试看看
date的输出和hwlock –show看看有没有一个是准确的，前者是系统时间，后者是BIOS时间。
[回复]
谢谢mlsx指出 apci和acpi的参数的确比较搞 我最后是试了把所有可能的组合都加了 但在这个问题上没有效果
date和hwclock应该两者表示的是相同的时间 但如果rtc出现问题时 它们之间就会有时差。
这个问题一是导致系统启动和关闭时默认与BIOS时间的校对失败 同时引起不必要的文件系统自检
[回复]
我的时间也是不对，不过我的就是32位的，ArchLinux
动不动就快10天。。。
[回复]
能不能做个NTP服务器？
[回复]
latteye 回复:
二月 9th, 2010 at 11:17 上午
@lypflash, 当然可以。做个 NTP 是保持系统时间准确最方便的方式。但这篇文章里面，我们主要在解决硬件时间不能同步的问题。同时我们在设法找到问题出现的原因。
[回复]