System clock and speedstepping

System clock and speedstepping

[Raffaele Sandrini]

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>

Re: System clock and speedstepping

[john stultz]

On Fri, 2003-11-28 at 08:09, Raffaele Sandrini wrote:
> 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).

Hmmm. Can any of the cpufreq folks comment on this? I'm guessing
time_cpufreq_notifier() isn't updating fast_gettimeoffset_quotient
properly. I've never had a laptop that did cpufreq properly, so I've
never been able to test this. 

> 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.

If the cpufreq code isn't working right, the system will seem to loose a
massive amount of timer ticks, which will be noted and we'll fall back
to using the PIT as a time source.  Although if you're seeing such heavy
skew, I'm surprised we don't trip that code earlier. 

> 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 :(.

The "sane timesource" is the PIT (programmable interval timer). The TSC
is the Time-Stamp-Counter which is basically a cycle counter on the cpu.
If you want to boot using the PIT instead of the TSC, you can override
the default time source by using  "clock=pit" as a boot option. However
hopefully the problem can be fixed by adjusting the cpufreq code. As I
don't have any such hardware, would you be interested in testing
possible patches?

thanks
-john

Re: System clock and speedstepping

[Raffaele Sandrini]

On Monday 01 December 2003 23:40, john stultz wrote:
>
> The "sane timesource" is the PIT (programmable interval timer). The TSC
> is the Time-Stamp-Counter which is basically a cycle counter on the cpu.
> If you want to boot using the PIT instead of the TSC, you can override
> the default time source by using  "clock=pit" as a boot option. However
> hopefully the problem can be fixed by adjusting the cpufreq code. As I
> don't have any such hardware, would you be interested in testing
> possible patches?
>
> thanks
> -john
>

Im willing to solve it another way: There is a patch around (included in the 
mm paches) for the kernel wich introduces a ACPI timer (timesource). As im 
successfully using ACPI here ill switch over to it. A collegue of mine (who 
had equal problems) reportet that this driver solves the problem completly.

About your patches: I would surely test your patches... i think its necessray 
to have a good bug less standard implementation  of the timesource.

BTW: The time screw was huge. Especially if i ran programms wich needed all 
the recources avalible (while(1){}).

cheers,
Raffaele
-- 
Raffaele Sandrini <rasa@gmx.ch>

Re: System clock and speedstepping

[john stultz]

On Tue, 2003-12-02 at 14:16, Raffaele Sandrini wrote:
> On Monday 01 December 2003 23:40, john stultz wrote:
> >
> > The "sane timesource" is the PIT (programmable interval timer). The TSC
> > is the Time-Stamp-Counter which is basically a cycle counter on the cpu.
> > If you want to boot using the PIT instead of the TSC, you can override
> > the default time source by using  "clock=pit" as a boot option. However
> > hopefully the problem can be fixed by adjusting the cpufreq code. As I
> > don't have any such hardware, would you be interested in testing
> > possible patches?

> Im willing to solve it another way: There is a patch around (included in the 
> mm paches) for the kernel wich introduces a ACPI timer (timesource). As im 
> successfully using ACPI here ill switch over to it. A collegue of mine (who 
> had equal problems) reportet that this driver solves the problem completly.

I'm glad the ACPI PM time source is working for you. I hope it will
solve a great number of these sorts of issues on systems that support
it, but its not quite ready to be included. So the more testing the
better! Thanks!


> About your patches: I would surely test your patches... i think its necessray 
> to have a good bug less standard implementation  of the timesource.

Indeed. There are many systems that do not have working ACPI PM
timesource, so making sure the cpufreq code works for the TSC timesource
is important. I appreciate your offer. 

> BTW: The time screw was huge. Especially if i ran programms wich needed all 
> the recources avalible (while(1){}).

Very interesting. Give me some time to generate a patch that will give
more debug info, and then we can sort out what is happening for sure. 

thanks
-john