* 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
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 below handles that case by disca
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.
>
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.
On investigation, the tsc_khz variable was significantly
10 matches
Mail list logo
