On Thu, 9 Oct 2003, Ethan Benson wrote:
On Fri, Oct 10, 2003 at 01:12:54AM -0400, Bill Fink wrote:
quoted
This discussion prompted me to finally ask about another clock related
problem I see on the 867 MHz G4 systems at work. The clocks on
these systems continuously run 0.2% slow (about 3 minutes per day).
Apparently this is more than ntp can adjust for (using scaling), as I
get many of these error messages in the log:
is it a quicksilver G4? i maintain one of those and its time goes off
much faster then that (3 minutes within a couple hours).
Yes I believe it's a quicksilver G4.
clifford% cat /proc/cpuinfo
cpu : 7450, altivec supported
clock : 866MHz
revision : 2.1 (pvr 8000 0201)
bogomips : 865.07
machine : PowerMac3,5
motherboard : PowerMac3,5 MacRISC2 MacRISC Power Macintosh
detected as : 69 (PowerMac G4 Silver)
pmac flags : 00000000
L2 cache : 256K unified
memory : 640MB
pmac-generation : NewWorld
quoted hunk
the fix is rather simple:
--- linux.old/arch/ppc/platforms/pmac_time.c.orig Sat Nov 30 02:33:49 2002
+++ linux/arch/ppc/platforms/pmac_time.c Sat Nov 30 02:33:22 2002
* calibration. That's better since the VIA itself seems
* to be slightly off. --BenH
*/
+#if 0
if (!machine_is_compatible("MacRISC2"))
+#endif
if (via_calibrate_decr())
return;
Thanks for the suggested fix. I'll give it a try when I get a chance.
in the case of the quicksilver VIA is FAR better then whatever it uses
instead.
Assuming the fix works, is there a simple way to test for the
quickserver G4 model rather than doing the "#if 0", since I like
to run a common kernel across a variety of different processor
models.
-Bill
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Sat, Oct 11, 2003 at 12:45:41AM -0400, Bill Fink wrote:
On Thu, 9 Oct 2003, Ethan Benson wrote:
quoted
On Fri, Oct 10, 2003 at 01:12:54AM -0400, Bill Fink wrote:
quoted
This discussion prompted me to finally ask about another clock
related problem I see on the 867 MHz G4 systems at work. The
clocks on these systems continuously run 0.2% slow (about 3
minutes per day). Apparently this is more than ntp can adjust for
(using scaling), as I get many of these error messages in the log:
is it a quicksilver G4? i maintain one of those and its time goes
off much faster then that (3 minutes within a couple hours).
Yes I believe it's a quicksilver G4.
clifford% cat /proc/cpuinfo
cpu : 7450, altivec supported
clock : 866MHz
revision : 2.1 (pvr 8000 0201)
bogomips : 865.07
machine : PowerMac3,5
motherboard : PowerMac3,5 MacRISC2 MacRISC Power Macintosh
detected as : 69 (PowerMac G4 Silver)
pmac flags : 00000000
L2 cache : 256K unified
memory : 640MB
pmac-generation : NewWorld
thats a quicksilver alright.
quoted
the fix is rather simple:
--- linux.old/arch/ppc/platforms/pmac_time.c.orig Sat Nov 30 02:33:49 2002
+++ linux/arch/ppc/platforms/pmac_time.c Sat Nov 30 02:33:22 2002
* calibration. That's better since the VIA itself seems
* to be slightly off. --BenH
*/
+#if 0
if (!machine_is_compatible("MacRISC2"))
+#endif
if (via_calibrate_decr())
return;
Thanks for the suggested fix. I'll give it a try when I get a chance.
quoted
in the case of the quicksilver VIA is FAR better then whatever it
inuses stead.
Assuming the fix works, is there a simple way to test for the
quickserver G4 model rather than doing the "#if 0", since I like to
run a common kernel across a variety of different processor models.
i don't know, ive discussed it with benh, but he won't accept that VIA
is a better choice here.
--
Ethan Benson
http://www.alaska.net/~erbenson/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
quoted
Assuming the fix works, is there a simple way to test for the
quickserver G4 model rather than doing the "#if 0", since I like to
run a common kernel across a variety of different processor models.
i don't know, ive discussed it with benh, but he won't accept that VIA
is a better choice here.
Hrm... I do accept that it's a better choice, but I'm sure using
the KeyLargo timer is even better :) Anyway, I'll switch to VIA by
default on "PowerMac3,5" type machines for now.
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Sat, Oct 11, 2003 at 04:58:14PM +0200, Benjamin Herrenschmidt wrote:
quoted
quoted
Assuming the fix works, is there a simple way to test for the
quickserver G4 model rather than doing the "#if 0", since I like to
run a common kernel across a variety of different processor models.
i don't know, ive discussed it with benh, but he won't accept that VIA
is a better choice here.
Hrm... I do accept that it's a better choice, but I'm sure using
the KeyLargo timer is even better :) Anyway, I'll switch to VIA by
default on "PowerMac3,5" type machines for now.
How does the Keylargo timer work? Any pointer?
Also for these machines it seems that OF also returns wrong values.
Maybe there is an OF update somewhere.
Does anybody know what MacOS X (most MacOS X machines probably use
ntp) do?
Sorry, more questions than answers. It superficially looks
like a HW screw-up in one specific series of machines.
Gabriel
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
How does the Keylargo timer work? Any pointer?
Darwin code... But it's basically a 64 bits counter at
KL base +
#define kKeyLargoCounterLoOffset 0x15038
#define kKeyLargoCounterHiOffset 0x1503C
MacOS X Appelle une fonction asm "TimeSystemBusKeyLargo" qui mesure
le nombre de "ticks" KeyLargo pour 1,048,575 PowerPC decrementer/tb
units.
(copied below)
And then uses that "tick" value this way:
ticks = TimeSystemBusKeyLargo (keyLargoBaseAddress);
if (intLock) {
IOSimpleLockUnlockEnableInterrupt(intLock, is); // As you were
IOSimpleLockFree (intLock);
}
systemBusHz = 4194300;
systemBusHz *= 18432000;
systemBusHz /= ticks;
;
; TimeSystemBusKeyLargo(inKeyLargoBaseAddress)
;
; TimeSystemBusKeyLargo - Times how long it takes the PowerPC decrementer to count down
; 1,048,575 ticks.
;
; returns, in r3, the number of KeyLargo timer ticks per 1,048,575 PowerPC decrementer ticks.
;
; trashes r3 - r10
;
; NOTE - interrupts should be disabled when calling this code
;
ENTRY(TimeSystemBusKeyLargo, TAG_NO_FRAME_USED)
lis r4, 0x000F
ori r4, r4, 0xFFFF ; Load decrementer tick count (1,048,575)
lis r6, kKeyLargoCounterLoOffset >> 16
ori r6, r6, kKeyLargoCounterLoOffset & 0xFFFF ; Counter lo offset
lis r7, kKeyLargoCounterHiOffset >> 16
ori r7, r7, kKeyLargoCounterHiOffset & 0xFFFF ; Counter hi offset
lwbrx r8, r6, r3 ; Read low 32-bits of counter
lwbrx r9, r7, r3 ; Read hi 32-bits of counter
; Set up decrementer and wait for it to tick down
mtdec r4 ; Set decrementer to 1,048,575
isync
NewDecrementerLoop:
mfdec r5 ; Read current decrementer value
cmpwi r5, 0 ; Check if decrementer is zero
bgt+ NewDecrementerLoop ; If not yet to zero, keep looping
sync
; Read current value of KeyLargo to get delta time
lwbrx r4, r6, r3 ; Load low 32-bits of timer (latches all 64 bits)
lwbrx r5, r7, r3 ; Load high 32-bits of timer (clear latch)
; Calculate difference
subf r3, r8, r4 ; Subtract low bits (ignore wrap)
blr ; Return
(END)
Also for these machines it seems that OF also returns wrong values.
Maybe there is an OF update somewhere.
Does anybody know what MacOS X (most MacOS X machines probably use
ntp) do?
Sorry, more questions than answers. It superficially looks
like a HW screw-up in one specific series of machines.
Gabriel
--
Benjamin Herrenschmidt [off-list ref]
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/