Bug 5740

Summary:	tsc ocassionally counts back with dual core
Product:	Timers	Reporter:	Adrian Yee (brewt-bugzilla.kernel.org)
Component:	Interval Timers	Assignee:	john stultz (john.stultz)
Status:	REJECTED UNREPRODUCIBLE
Severity:	normal	CC:	john.stultz
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.15-rc5	Subsystem:
Regression:	---	Bisected commit-id:
Attachments:	dmesg (smp, apic, acpi, pmtmr) config for 2.6.15-rc5

Description Adrian Yee 2005-12-14 00:47:00 UTC

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.

Comment 1 Adrian Yee 2005-12-14 00:53:20 UTC

Created attachment 6818 [details]
dmesg (smp, apic, acpi, pmtmr)

Comment 2 Adrian Yee 2005-12-14 00:56:44 UTC

Created attachment 6819 [details]
config for 2.6.15-rc5

Comment 3 Adrian Yee 2005-12-14 12:22:21 UTC

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.

Comment 4 john stultz 2005-12-15 15:40:21 UTC

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.

Comment 5 john stultz 2006-02-03 16:38:07 UTC

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?

Comment 6 Adrian Yee 2006-02-04 03:26:36 UTC

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?).

Comment 7 john stultz 2006-08-22 16:40:11 UTC

This bug is a bit stale.
Adrian: Does the sluggishness you described in this bug still exist w/ 2.6.18-rc4?

Comment 8 Adrian Yee 2006-08-27 20:19:40 UTC

No, my comments from comment 6 still stand.

Comment 9 john stultz 2006-08-28 17:46:13 UTC

Thanks for the feedback, if its not being seen, then I'm going to go ahead and
close this.