Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 Nov 1995 10:00:29 +0200 (SAT)
From:      John Hay <jhay@mikom.csir.co.za>
To:        wollman@lcs.mit.edu (Garrett A. Wollman)
Cc:        current@FreeBSD.org
Subject:   Re: Time problems
Message-ID:  <199511010800.KAA18894@zibbi.mikom.csir.co.za>
In-Reply-To: <9510311747.AA29686@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Oct 31, 95 12:47:55 pm

next in thread | previous in thread | raw e-mail | index | archive | help
OK, I changed the values in calibrate_cyclecounter() like suggested and now
my time stay much closer to reality.

My CPU even probe as a 90MHz processor!
> CPU: 90-MHz Pentium 735\\90 (Pentium-class CPU)
>   Origin = "GenuineIntel"  Id = 0x525  Stepping=5
>   Features=0x3bf<FPU,VME,PSE,MCE,CX8,APIC>

Can we get some kernel config option to do this or will I have to change
clock.c after every ctm? Or will this get to be the default?

John
-- 
John Hay -- John.Hay@csir.co.za

> In talking to David Greenman about this problem, we found that one of
> his machines which exhibits this problem suffers from (1).  Other
> people have suggested (2) for their motherboards.  (David's
> motherboard took about 12 seconds to perform a ten-second delay.)
> 
> Here's one thing which you might try:
> 
> In this function (in i386/isa/clock.c):
> 
> ------------------------------------
> calibrate_cyclecounter(void)
> {
>         /*
>          * Don't need volatile; should always use unsigned if 2's
>          * complement arithmetic is desired.
>          */
>         unsigned long long count;
> 
>         __asm __volatile(".byte 0x0f, 0x30" : : "A"(0LL), "c" (0x10));
>         DELAY(1000000);
>         __asm __volatile(".byte 0xf,0x31" : "=A" (count));
>         /*
>          * XX lose if the clock rate is not nearly a multiple of 1000000.
>          */
>         pentium_mhz = (count + 500000) / 1000000;
> }
> ------------------------------------
> 
> Change the occurrences of `1000000' to `10000' and `500000' to
> `5000'.  This will reduce the calibration time, which makes it more
> likely that the error in your clock will be small enough to get
> rounded off.  If that doesn't work, then just #ifdef out the body of
> the function, which will cause the 8254-alike to act as the reference
> for timekeeping.
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511010800.KAA18894>