Distribution: Slackware 10.2 Hardware Environment: AMD Athlon 64 X2 3800+ EVGA 133-K8-NF41-AX nForce 4 SLI Motherboard Software Environment: i386 kernel with SMP, APIC, ACPI enabled, AMD Cool & Quiet/cpufreq disabled Problem Description: I've been having tsc issues where it counts back occasionally causing things like ping to break with errors: "Warning: time of day goes back (-1451987us), taking countermeasures." It seems related to bug 5105, but that bug seems to be closed (and more x86_64 related). I also get other timing issues like single clicks registering as double clicks, and at times double clicks that don't register. In addition, if I stress the system with something like prime95, then after about 2 minutes the system clock will speed up where the clock advances by minutes every second - a `watch -n1 cat /proc/interrupts` will result in it refreshing more than once a second and interrupts going crazy. As suggested in bug 5105, I switched to use the pmtimer (my system doesn't seem to support hpet) and it has fixed the ping and clock issue, but my system doesn't 'feel' right (doesn't seem to perform like an smp machine should). I've also tried the tsc synchronisation test from http://bugzilla.kernel.org/show_bug.cgi?id=5105#c49 and it detects the backwards count. dmesg and .config to follow.
Created attachment 6818 [details] dmesg (smp, apic, acpi, pmtmr)
Created attachment 6819 [details] config for 2.6.15-rc5
I forgot to add that I was having similar issues with an Abit AV8 (VIA K8T800 Pro chipset) motherboard with the Athlon 64 X2 3800+ as well, but using a different kernel configuration.
Assuming CONFIG_X86_PM_TIMER is enabled, the ACPI PM timer should be used and timekeeping problems related to unsycned TSCs should go away. The main concern in this bug is the sluggishness reported when the ACPI PM timer is used. I'm not sure what the cause of this would be, and the bug filer has not been able to recreate the issue in a reliable way. I'm going to leave this open in hopes someone else might recognize a similar problem or further info appears.
Adrian: Are you still experiencing sluggishness w/ 2.6.16-rc2 usign the pmtmr? Is there any way you could better describe the sluggishness? Maybe could you run "time make -j3 bzImage" three times and submit the results here?
I'm not sure if I've gotten more used to it, or what, but I haven't really felt the system being sluggish since then. The reason why I filed the bug was mainly because of the TSC issue. Even though I'm using the pmtmr, isn't the TSC counting backwards still an issue (I'm not completely sure how things work, but isn't it possible that things still use the TSC as a timing source?).
This bug is a bit stale. Adrian: Does the sluggishness you described in this bug still exist w/ 2.6.18-rc4?
No, my comments from comment 6 still stand.
Thanks for the feedback, if its not being seen, then I'm going to go ahead and close this.