From owner-freebsd-acpi@FreeBSD.ORG Mon Dec 30 22:39:13 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52799C2F for ; Mon, 30 Dec 2013 22:39:13 +0000 (UTC) Received: from frontend2.warwick.net (mail.warwick.net [204.255.24.103]) by mx1.freebsd.org (Postfix) with SMTP id 152431775 for ; Mon, 30 Dec 2013 22:39:12 +0000 (UTC) Received: (qmail 20982 invoked from network); 30 Dec 2013 22:39:05 -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 frontend2.warwick.net with SMTP (3008c4d6-71a3-11e3-8283-001f2909bf3e); Mon, 30 Dec 2013 17:39:05 -0500 Message-ID: <1388443144.2697.31.camel@res-cmts> Subject: Re: loud fan pavilion ze2000 From: ito To: freebsd-acpi@freebsd.org Date: Mon, 30 Dec 2013 17:39:04 -0500 In-Reply-To: <20131222153537.T25305@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> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-MagicMail-UUID: 3008c4d6-71a3-11e3-8283-001f2909bf3e X-MagicMail-Authenticated: egunther@warwick.net Cc: Ian Smith 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: Mon, 30 Dec 2013 22:39:13 -0000 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) > 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? While trying to dig out the problem: 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? thanks, eg > Right, 1135 / 1298 ~= .875 = 7/8, so yes that's your 1.3GHz CPU dropping > down one step for thermal control. OK > > I suppose that is the 8 (freq_levels) you where referring to. Further I > > infer that this -1 means that the BIOS has set them or does set them. > Yes, but here the -1 indicates for freq_levels that power consumption in milliwatts at that freq is unknown, likely the same for p4tcc settings. Ok. > While doing the above (find) the fan is on but not full out. > > find(1) works disk harder than CPU as a rule, though here that command > gets xorg about 70% busy, and keeps going for ages after hitting ^C, as > it lists each file on the disk :) Maybe useful: find / -name "*acpi*" OK, I will keep that in mind find / -name "*acpi*" > > PS, is this the exact command? > > " dd if=/dev/random > of=/dev/null " > > No, no. I was careful to be precise, and yes a mistyped dd can be > dangerous, and redirected to a file could indeed fill your disk. > Fortunately that one doesn't work, invalid filename. see dd(1). > OK so "dd if=/dev/urandom of=/dev/null" I see: if=FILE read from file instead of stdin /dev/urandom, kernels random number generator of=FILE write to FILE instead of stdout /dev/null, data sink : > > I am reluctant to type anything like dd: anything: I'm not really that > > confident with the command line. > > Without your redirection it just reads from /dev/random, burning CPU, > discarding the output, until you hit ^C .. perfectly safe. > :> > > After setting the PSV value it does not go above 71 when rendering > > animation with blender. > > Yeah rendering will busy the CPU (and GPU too) pretty well. Good, so > we know passive cooling works (in case your fan ever really packs up). > The passive cooling seems to work pretty well. :0 > > I will try cleaning it again, but I think I remember that I thought > > cleaning would fix it before. > > Unless you live in an extraordinarily dust-free environment, this needs > doing with some regularity anyway. I did mine the other day, as summer > ambient temperatures over 30C are becoming normal here (happy solstice!) > I did a quick cleaning but did not want to take it apart at the moment. However, I noticed in the past that a thorough cleaning only helped but did not solve noise. > At the temperatures you've quoted, apart from annoying fan noise, it > doesn't seem broken to me. How warm does it run just idling (versus > what ambient temperature where you are)? > Yeah, thats the thing this is an old computer and all but it still works +stock+ more or less. That is one of the few things that is actually bothersome, the fan that is. I do not have AC but the window is often open, it is winter here. I would guess between 60-70 degrees Fahrenheit (15-21C). > > > > Found the source online for freebsd acpi. > > It'll be on your disk if you installed sources. I did not install the sources, although I did find acpiio.h in /usr/include/dev/acpica/ so I may try the find command you mentioned (find -name "*acpi*") and see what else I can find. And as I mentioned I can find it online. > > So I guess that I could adjust the throttling, through the process that > > the machine uses to save power?? > > 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. Powerd is the first thing that was mentioned on the FreeBSD forums. I tried it but possibly did not configure it properly. It did not seem to fix the fan issue and as I said above the computer works fine otherwise; no emergency shut down's or slow downs really to speak of. I don't really work this computer that hard so I am not demanding too much out of it. Which is why I thought maybe the 'normal' operation of the CPU could be curtailed. ----- -----------/etc/rc.conf---------- ----snip----- powerd_enable="YES" powerd_flags="-a adp -b min -i 30" ------snip------ ----------------------- ------ --I am trying powerd -i 30 to see where it gets me. > cheers, Ian Thanks a bunch, eg----------