.config/cpuinfo
btw, after switching power off/on it worked again. And I don't understand why.
after rebooting it kept the same.
Attached cpuinfos from older kernels, because I forgot to save the other
one before rebooting.
Nico
--
Please send your messages pgp-signed and/or pgp-encrypted (don't encrypt mails
to mailing list!). If you don't know what pgp is visit http://www.gnupg.org.
(public pgp key: ftp.schottelius.org/pub/familiy/nico/pgp-key)
Joshua Uziel [Wed, Jul 24, 2002 at 03:27:09AM -0700]:
> * Nico Schottelius <[email protected]> [020724 02:03]:
> > This periodicly appears in my system. The Kernel seems to misdetect the
> > right cpu speed and then it's running only at 165mhz.
> > I don't really understand why this happens, there's no acpi enabled, which
> > caused this failure the last time.
>
> Is this a notebook computer? Is it that you're sometimes booting it up
> while the system is unplugged (ie. on battery)?
yes,it is, but slowing down to 500 mhz is the only available speedstep
option.
165 or similar is not supported (afaik) by the bios/processor.
Nico
--
Please send your messages pgp-signed and/or pgp-encrypted (don't encrypt mails
to mailing list!). If you don't know what pgp is visit http://www.gnupg.org.
(public pgp key: ftp.schottelius.org/pub/familiy/nico/pgp-key)
Nico Schottelius wrote:
>
> Joshua Uziel [Wed, Jul 24, 2002 at 03:27:09AM -0700]:
> > * Nico Schottelius <[email protected]> [020724 02:03]:
> > > This periodicly appears in my system. The Kernel seems to misdetect the
> > > right cpu speed and then it's running only at 165mhz.
> > > I don't really understand why this happens, there's no acpi enabled, which
> > > caused this failure the last time.
> >
> > Is this a notebook computer? Is it that you're sometimes booting it up
> > while the system is unplugged (ie. on battery)?
>
> yes,it is, but slowing down to 500 mhz is the only available speedstep
> option.
>
> 165 or similar is not supported (afaik) by the bios/processor.
>
The cpu speed is detected by comparing the TSC against the
PIT. The PIT is used to drive the clock. If it is wrong by
this much you should see time drifting like mad. If the TSC
is wrong, you should see errors in the sub 1/HZ correction
applied to get_time_of_day(). You could detect this by
looping on a get_time_of_day() call and noticing that time
slides ahead 3/HZ seconds and then back each tick. What
would be happening is that the interpolation code would be
taking the fast TSC (i.e. 500MHZ when it thought it was 165)
and be pushing time out beyond the next tick value. Each
tick this would reset and be replayed. If neither of these
is happening, the reported value is most likely what is
really going on.
--
George Anzinger [email protected]
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Real time sched: http://sourceforge.net/projects/rtsched/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
Once again I am on a 147Mhz system....
george anzinger [Wed, Jul 24, 2002 at 01:13:18PM -0700]:
> Nico Schottelius wrote:
> > Joshua Uziel [Wed, Jul 24, 2002 at 03:27:09AM -0700]:
> > > * Nico Schottelius <[email protected]> [020724 02:03]:
> > > > This periodicly appears in my system. The Kernel seems to misdetect the
> > > > right cpu speed and then it's running only at 165mhz.
> > > > I don't really understand why this happens, there's no acpi enabled, which
> > > > caused this failure the last time.
> > >
> > > Is this a notebook computer? Is it that you're sometimes booting it up
> > > while the system is unplugged (ie. on battery)?
> >
> > yes,it is, but slowing down to 500 mhz is the only available speedstep
> > option.
> >
> > 165 or similar is not supported (afaik) by the bios/processor.
> >
> The cpu speed is detected by comparing the TSC against the
> PIT.
I don't even now any of these both.
> The PIT is used to drive the clock. If it is wrong by
> this much you should see time drifting like mad.
Hey, you are right! Instead of 13 o'clock it's 5 o'clock.
What todo now ? I am staying on this downclocked system, if you
need some more informations.
> If the TSC
> is wrong, you should see errors in the sub 1/HZ correction
> applied to get_time_of_day().
> You could detect this by
> looping on a get_time_of_day() call and noticing that time
> slides ahead 3/HZ seconds and then back each tick. What
> would be happening is that the interpolation code would be
> taking the fast TSC (i.e. 500MHZ when it thought it was 165)
> and be pushing time out beyond the next tick value. Each
> tick this would reset and be replayed. If neither of these
> is happening, the reported value is most likely what is
> really going on.
Nice explanation. I think I understood 85 % of it :)
Nico
--
Changing mail address: please forget all known @pcsystems.de addresses.
Please send your messages pgp-signed and/or pgp-encrypted (don't encrypt mails
to mailing list!). If you don't know what pgp is visit http://www.gnupg.org.
(public pgp key: ftp.schottelius.org/pub/familiy/nico/pgp-key)