Thus wrote Daniele Venzano:
> > I have a notebook with an Athlon-M CPU. I tried linux 2.6.4 with
> > CONFIG_X86_PM_TIMER=y and I noticed that /proc/cpuinfo doesn't get
> > updated when I switch frequency (via sysfs, using powernow-k7). The is
> > issue seems cosmetic only, CPU frequency changes (watching
> > temperature/battery life).
> I can confirm, I'm seeing the same behavior. Please note that the
> bogomips count gets updated, it's only the frequency that doesn't
> change.
Same here with a P4-M, follow-up to John and Dmitry.
Best regards,
--
Karol 'sziwan' Kozimor
[email protected]
On Tuesday 16 March 2004 04:42 pm, Karol Kozimor wrote:
> Thus wrote Daniele Venzano:
> > > I have a notebook with an Athlon-M CPU. I tried linux 2.6.4 with
> > > CONFIG_X86_PM_TIMER=y and I noticed that /proc/cpuinfo doesn't get
> > > updated when I switch frequency (via sysfs, using powernow-k7). The is
> > > issue seems cosmetic only, CPU frequency changes (watching
> > > temperature/battery life).
> > I can confirm, I'm seeing the same behavior. Please note that the
> > bogomips count gets updated, it's only the frequency that doesn't
> > change.
>
> Same here with a P4-M, follow-up to John and Dmitry.
> Best regards,
>
PM timer does not install CPUFREQ handler which would scale cpu_khz to
give proper display. I might cook up something later tonight.
--
Dmitry
On Tue, 2004-03-16 at 13:42, Karol Kozimor wrote:
> Thus wrote Daniele Venzano:
> > > I have a notebook with an Athlon-M CPU. I tried linux 2.6.4 with
> > > CONFIG_X86_PM_TIMER=y and I noticed that /proc/cpuinfo doesn't get
> > > updated when I switch frequency (via sysfs, using powernow-k7). The is
> > > issue seems cosmetic only, CPU frequency changes (watching
> > > temperature/battery life).
> > I can confirm, I'm seeing the same behavior. Please note that the
> > bogomips count gets updated, it's only the frequency that doesn't
> > change.
>
> Same here with a P4-M, follow-up to John and Dmitry.
Hmm. This is untested, but I think this should do the trick.
Dominik: Is there any reason I'm not seeing why cpu_khz should only be
updated when using the TSC?
thanks
-john
===== arch/i386/kernel/timers/timer_tsc.c 1.36 vs edited =====
--- 1.36/arch/i386/kernel/timers/timer_tsc.c Tue Feb 3 21:35:49 2004
+++ edited/arch/i386/kernel/timers/timer_tsc.c Tue Mar 16 15:23:49 2004
@@ -360,8 +360,8 @@
if (variable_tsc)
cpu_data[freq->cpu].loops_per_jiffy = cpufreq_scale(loops_per_jiffy_ref, ref_freq, freq->new);
#ifndef CONFIG_SMP
+ cpu_khz = cpufreq_scale(cpu_khz_ref, ref_freq, freq->new);
if (use_tsc) {
- cpu_khz = cpufreq_scale(cpu_khz_ref, ref_freq, freq->new);
if (variable_tsc) {
fast_gettimeoffset_quotient = cpufreq_scale(fast_gettimeoffset_ref, freq->new, ref_freq);
set_cyc2ns_scale(cpu_khz/1000);
On Tue, Mar 16, 2004 at 03:28:15PM -0800, john stultz wrote:
> On Tue, 2004-03-16 at 13:42, Karol Kozimor wrote:
> > Thus wrote Daniele Venzano:
> > > > I have a notebook with an Athlon-M CPU. I tried linux 2.6.4 with
> > > > CONFIG_X86_PM_TIMER=y and I noticed that /proc/cpuinfo doesn't get
> > > > updated when I switch frequency (via sysfs, using powernow-k7). The is
> > > > issue seems cosmetic only, CPU frequency changes (watching
> > > > temperature/battery life).
> > > I can confirm, I'm seeing the same behavior. Please note that the
> > > bogomips count gets updated, it's only the frequency that doesn't
> > > change.
> >
> > Same here with a P4-M, follow-up to John and Dmitry.
>
> Hmm. This is untested, but I think this should do the trick.
>
> Dominik: Is there any reason I'm not seeing why cpu_khz should only be
> updated when using the TSC?
Is cpu_khz always correct (or, at least, nonzero) when we're reaching this
code path?
Dominik
On Tue, 2004-03-16 at 15:19, Dmitry Torokhov wrote:
> On Tuesday 16 March 2004 04:42 pm, Karol Kozimor wrote:
> > Thus wrote Daniele Venzano:
> > > > I have a notebook with an Athlon-M CPU. I tried linux 2.6.4 with
> > > > CONFIG_X86_PM_TIMER=y and I noticed that /proc/cpuinfo doesn't get
> > > > updated when I switch frequency (via sysfs, using powernow-k7). The is
> > > > issue seems cosmetic only, CPU frequency changes (watching
> > > > temperature/battery life).
> > > I can confirm, I'm seeing the same behavior. Please note that the
> > > bogomips count gets updated, it's only the frequency that doesn't
> > > change.
> >
> > Same here with a P4-M, follow-up to John and Dmitry.
> > Best regards,
> >
>
> PM timer does not install CPUFREQ handler which would scale cpu_khz to
> give proper display. I might cook up something later tonight.
Actually, the cpufreq handler is installed by an initcall regardless of
which time-source is used. However as the handler changes a few TSC
specific variables, it exits in timer_tsc.c.
I think the fix I just mailed should do the trick. Let me know if it
doesn't.
thanks
-john
Thus wrote john stultz:
> Hmm. This is untested, but I think this should do the trick.
Hmm... without the patch, neither cpu MHz nor bogomips are updated, with
the patch cpu MHz value seems correct (both using acpi.ko and
speedstep-ich.ko, but the bogomips is still at its initial value.
Best regards,
--
Karol 'sziwan' Kozimor
[email protected]
On Tuesday 16 March 2004 06:32 pm, john stultz wrote:
> On Tue, 2004-03-16 at 15:19, Dmitry Torokhov wrote:
> > PM timer does not install CPUFREQ handler which would scale cpu_khz to
> > give proper display. I might cook up something later tonight.
>
> Actually, the cpufreq handler is installed by an initcall regardless of
> which time-source is used. However as the handler changes a few TSC
> specific variables, it exits in timer_tsc.c.
>
Yes, you are of course right, I missed that fact, sorry.
--
Dmitry
On Tuesday 16 March 2004 07:13 pm, Karol Kozimor wrote:
> Thus wrote john stultz:
> > Hmm. This is untested, but I think this should do the trick.
>
> Hmm... without the patch, neither cpu MHz nor bogomips are updated, with
> the patch cpu MHz value seems correct (both using acpi.ko and
> speedstep-ich.ko, but the bogomips is still at its initial value.
> Best regards,
>
Karol, do you have a P4? AFAIK P4's TSC is stable even if core frequence
changes so loop_per_juffy (== bogomips) need not be updated.
--
Dmitry