Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Aug 2005 04:08:51 +0900
From:      Hajimu UMEMOTO <ume@freebsd.org>
To:        Hajimu UMEMOTO <ume@freebsd.org>
Cc:        acpi@freebsd.org
Subject:   Re: Annoyances with passive thermal code (acpi_thermal)
Message-ID:  <ygeacjj81bw.wl%ume@mahoroba.org>
In-Reply-To: <ygek6in5e4t.wl%ume@mahoroba.org>
References:  <20050814023842.C0D845D07@ptavv.es.net> <ygezmrk2van.wl%ume@mahoroba.org> <ygeoe7zacqg.wl%ume@mahoroba.org> <4300C5DF.40409@root.org> <ygek6in5e4t.wl%ume@mahoroba.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

>>>>> On Tue, 16 Aug 2005 02:00:34 +0900
>>>>> Hajimu UMEMOTO <ume@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@mahoroba.org  ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ygeacjj81bw.wl%ume>