> -----Original Message-----
> From: Marc
> Sent: Sunday, October 02, 2005 11:46
>
> Some additions to the previous mail: I was able to isolate
> the problem to the
> introduction of a user specificable value of HZ (in
> include/asm-ppc/parm.h).
> I used a value of 250 while the former default was 1000.
> Setting it back to
> 1000 makes the clock tick right again.
>
> Is the CONFIG_HZ known to be broken on PPC ?
>
CONFIG_HZ is not broken, but the whole clock configuration is.
(I poseded something about it for 8260 earlier this summer)
Basic problem is that CLOCK_TICK_RATE which is used for setting up the
variables used for advancing the clock, is hardcoded to a value that
only makes sence for an i386. (it is default set at 1193180Hz which
happens to be the timer clock for timer1 on an i386 machine)
Another problem here is that that value apparently hve to be #define'd
which means you cannot insert the decrementer frequency from the
boot-loader either.
Hi,
given that this option causes problems on non i386 systems, may I propose to
mark CONFIG_HZ as broken on these architectures and/or use a default value of
1000 ? I guess this issue can't be fixed in a sane way until 2.6.14 is out.
Marc
Le Montag 03 Oktober 2005 16:18, Rune Torgersen a ?crit :
> > -----Original Message-----
> > From: Marc
> > Sent: Sunday, October 02, 2005 11:46
> >
> > Some additions to the previous mail: I was able to isolate
> > the problem to the
> > introduction of a user specificable value of HZ (in
> > include/asm-ppc/parm.h).
> > I used a value of 250 while the former default was 1000.
> > Setting it back to
> > 1000 makes the clock tick right again.
> >
> > Is the CONFIG_HZ known to be broken on PPC ?
>
> CONFIG_HZ is not broken, but the whole clock configuration is.
> (I poseded something about it for 8260 earlier this summer)
>
> Basic problem is that CLOCK_TICK_RATE which is used for setting up the
> variables used for advancing the clock, is hardcoded to a value that
> only makes sence for an i386. (it is default set at 1193180Hz which
> happens to be the timer clock for timer1 on an i386 machine)
>
> Another problem here is that that value apparently hve to be #define'd
> which means you cannot insert the decrementer frequency from the
> boot-loader either.
Rune Torgersen writes:
> CONFIG_HZ is not broken, but the whole clock configuration is.
> (I poseded something about it for 8260 earlier this summer)
>
> Basic problem is that CLOCK_TICK_RATE which is used for setting up the
> variables used for advancing the clock, is hardcoded to a value that
> only makes sence for an i386. (it is default set at 1193180Hz which
> happens to be the timer clock for timer1 on an i386 machine)
I do not believe CLOCK_TICK_RATE affects timekeeping at all on ppc or
ppc64 machines, but I could be wrong. Can you show us where and how
CLOCK_TICK_RATE affects things?
Paul.
On Tue, 2005-10-04 at 08:14 +0200, Marc wrote:
> Hi,
>
> given that this option causes problems on non i386 systems, may I propose to
> mark CONFIG_HZ as broken on these architectures and/or use a default value of
> 1000 ? I guess this issue can't be fixed in a sane way until 2.6.14 is out.
No, it should work fine, there is something else broken on this G3
Ben.
On Tue, 2005-10-04 at 08:14 +0200, Marc wrote:
> Hi,
>
> given that this option causes problems on non i386 systems, may I propose to
> mark CONFIG_HZ as broken on these architectures and/or use a default value of
> 1000 ? I guess this issue can't be fixed in a sane way until 2.6.14 is out.
The problem is indeed in via_calibrate_decr(). This routine works on
HZ/100 so it will not do any good with HZ not beeing a multiple of 100.
Can you test this patch ?
Index: linux-work/arch/ppc/platforms/pmac_time.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/pmac_time.c 2005-09-22 14:06:18.000000000 +1000
+++ linux-work/arch/ppc/platforms/pmac_time.c 2005-10-05 08:14:17.000000000 +1000
@@ -195,7 +195,7 @@
;
dend = get_dec();
- tb_ticks_per_jiffy = (dstart - dend) / (6 * (HZ/100));
+ tb_ticks_per_jiffy = (dstart - dend) / ((6 * HZ)/100);
tb_to_us = mulhwu_scale_factor(dstart - dend, 60000);
printk(KERN_INFO "via_calibrate_decr: ticks per jiffy = %u (%u ticks)\n",
Hi Ben,
Le Mittwoch 05 Oktober 2005 00:14, Benjamin Herrenschmidt a écrit :
> The problem is indeed in via_calibrate_decr(). This routine works on
> HZ/100 so it will not do any good with HZ not beeing a multiple of 100.
>
> Can you test this patch ?
I can confirm that this patch solves the timer skew on my mac.
Thanks!
>
> Index: linux-work/arch/ppc/platforms/pmac_time.c
> ===================================================================
> --- linux-work.orig/arch/ppc/platforms/pmac_time.c 2005-09-22
> 14:06:18.000000000 +1000 +++
> linux-work/arch/ppc/platforms/pmac_time.c 2005-10-05 08:14:17.000000000
> +1000 @@ -195,7 +195,7 @@
> ;
> dend = get_dec();
>
> - tb_ticks_per_jiffy = (dstart - dend) / (6 * (HZ/100));
> + tb_ticks_per_jiffy = (dstart - dend) / ((6 * HZ)/100);
> tb_to_us = mulhwu_scale_factor(dstart - dend, 60000);
>
> printk(KERN_INFO "via_calibrate_decr: ticks per jiffy = %u (%u ticks)\n",
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/