All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc <marvin24@gmx.de>
To: "Rune Torgersen" <runet@innovsys.com>
Cc: linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: clock skew on B/W G3
Date: Tue, 4 Oct 2005 08:14:06 +0200	[thread overview]
Message-ID: <200510040814.07188.marvin24@gmx.de> (raw)
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B859476@ismail.innsys.innovsys.com>


Hi,

given that this option causes problems on non i386 systems, may I propose t=
o=20
mark CONFIG_HZ as broken on these architectures and/or use a default value =
of=20
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 =E9crit :
> > -----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.

WARNING: multiple messages have this Message-ID (diff)
From: Marc <marvin24@gmx.de>
To: "Rune Torgersen" <runet@innovsys.com>
Cc: linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: clock skew on B/W G3
Date: Tue, 4 Oct 2005 08:14:06 +0200	[thread overview]
Message-ID: <200510040814.07188.marvin24@gmx.de> (raw)
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B859476@ismail.innsys.innovsys.com>


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.

  reply	other threads:[~2005-10-04  6:14 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-03 14:18 clock skew on B/W G3 Rune Torgersen
2005-10-03 14:18 ` Rune Torgersen
2005-10-04  6:14 ` Marc [this message]
2005-10-04  6:14   ` Marc
2005-10-04 22:10   ` Benjamin Herrenschmidt
2005-10-04 22:10     ` Benjamin Herrenschmidt
2005-10-04 22:14   ` Benjamin Herrenschmidt
2005-10-04 22:14     ` Benjamin Herrenschmidt
2005-10-05  6:34     ` Marc
2005-10-05  6:34       ` Marc
2005-10-04 12:48 ` Paul Mackerras
2005-10-04 12:48   ` Paul Mackerras
  -- strict thread matches above, loose matches on Subject: below --
2005-10-04 19:22 Rune Torgersen
2005-10-04 19:22 ` Rune Torgersen
2005-10-04 15:15 Rune Torgersen
2005-10-04 15:15 ` Rune Torgersen
2005-10-04 19:14 ` George Anzinger
2005-10-04 19:14   ` George Anzinger
2005-10-01 12:29 marvin24
2005-10-02 16:46 ` Marc
2005-10-02 16:46   ` Marc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200510040814.07188.marvin24@gmx.de \
    --to=marvin24@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=runet@innovsys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.