The following reply was made to PR port-i386/36839; it has been noted by GNATS.

From: Frank Kardel <kardel@netbsd.org>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@netbsd.org, port-i386-maintainer@netbsd.org,
	gnats-admin@netbsd.org
Subject: Re: port-i386/36839: x86/x86/tsc.c should be switched to using MIkern_cctr.c
Date: Sun, 26 Aug 2007 16:48:06 +0200

 Izumi Tsutsui wrote:
 > kardel@NetBSD.org wrote:
 >
 >   
 >>  The reason for not having switched yet is, that I saw backward time 
 >>  steps when
 >>  running the regress/sys/kern/time test.
 >>     
 >
 > Doesn't it happen with -current (not split) tsc.c?
 >   
 Not so much (around -5us...0), this is because calibration happens at HZ
 and not at 1Hz as in the patch.
 > i.e. is the problem caused by this patch?
 >   
 Not really, it is caused (I think) by different interrupt latencies 
 (clock/IPI) so
 the the calibration factors differ each time and negative steps can be seen
 when CPUs are switched. Unless we would know that all TSCs run with
 the same frequency and (preferrably) the same value I currently see no
 way to completely resolve this uncertainty without more coordination.
 We could, of course attempt to verify assumptions at startup and select
 appropriate reading/calibration algorithms.
 There are still cases where CPU implementations might stab us in the back.
 
 TSC is nice, but there where quite a few errata around that especially 
 in the
 speedstep/powermanagement/MP area :-(. So currently for MP systems global
 counters are safer to use (FreeBSD also avoids CC in MP scenarios).
 
 Given that the current implementation with HZ calibration also has some 
 hickups
 and TSC is normally disabled in MP systems I could commit that code for 
 the sake
 of MI-ification.
 
 The MI code should be improved to run different strategies depending on the
 characteristics of the MP TSC implementation.
 
 The reason why the backwards running time didn't show up with TSC and
 kern_microtime.c was that the clock was basically "halted" by returning
 the old value plus 1 usec (needed locking). We could create that behaviour
 at CC level if needed at the expense of a lock and a global
 last_CC_val variable. Doing that right (including wrap) needs a bit of
 thought though.
 > There is also a PR kern/14058 which says
 > "time-of-day goes backward" even on 3.1_RC2.
 > (when timecounter(9) is not integrated yet?)
 >   
 Yes, but the causes for that where completely different.
 
 Frank