Hi, * 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 problem is: I got this idea that it may have to do with the CPU clock changes done by the "power manager" after I had changed the kernel (which solved the problem for me), so -I'm sorry- I haven't tested whether the problem would have been also solved by setting the "power management" to a fixed valued instead of "dynamic". But, of course, you could give it a try if you haven't, yet. I've also found another discussion thread in a Gentoo forum about this problem: http://forums.gentoo.org/viewtopic.php?t=191716 Perhaps there are some hints that may help you. HTH, Steffen

The messages about lost ticks and interrupt hogging as well as erratic clock operation have been common occurence on Compaq Presario 3000-series and HP Pavillion 5000-series laptops with the nVidia chipset and AMD64. A lot has been written about them in boards specific to these laptops. I experienced all of the above on my Compaq Presario 3240 AMD64-based laptop. I was under the impression that kernels newer than 2.6.8 had fixed the problem (at least as far as my Presario 3240 laptop was concerned). It seems the problem has returned or it never really went away. In a followup to my recent posting "MANY-MANY PROBLEMS AFTER UPGRADING TO 10.0," I remarked that it seems lost-ticks messages (as well as messages regarding DMA and IRQ errors) go away if I boot with the 'acpi_skip_timer_override' kernel directive (without the quotes). Since I simultaneously upgraded the nForce chipset drivers in an attempt to fix concurrent on-board ethernet lockup problems, I am not sure if the updated nForce drivers or the 'acpi_skip-timer_override' kernel directive was what fixed the problem of lost ticks. I am not sure if lost ticks and erratic clock operation are related (I guess they probably are); in the past I experienced both but I also experienced lost ticks with decent clock accuracy. I think one thing you should watch out for is the '/etc/adjtime' file, where corrections to the hardware clock are stored. (For further details do a 'man adjtimex' and 'man hwclock'; Linux utilizes two clocks, the CMOS hardware clock and its own running clock.) This can throw you into a loop! Even if we assume that lost ticks impact the accuracy of the clock, if you eliminate this cause, the '/etc/adjtime' file will contain wrong corrections from before, so your clock will still be off! I would think that, maybe, first try to fix the lost ticks problem and then start with a clean '/etc/adjtime' file. I am not sure what the numeric entries in the '/etc/adjtime' file stand for. CF Jonathan Brooks wrote:

Hi,

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]

Is there some parameter I should be passing to the kernel to stop it correcting for lost ticks? Also, is there some way to track whether the clock is really gaining seconds - other than by just leaving it, and watching the clock? :)

Best wishes,

Jon.