From owner-freebsd-acpi@FreeBSD.ORG Tue Dec 31 11:59:43 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DAC4D36E for ; Tue, 31 Dec 2013 11:59:43 +0000 (UTC) Received: from frontend1.warwick.net (wvtcvoicemail.wvtc.com [204.255.24.102]) by mx1.freebsd.org (Postfix) with SMTP id 9AE181AD4 for ; Tue, 31 Dec 2013 11:59:42 +0000 (UTC) Received: (qmail 7707 invoked from network); 31 Dec 2013 11:53:01 -0000 Received: from 70.44.113.171.res-cmts.sefg.ptd.net (HELO [70.44.113.171]) (egunther@warwick.net@70.44.113.171) by frontend1.warwick.net with SMTP (192a62b4-7212-11e3-9ff9-001e0b616b8e); Tue, 31 Dec 2013 06:53:01 -0500 Message-ID: <1388490780.2797.15.camel@res-cmts> Subject: Re: loud fan pavilion ze2000 From: ito To: Ian Smith Date: Tue, 31 Dec 2013 06:53:00 -0500 In-Reply-To: <20131231155224.R35277@sola.nimnet.asn.au> References: <1387551635.2533.21.camel@res-cmts> <20131221152703.E25305@sola.nimnet.asn.au> <1387666895.5356.22.camel@res-cmts> <20131222153537.T25305@sola.nimnet.asn.au> <1388443144.2697.31.camel@res-cmts> <20131231155224.R35277@sola.nimnet.asn.au> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-MagicMail-UUID: 192a62b4-7212-11e3-9ff9-001e0b616b8e X-MagicMail-Authenticated: egunther@warwick.net Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 11:59:43 -0000 On Tue, 2013-12-31 at 18:49 +1100, Ian Smith wrote: > On Mon, 30 Dec 2013 17:39:04 -0500, ito wrote: > > Ok, > > > > So I have tried looking around more, and working on powerd.There seems > > to be no difference in any change I make aside from the temperature staying > > below where I set PSV. > > > > hw.acpi.thermal.tz0_PSV: 85C > > > > (set back to what it was) > > So does your noisy fan run less often with powerd running? Not as far as I can tell. Negligible if any. > Does it run > cooler when idle now? It does run cooler when the passive cooling setpoint is lower (under duress), other than that it hovers between 59-64C. > What freq does it run at when idle? Here I run > gkrellm which displays freq and temperature among many other goodies. > I will install that. > > > I wouldn't worry about that. Are you not running powerd(8)? As Kevin > > > Oberman often points out, p4tcc is for thermal control - as we've just > > > exercised - but cpufreq(4), controlled by powerd, is the way to save > > > power when you don't need the CPU running at maximum frequency, which is > > > likely most times. Running it slower when idle _greatly_ reduces heat. > > > > cpufreq and powerd, but I have a question about that; in the man page > > for powerd, a bug is stated thus; > > "if powerd is used with power_profile, they may override each other." > > > > -in any case it seems to me both are being used on this machine.- > > > > man cpu freq --------snip---------- > > ..."The cpufreq driver provides a unified kernel and user interface to CPU > > frequency control drivers. It combines multiple drivers offering different > > settings into a single interface of all possible levels. Users can access > > this interface directly via sysctl(8) or by indicating to > > /etc/rc.d/power_profile that it should switch settings when the AC line state > > changes via rc.conf(5)"... > > > > ------------snip------------ > > > > I thought that cpufreq calls or is called by /etc/rc.d/power_profile. I see > > in the script that is 'power_profile' that it is called via devd. > > > > Does one actually edit the script, /etc/rc.d/power_profile? Or is there > > a more user friendly approach? > > This is not really a problem; no, and yes. devd only runs power_profile > whenever the line state changes between AC power and battery. Right! that hadn't sunk in after reading it multiple times. In /etc/rc.d/power_profile > When this > happens, power_profile sets both C-state and CPU frequency to the values > set in rc.conf of the below variables, the default settings of which are > in /etc/defaults/rc.conf: > > performance_cx_lowest="HIGH" # Online CPU idle state > performance_cpu_freq="NONE" # Online CPU frequency > economy_cx_lowest="HIGH" # Offline CPU idle state > economy_cpu_freq="NONE" # Offline CPU frequency > > With performance_cpu_freq and economy_cpu_freq set to the default NONE, > you'll see that power_profile makes no change to CPU frequency. If you > set it to say HIGH or LOW, then power_profile will set freq to the max > or min freq - or other value you specify - but only until powerd next > adjusts freq according to load, likely less than 500ms later, so even > then it's really a non-issue .. only relevant when NOT using powerd. > > You likely DO want to set performance_cx_lowest and economy_cx_lowest > however. I use "C3" for both but that may not be best for your Celeron: > > smithi on t23% sysctl dev.cpu.0 | grep -v '\.%' > dev.cpu.0.freq: 733 > dev.cpu.0.freq_levels: 1133/19100 733/102500 > dev.cpu.0.cx_supported: C1/0 C2/84 C3/120 > dev.cpu.0.cx_lowest: C3 > dev.cpu.0.cx_usage: 0.02% 28.09% 71.87% last 681us > Those are set to C2 and running in that state 99%. AC power. > You can see mine's mostly running C3 state (on AC power), nice and cool > and easy on power .. I'm only listening to a radio stream and typing :) > > Read https://wiki.freebsd.org/TuningPowerConsumption for the good oil. > OK! > > While trying to dig out the problem: > > Non-problem, but digging is educational .. > > > I tried kldstat -v | grep cpu > > > > 503 cpu/smist > > 502 cpu/powernow > > 501 cpu/p4tcc > > 500 cpu/hwpstate > > 499 cpu/est > > 486 legacy/cpu > > 33 cpu/acpi_perf > > 24 acpi/cpu > > 410 cpu/cpufreq > > 112 cpu/ichss > > 37 cpu/acpi_throttle > > > > Most if not all of these are related to thermal control, no? It looks like there > > is redundancy, is that the case? > > No, GENERIC contains drivers for many CPUs and chipsets. See cpufreq(4) > which mentions all those except hwpstate, for some AMDs I recall, as is > powernow, though all the cpufreq drivers still lack their own man pages. > > cheers, Ian > > PS you may find freebsd-mobile a better list for many questions such as > this one, not specifically to do with ACPI functioning and development. > Yes, and that was my next question, where else to ask/look. Thanks, eg > [snip]