RE: [suse-amd64] many lost ticks
* On Thu, Oct 27, 2005 at 01:04 PM (+0100), Jonathan Brooks wrote:
I have an AMD Athlon64 X2 machine running SuSE 10 (x86_64) on an Nvidia Nforce4 Ultra motherboard, and have noticed that the system clock has become unstable (it runs too fast). Not sure when it occurred, but I have been getting a lot of error messages like this in dmesg:
warning: many lost ticks. Your time source seems to be instable or some driver is hogging interupts rip acpi_processor_idle+0x12f/0x37f [processor]
I had a very similar (or the same?) problem on a "Tyan Thunder K8SE 2892G3NR" dual Opteron machine running SuSE Linux 9.3: The system time ran much too fast (minutes were almost running like seconds), the screen saver started only seconds after not moving the mouse or pressing a key and the log file was full of these messages ("many lost ticks").
My notice was that it especially happend when the CPU usage grew, so I suppose it was related to the "powernow" feature of the CPU, because at least on Opteron systems SuSE's "power management" changes the CPU clock based on the load.
After I upgraded to the most recent vanilla kernel the problem was gone.
The powernow-k8 driver in SL9.3 caused clock instability on SMP machines that did not support HPET timers; SL10.0 and the mainstream kernel support PMTimer for those machines. That's most likely what you were seeing. The single processor, dual-core problem is believed to be something different and is under investigation at AMD. We will make a statement as soon as we have definite information. -Mark Langsdorf AMD, Inc.
Langsdorf, Mark wrote:
* On Thu, Oct 27, 2005 at 01:04 PM (+0100), Jonathan Brooks wrote:
I have an AMD Athlon64 X2 machine running SuSE 10 (x86_64) on an Nvidia Nforce4 Ultra motherboard, and have noticed that the system clock has become unstable (it runs too fast). Not sure when it occurred, but I have been getting a lot of error messages like this in dmesg:
warning: many lost ticks. Your time source seems to be instable or some driver is hogging interupts rip acpi_processor_idle+0x12f/0x37f [processor] I had a very similar (or the same?) problem on a "Tyan Thunder K8SE 2892G3NR" dual Opteron machine running SuSE Linux 9.3: The system time ran much too fast (minutes were almost running like seconds), the screen saver started only seconds after not moving the mouse or pressing a key and the log file was full of these messages ("many lost ticks").
My notice was that it especially happend when the CPU usage grew, so I suppose it was related to the "powernow" feature of the CPU, because at least on Opteron systems SuSE's "power management" changes the CPU clock based on the load.
After I upgraded to the most recent vanilla kernel the problem was gone.
The powernow-k8 driver in SL9.3 caused clock instability on SMP machines that did not support HPET timers; SL10.0 and the mainstream kernel support PMTimer for those machines. That's most likely what you were seeing.
The single processor, dual-core problem is believed to be something different and is under investigation at AMD. We will make a statement as soon as we have definite information.
-Mark Langsdorf AMD, Inc.
Wow! Wasn't expecting to get an answer straight from the horse's mouth (so to speak) :) So can you confirm that the kernel options clock=pmtmr and notsc will not have any effect on this problem, and we should wait for a resolution from AMD? Sorry for the request for clarification, but I'm stumbling around in the dark on this matter, and don't want to waste any more time on the problem - especially if it's all fruitless. Best wishes, Jon. -- Jonathan Brooks (Ph.D.) Research Assistant. PaIN Group, Department of Human Anatomy & Genetics, University of Oxford, South Parks Road, Oxford, OX1 3QX tel: +44(0)1865-282654 fax: +44(0)1865-282656 web: http://www.fmrib.ox.ac.uk/~jon
Hi, Am Donnerstag, 27. Oktober 2005 19:17 schrieb Jonathan Brooks:
Langsdorf, Mark wrote:
* On Thu, Oct 27, 2005 at 01:04 PM (+0100), Jonathan Brooks wrote:
I have an AMD Athlon64 X2 machine running SuSE 10 (x86_64) on an Nvidia Nforce4 Ultra motherboard, and have noticed that the system clock has become unstable (it runs too fast). Not sure when it occurred, but I have been getting a lot of error messages
I've had that same problem with sl9.3 and amd64-x2. I've found that the problem comes from the irqbalance programm. It is compiled with class_policy[IRQ_TIMER] = POLICY_ROTATE; witch will divide the timer Interrupts between both cores. I've change the source to class_policy[IRQ_TIMER] = POLICY_IGNORE; and since recompiling and reinstall of irqbalance my clock is working perfect. NTP has no more problems to hold the clock stable. I dont know if irqbalance is the main problem but for me now it is working. :-) And it is working with all different type of timer (pmtimer, tsc ...) no more commandline parameters needed. With original kernel and KOTD's. Gruß Carsten P.S. Wer Fehler in Rechtschreibung oder Grammatik findet darf sie behalten. Englisch ist leider nicht meine Stärke.
On Thu, 2005-10-27 at 10:53 -0500, Langsdorf, Mark wrote:
The powernow-k8 driver in SL9.3 caused clock instability on SMP machines that did not support HPET timers; SL10.0 and the mainstream kernel support PMTimer for those machines. That's most likely what you were seeing.
Just for anybody else reading the archives, it might be worth noting that on some machines at least it is possible to enable/disable the HPET timer in the BIOS. So if you have a fast clock problem, it's worth checking the BIOS settings to see that HPET is enabled. Cheers, Dave
The single processor, dual-core problem is believed to be something different and is under investigation at AMD. We will make a statement as soon as we have definite information.
-Mark Langsdorf AMD, Inc.
* On Thu, Oct 27, 2005 at 10:53 AM (-0500), Langsdorf, Mark wrote:
The powernow-k8 driver in SL9.3 caused clock instability on SMP machines that did not support HPET timers; SL10.0 and the mainstream kernel support PMTimer for those machines. That's most likely what you were seeing.
Yes, most probably - as I am running two single-core processors (Opteron 246). Steffen
participants (5)
-
Carsten Koch-Mauthe -
Dave Howorth -
Jonathan Brooks -
Langsdorf, Mark -
Steffen Moser