On Tuesday 28 July 2009 19:31:10 pierre@xxxxxxxxxxxxxxxxxx wrote:
> Hi.
> I'm on gentoo.
> I use powernow-k8 since a long time now...
> since I switched to 2.6.30, p-k8 works randomly : everything sounds good
> except
> some times, I got max frequency = min frequency...
>
> here some more details :
>
> kernel config :
>
> CONFIG_X86_ACPI_CPUFREQ=y
> CONFIG_X86_POWERNOW_K8=y
> CONFIG_CPU_FREQ=y
> CONFIG_CPU_FREQ_TABLE=y
> CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
> CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
> CONFIG_CPU_FREQ_GOV_ONDEMAND=y
>
> dmesg | grep powernow :
>
> [ 0.721303] powernow-k8: Found 1 AMD Turion(tm) 64 X2 Mobile Technology
> TL-58 processors (2 cpu cores) (version 2.20.00)
> [ 0.721549] powernow-k8: 0 : fid 0xb (1900 MHz), vid 0x12
> [ 0.721635] powernow-k8: 1 : fid 0xa (1800 MHz), vid 0x13
> [ 0.721719] powernow-k8: 2 : fid 0x8 (1600 MHz), vid 0x14
> [ 0.721804] powernow-k8: 3 : fid 0x0 (800 MHz), vid 0x1e
>
> as you can see, different freqs are correctly detected, but
> cpufreq-info :
>
> cpufrequtils 005: cpufreq-info (C) Dominik Brodowski 2004-2006
> Report errors and bugs to cpufreq@xxxxxxxxxxxxxxx, please.
> analyzing CPU 0:
> driver: powernow-k8
> CPUs which need to switch frequency at the same time: 0 1
> hardware limits: 800 MHz - 1.90 GHz
> available frequency steps: 1.90 GHz, 1.80 GHz, 1.60 GHz, 800 MHz
> available cpufreq governors: ondemand, performance
> current policy: frequency should be within 800 MHz and 800 MHz.
> The governor "performance" may decide which speed to use
> within this range.
> current CPU frequency is 800 MHz (asserted by call to hardware).
> analyzing CPU 1:
> driver: powernow-k8
> CPUs which need to switch frequency at the same time: 0 1
> hardware limits: 800 MHz - 1.90 GHz
> available frequency steps: 1.90 GHz, 1.80 GHz, 1.60 GHz, 800 MHz
> available cpufreq governors: ondemand, performance
> current policy: frequency should be within 800 MHz and 800 MHz.
> The governor "performance" may decide which speed to use
> within this range.
> current CPU frequency is 800 MHz (asserted by call to hardware).
>
>
> look on "current policy" line for both processors, even if different freqs
> are
> detected, governor policy is wrong.
>
> for i in /sys/devices/system/cpu/cpu0/cpufreq/*; do echo $i; cat $i; done;
> /sys/devices/system/cpu/cpu0/cpufreq/affected_cpus
> 0 1
> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
> 800000
> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
> 1900000
> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq
> 800000
> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency
> 109000
> /sys/devices/system/cpu/cpu0/cpufreq/ondemand
> cat: /sys/devices/system/cpu/cpu0/cpufreq/ondemand: Is a directory
> /sys/devices/system/cpu/cpu0/cpufreq/related_cpus
> 0 1
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
> 1900000 1800000 1600000 800000
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
> ondemand performance
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
> 800000
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
> powernow-k8
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
> ondemand
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
> 800000 <--- here is the pb
Maybe you should open a bug report, this is a regression and worked
with older kernels?
Reduced max_freq (if there is no bug) can automatically
be set by:
- the BIOS through _PCC
- through passive cooling
Passive Cooling
---------------
Do:
cat /proc/acpi/thermal_zone/*/trip_points
(Can you post this one somewhere)
If the temperature exceeds the passive trip point, frequency
will get reduced. Cleaning fans, buying a bigger fan, buy a smaller graphics
card or whatever might help then.
BIOS through _PCC limit
-----------------------
There should happen a processor change event, which you can grab
via:
acpi_listen
(not sure whether it's part of the official acpid, hopefully).
An ACPI processor event 0x80 should happen. The last value is the _PPC value.
A value of 0 means unlimited, max_freq equals cpuinfo_max_freq,
A value of 1 means the highest freq is not allowed.
Or you compile in CONFIG_CPU_FREQ_DEBUG=y and enable cpufreq.debug=1 and look out
for:
cpufreq_printk("CPU %d: _PPC is %d - frequency %s limited\n", pr->id,
(int)ppc, ppc ? "" : "not");
Both very much depends on ACPI, do you see any errors/warnings somewhere in dmesg?
Thomas
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
> 800000
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
> <unsupported>
>
>
> and
> for i in /sys/devices/system/cpu/cpu0/cpufreq/ondemand/*;do echo $i;cat
> $i;done;
> /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load
> 0
> /sys/devices/system/cpu/cpu0/cpufreq/ondemand/powersave_bias
> 0
> /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate
> 109000
> /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate_max
> 54500000
> /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate_min
> 54500
> /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
> 95
>
>
>
> as you can see, /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq is the
> problem. should be 1900000
>
> ls -l /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq gives 644 and
> root:root
>
> echo "1900000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
> gives no
> error but does nothing
>
> cpufreq-set -u 1900000 gives no error but does nothing either.
>
> cpufreq-set -g ondemand/performance changes governor, but not
> scaling_max_freq
>
>
> so to sum up, randomly, sometimes during boot, scaling_max_freq is set
> wrongly
> (=scaling_min_freq), and I can't find a way to change it ...
>
>
> I have even try to compile gov_ondemand as a module, and set performance as
> default. loading cpufreq_ondemand module gives :
> CPUFREQ: ondemand sampling_rate_max sysfs file is deprecated - used by: cat
> CPUFREQ: ondemand sampling_rate_min sysfs file is deprecated - used by: cat
> but no futher progress...
>
> I read somewhere that compiling kernel with
> CONFIG_X86_ACPI_CPUFREQ=y
> CONFIG_X86_POWERNOW_K8=m
> helped some folks. I will try it now.
>
>
> the biggest pb is that it happens randomly. let's say once out of 3 boots...
>
> pierre
>
> --
> To unsubscribe from this list: send the line "unsubscribe cpufreq" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
