Annoyances with passive thermal code (acpi_thermal)
Hajimu UMEMOTO
ume at freebsd.org
Mon Aug 15 19:09:20 GMT 2005
Hi,
>>>>> On Tue, 16 Aug 2005 02:00:34 +0900
>>>>> Hajimu UMEMOTO <ume at freebsd.org> said:
nate> Would you mind checking the implementation of CPUFREQ_SET in kern_cpu.c?
nate> I'm wondering what doesn't work about it and it's the right place to
nate> solve this problem.
ume> I turned debug.cpufreq.verbose on. It seems that maximum frequency is
ume> always saved even after I set lower frequency (1050) by sysctl(8).
ume> Aug 15 04:51:05 kasuga kernel: cpufreq: saving level, freq 1200 prio 0
ume> Where, 1200 is a maximum frequency of my box.
ume> I'm now tracking CPUFREQ_SET. However, I cannot detect what is going
ume> on.
I found the cause. The saved_level is not stackable. So, an initial
cpu level was saved, then a cpu level at CPUFREQ_PRIO_USER was not
saved. Here is a patch to solve this problem:
Index: sys/kern/kern_cpu.c
diff -u -p sys/kern/kern_cpu.c.orig sys/kern/kern_cpu.c
--- sys/kern/kern_cpu.c.orig Mon Apr 11 04:11:23 2005
+++ sys/kern/kern_cpu.c Tue Aug 16 03:31:55 2005
@@ -336,6 +336,7 @@ cf_set_method(device_t dev, const struct
*/
if (sc->curr_level.total_set.freq != CPUFREQ_VAL_UNKNOWN &&
sc->saved_level.total_set.freq == CPUFREQ_VAL_UNKNOWN &&
+ sc->curr_priority > CPUFREQ_PRIO_LOWEST &&
priority > sc->curr_priority) {
CF_DEBUG("saving level, freq %d prio %d\n",
sc->curr_level.total_set.freq, sc->curr_priority);
I think it is enough to solve CPUFREQ_PRIO_USER v.s. CPUFREQ_PRIO_KERN
issue. However, it may better to have saved_level at each priority,
IMHO.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
ume at mahoroba.org ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
More information about the freebsd-acpi
mailing list