* Dave Johnson <[EMAIL PROTECTED]> wrote:
> The previous patch wasn't correctly handling the 'count' variable. If
> a CPU gave bad results on the 1st or 2nd run but good results on the
> 3rd, it wouldn't do the correct thing. No idea if any such CPU
> exists, but the patch below handles that
On Tue, 2007-10-16 at 10:50 -0400, Dave Johnson wrote:
>
> range of tsc_khz # of boots % of boots
> - -- --
> < 1999750 0 0.000%
> 1999750 - 1999800 21 3.048%
> 1999800 - 1999850 166 24.128%
> 1999850 - 100
Hiroshi Shimamoto writes:
> Dave Johnson wrote:
> > mach_prepare_counter();
>
> It's a really rare case, but if SMI interrupt takes CPU here, just after
> prepare and before rdtscll, it makes delta64 shorter than expected one.
> Is it possible? And how about moving rdtscll before mach_
Dave Johnson wrote:
> From: Dave Johnson <[EMAIL PROTECTED]>
>
> The previous patch wasn't correctly handling the 'count' variable. If
> a CPU gave bad results on the 1st or 2nd run but good results on the
> 3rd, it wouldn't do the correct thing. No idea if any such CPU
> exists, but the patch b
Daniel Walker writes:
> Can you tell us what type of machine this was? I've seen complaints
> where the SMI's can cause some other funny stuff with calibration , be
> no one can every reproduce anything..
Xeon LV (Sossaman) based custom board. BIOS is GenSW.
--
Dave Johnson
Starent Networks
-
T
On Tue, 2007-10-16 at 10:50 -0400, Dave Johnson wrote:
>
> range of tsc_khz # of boots % of boots
> - -- --
> < 1999750 0 0.000%
> 1999750 - 1999800 21 3.048%
> 1999800 - 1999850 166 24.128%
> 1999850 - 100
* Dave Johnson <[EMAIL PROTECTED]> wrote:
> I ran into this problem on a system that was unable to obtain NTP sync
> because the clock was running very slow (over 1ppm slow). ntpd had
> declared all of its peers 'reject' with 'peer_dist' reason.
>
> On investigation, the tsc_khz variable w
On 10/16/2007 10:50 AM, Dave Johnson wrote:
> From: Dave Johnson <[EMAIL PROTECTED]>
>
> I ran into this problem on a system that was unable to obtain NTP sync
> because the clock was running very slow (over 1ppm slow). ntpd had
> declared all of its peers 'reject' with 'peer_dist' reason.
>
8 matches
Mail list logo
