medent
asked on
hwclock "clock tick" error
Hi I am seeing the following error when I run hwclock commands on RHEL4.5
[root@test192 ~]# /sbin/hwclock --show
select() to /dev/rtc to wait for clock tick timed out
[root@test192 ~]#
This issue seems to be specific to the hardware (IBMx3850 - 4 CPU), as I am not seeing it on any other IBM server I have tested. I see similar complaints on forums with the suggestion to use the --directisa parameter with the hwclock call - That does eliminate the error - but looking at the man page - I am not fixing anything - just bypassing the /dev/rtc which appears to be broken...?
[root@test192 ~]# /sbin/hwclock --show
select() to /dev/rtc to wait for clock tick timed out
[root@test192 ~]#
This issue seems to be specific to the hardware (IBMx3850 - 4 CPU), as I am not seeing it on any other IBM server I have tested. I see similar complaints on forums with the suggestion to use the --directisa parameter with the hwclock call - That does eliminate the error - but looking at the man page - I am not fixing anything - just bypassing the /dev/rtc which appears to be broken...?
paradoxengine
That's it, it's not a fix.
Hi,
This is a bug in kernel. On some chpsets kernel simply can not handle rtc interrupts. In fact it is a combination of Clock dirvers in Southbirge chipset and kernel. So you will try later releases for the solution of thi problem. Because from time to tie this is fixed on one chipset while still others are not.
You can diagnose te problem like that.
# cat /proc/interrupts
look for rtc interrupt:
CPU0
(snip)
8: 2 IO-APIC-edge rtc
(snip)
while on a faulty system you'll see:
8: 0 IO-APIC-edge rtc
(there will be 4 sets of 0's for 4 CPU's).
I'll suggest you to grab a live CentoS 5.0 CD (I am not aware of a Live RedHAT ES CD, CentOS is compiled from RedHAT source RPMs and I'd expect if it runs then it will run on RedHAT too) and boot from the cd and test if this is fixed for your platform. If it is fixed just upgrade to RedHAT 5.0.
Anyway till you find a permanent solution I'll suggest you to use NTP otherwise your time will go way beyonfd real time and you will never be sore about your timestaps etc. Since ntp service in RedHAT also uses ntpdate before starting the service it will set the time correctly.
Cheers,
K.
This is a bug in kernel. On some chpsets kernel simply can not handle rtc interrupts. In fact it is a combination of Clock dirvers in Southbirge chipset and kernel. So you will try later releases for the solution of thi problem. Because from time to tie this is fixed on one chipset while still others are not.
You can diagnose te problem like that.
# cat /proc/interrupts
look for rtc interrupt:
CPU0
(snip)
8: 2 IO-APIC-edge rtc
(snip)
while on a faulty system you'll see:
8: 0 IO-APIC-edge rtc
(there will be 4 sets of 0's for 4 CPU's).
I'll suggest you to grab a live CentoS 5.0 CD (I am not aware of a Live RedHAT ES CD, CentOS is compiled from RedHAT source RPMs and I'd expect if it runs then it will run on RedHAT too) and boot from the cd and test if this is fixed for your platform. If it is fixed just upgrade to RedHAT 5.0.
Anyway till you find a permanent solution I'll suggest you to use NTP otherwise your time will go way beyonfd real time and you will never be sore about your timestaps etc. Since ntp service in RedHAT also uses ntpdate before starting the service it will set the time correctly.
Cheers,
K.
It happens on my debian box too. My workaround is :
I renamed /sbin/hwclock to /sbin/hwclock1
added a simple script hwclock in /sbin with
hwclock --directisa
This is not a permanent solution, but works.
I renamed /sbin/hwclock to /sbin/hwclock1
added a simple script hwclock in /sbin with
hwclock --directisa
This is not a permanent solution, but works.
ASKER
Sounds like that may do the trick work.... with this workaround does your server grab the hardware clock time on bootup properly? ps- I just logged a support call into IBM now to see if they can help,
If you are talking about my solution, yes it does.
it is some variation of using --directisa switch. Furthermore the content of the script must have been:
hwclock1 --directisa
Otherwise the script would call itself indefinitely. This is a "dirty" solution in that it just does not allow passing other parameters to hwclock anymore. This will cause hwclocak will not be able to set the system clock to the RTC anyway. Because it will not pass --set --date xxx to the hwclock. the correct way is to add directisa to the CLOCKOPTIONS varaible in the /etc/rc.d/rc.sysconfig.
The difference between using or not using the --directisa switch is without switch the rtc driver built into the kernel reads the hwclock. But if you include the --directisa switch rtc driver will by bypassed and the clock will be accessed as if this system is an ancient standard PC with ISA bus.
Since --directisa must be included eveytime you call the hwclock (it is generally called once during initialization and once more during shutdown). RedHAT, alongwith other distros allow the settings via a special variable. For redHAT you should include your settings in /etc/rc.d/rc.sysinit called CLOCKFLAGS.
Without inclusion of the setting rte driver will not be able to write to sysclok for obvious reasons. This is the only proper solution which does not disrupt with parameter passing to the hwclock
hwclock1 --directisa
Otherwise the script would call itself indefinitely. This is a "dirty" solution in that it just does not allow passing other parameters to hwclock anymore. This will cause hwclocak will not be able to set the system clock to the RTC anyway. Because it will not pass --set --date xxx to the hwclock. the correct way is to add directisa to the CLOCKOPTIONS varaible in the /etc/rc.d/rc.sysconfig.
The difference between using or not using the --directisa switch is without switch the rtc driver built into the kernel reads the hwclock. But if you include the --directisa switch rtc driver will by bypassed and the clock will be accessed as if this system is an ancient standard PC with ISA bus.
Since --directisa must be included eveytime you call the hwclock (it is generally called once during initialization and once more during shutdown). RedHAT, alongwith other distros allow the settings via a special variable. For redHAT you should include your settings in /etc/rc.d/rc.sysinit called CLOCKFLAGS.
Without inclusion of the setting rte driver will not be able to write to sysclok for obvious reasons. This is the only proper solution which does not disrupt with parameter passing to the hwclock
ASKER
I do not have a etc/rc.d/rc.sysconfig on my CENTOS 4.5 server. I have an rc.sysinit and I changed the CLOCKFLAG statements accordingly. Where can I find CLOCKOPTIONS on RH?
Sorry my bad. The file is named /etc/rc.sysinit. It is actually a link to /etc/rc.d/rc.sysinit. So if you edit the former one you'd really edit /etc/rc.d/rc.sysinit. So they are both the same file.
Re: CLOCKOPTIONS it is my bad again :) Sorry for the inconvenience. It seems that I was a bit distracted when I was writing the first paragraph. I mean it is sufficent that you edit /etc/rc.d/rc.sysinit file and modify CLOCKFLAGS accordingly.
Oops soory for my mistakes once more again.
Re: CLOCKOPTIONS it is my bad again :) Sorry for the inconvenience. It seems that I was a bit distracted when I was writing the first paragraph. I mean it is sufficent that you edit /etc/rc.d/rc.sysinit file and modify CLOCKFLAGS accordingly.
Oops soory for my mistakes once more again.
ASKER
No problem, I made changes to all of the instances of CLOCKFLAGS in rc.sysinit and rebooted the server... and I do not see the clock errors any more during bootup (thank you), but I do still see the errors if I run the hwclock command (hwclock --show). I must be getting close!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Makes sense- Thanks. Ps- I tried CentoOS 5 to see if the latest kernel would help and no such luck..but I am very glad to have a workaround!
Yr welcome. I've upgraded my test system to CentOS 5 and a newer to CentOS 5. It is a good idea to keep your system updated because RedHAT is ending the support so quickly without you knowing your system will be out of support.
BTW. There's a new BIOS fix available for your system. The good thing is this fix works under Linux. May be it might help. Because it seems that they've changed something related to PCI and ACPI most problems are occuring because of them. I'll suggest you to try the fix if you did not already:
http://www-304.ibm.com/jct01004c/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-66901&brandind=5000008
BTW. There's a new BIOS fix available for your system. The good thing is this fix works under Linux. May be it might help. Because it seems that they've changed something related to PCI and ACPI most problems are occuring because of them. I'll suggest you to try the fix if you did not already:
http://www-304.ibm.com/jct01004c/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-66901&brandind=5000008