On Mon, 30 Dec 2013 17:39:04 -0500, ito wrote:
> 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? Does it run
cooler when idle now? What freq does it run at when idle? Here I run
gkrellm which displays freq and temperature among many other goodies.
> > 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)"...
> 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. 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
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_levels: 1133/19100 733/12500
dev.cpu.0.cx_supported: C1/0 C2/84 C3/120
dev.cpu.0.cx_usage: 0.02% 28.09% 71.87% last 681us
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.
> 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
> 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.
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.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"