From: Raffaele Sandrini <rasa@gmx.ch>
To: linux-kernel@vger.kernel.org
Subject: System clock and speedstepping
Date: Fri, 28 Nov 2003 17:09:08 +0100 [thread overview]
Message-ID: <200311261943.38002.rasa@gmx.ch> (raw)
Hi
I'm running here a dell inspirion 5150 with a P4 with Kernel 2.6.0-t9.
My problem is: If the laptop is running on bateries and the system is not idle
the system clock (i dont think the hardware clock too) runns min twice as
fast as it should (if not 4 times as fast as it should).
I first recognized it when i ran KDE (and we all know that KDE is not known
for
beeing tight on recources :) ) that the clock runs too fast when running from
bateries.
Perhapps some words about my system. Without manually changing the CPU freq
the system runs on AC const. 3 GHZ. On battries 1.6 GHZ const (i dont know if
its
really const on batteries i assume that there is a kind of hardware
stepping).
I tried many kernel options RTC and HPET. The result was the same every time:
When im running on bats in the console doing nothing the clock runs correct.
If i execute this simple programm:
main () {
while(1) {}
}
then the clock runns too fast.
I am able to step my CPU via the software interface CPUFREQ of the kernel (via
the P4 clockmod driver). After some playing around i recognized that if i set
the CPU freq to a very low value (e.g 100 MHZ) i get this msg on the console:
<msg>
Losing too many ticks!
TSC cannot be used as a timesource. (Are you running with SpeedStep?)
Falling back to a sane timesource.
</msg>
The funny thing is: After this msg the clock is running correct. I can set my
CPU freq to what i want and load my system as much i want with a corect
clock.
I don't know what "sane timesource" and "TSC" is. I also dont know where
exaclty the problem is. I solved for the moment with an init script which
checks if the laptop is running on bats and if so its stepping the system
down for a sec and up again to force the above error to come. I know that
this is a VERY dirty solution but i see know other way around this for the
moment :(.
I tried to explain the problem as good as i can... I thought this should be
postet here as this is surly a kernel issue. If you need more info ill try to
provide these.
cheers,
Raffaele
--
Raffaele Sandrini <rasa@gmx.ch>
next reply other threads:[~2003-11-28 16:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-28 16:09 Raffaele Sandrini [this message]
2003-12-01 22:40 ` System clock and speedstepping john stultz
2003-12-02 22:16 ` Raffaele Sandrini
2003-12-03 0:56 ` john stultz
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=200311261943.38002.rasa@gmx.ch \
--to=rasa@gmx.ch \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox