From Bugzilla Helper:
User-Agent: Mozilla/4.75 [ja] (WinNT; U)
Description of problem:
By running for a long time, the difference of the time according to "hwclock" and "date" gets
larger and larger.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. boot IA-64 Linux (RH7.1, kernel is 2.4.3-12smp)
2. Don't touch it for a long time. ex. 1 week or so.
3. hwclock ; date
Actual Results: The result of "hwclock" is similar to the one of "date".
Expected Results: The difference might be 10 minutes or more large.
After 1 month heat run, we are surprise the difference was about 1 hour !
This may be caused by the interval of kernel internal clock.
To avoid this,
1. fix kernel to have suitable interval of kernel clock.
2. fix /etc/crontab to adjust kernel clock by using "hwclock" command.
3. Use ntpd
Actually this bug is very serious because IA-64 Linux is using on enterprise and huge
mathematical calculation. This significantly affects the performance test and any
Is this with the e100 or the qla2x00 driver loaded ?
Yes tye machine has e100.
We have 2 systems, Intel Lion(2way) and HITACHI ColdFusion-1(8way),
both system have e100(Ver1.6.6) and DAC960(Ver 2.4.10).
And also Lion has qla1280, CF-1 has aic7xxx_mod.
However I wonder if these devices have a relation with kernel clock...
I've noticed ia64 machines losing time even without e100/qla2x00.
We confirmed that the kernel 2.4.9-6smp from redhat ftp site had this issue yet.
The kernel internal clock had a difference 0.5msec a sec, then the difference
between internal and hardware clock may be 30 or 40 sec a day.
e100 has a relation to the kernel clock in that it disables interrupts for 500
miliseconds sometimes, and that makes the kernel miss timer interrupts....
We tested the system with eepro100 instead of e100, however we have this issue yet.
I guess this is not a issue related with e100 driver.
This issue may be complex both hardware(firmware) and kernel.
Our hardware team is trying to fix this issue by customizing its firmware...
To be honest, I find it perfectly reasonable that if you want exact time, you
use ntpd .... Even normal PC's have a clockdrift, some up to 5 to 10 minutes a day.
ntpd is there for a reason ;(
Our hardware team finally makes new firmware(SAL) and success to reduce the
effects of this issue. So, this doesn't have to be fixed, but this should be yet.
However we can avoid this to make new SAL, many IA64 machines are made
by Intel and I wonder that they dicide to make new SAL to solve this.
I agree you, ntp is a best solution against this, but it remains some problems
if I use ia64 machine as stand-alone(without any ntp servers)...
BTW, one of reasons of this issue may be /etc/rc.d/init.d/halt script in
initscripts package, the line below:
runcmd $"Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
The hareware clock is getting later and later if we don't have any ntp server
and do shutdown every day, because the hw clock is set by *broken* system clock
at every shutdown time. So I recomend to remove this line, as you know,
the system clock is very inaccurate comparing with hw clock.
7.1 IA64 is no longer supported. Closing. If this is in the supported products
too please update version and reopen