From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 15 19:09:20 2005 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A1F516A41F; Mon, 15 Aug 2005 19:09:20 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id D800C43D46; Mon, 15 Aug 2005 19:09:19 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:1E5bA+ck+kkVpoQhVobgtf8mznH931YKZLMpGshIaMfc5Nw/AWgDVWt2P3Wm7/qF@[IPv6:3ffe:501:185b:801a:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j7FJ96W9080447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Aug 2005 04:09:13 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 16 Aug 2005 04:08:51 +0900 Message-ID: From: Hajimu UMEMOTO To: Hajimu UMEMOTO In-Reply-To: References: <20050814023842.C0D845D07@ptavv.es.net> <4300C5DF.40409@root.org> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.0-BETA2 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Tue, 16 Aug 2005 04:09:15 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: acpi@freebsd.org Subject: Re: Annoyances with passive thermal code (acpi_thermal) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2005 19:09:20 -0000 Hi, >>>>> On Tue, 16 Aug 2005 02:00:34 +0900 >>>>> Hajimu UMEMOTO 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/