Bugzilla – Bug 552112
slow clock on Amilo Pro 2030 with NO_HZ=y
Last modified: 2011-03-12 21:40:12 UTC
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090410 SUSE/1.1.18-0.1 SeaMonkey/1.1.18 reported upstream a while ago at http://bugzilla.kernel.org/show_bug.cgi?id=14280 hardware is detailed at http://www.smolts.org/show?uuid=pub_c5345625-52df-4d29-9f31-acb6df810402 only nohz=off really helped. as TSC clocksource was also marked unstable with NOHZ Reproducible: Always Steps to Reproduce: 1. boot 2.6.31 2. sntp -v -P no -r pool.ntp.org Actual Results: time drifts by 4% Expected Results: time should remain accurate as with nohz=off
I'm afraid this issue will have to be resolved upstream first.
Have you tried openSUSE 11.3? If so, does it have that problem too?
I went to using 11.4 milestones on this machine and at some point with nohz it started to not schedule any process anymore, unless I caused interrupts (i.e. by pressing keys). Luckily, nohz=off still makes it work.
Let's use http://bugzilla.kernel.org/show_bug.cgi?id=14280 for further tracking of this issue.
It turns out that the hardware/BIOS of the machine in question is not functioning as expected (specifically, the ACPI PM timer cannot cope with NO_HZ, which it should). hpet=force in the kernel command line is recommended as a permanent workaround.