Hide Forgot
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): How reproducible: Always 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 ! Additional info: 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 test programs.
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.
FYI: 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