issues with powerd/freq_levels

Ian Smith smithi at nimnet.asn.au
Wed Aug 2 18:07:25 UTC 2017


On Wed, 2 Aug 2017 13:30:03 +0300, Daniel Braniss wrote:
 > > On 1 Aug 2017, at 20:45, Ian Smith <smithi at nimnet.asn.au> wrote:
 > > 
 > > On Mon, 31 Jul 2017 12:03:27 -0700, Kevin Oberman wrote:
 > >> On Mon, Jul 31, 2017 at 3:48 AM, Ian Smith <smithi at nimnet.asn.au> wrote:
 > >> 
 > >>> On Mon, 31 Jul 2017 10:09:11 +0300, Daniel Braniss wrote:
 > >>> 
 > >>>> I am trying out PCengines latest apu2 boards, and I just noticed that
 > >>> with different Freebsd versions I get
 > >>>> different freq_levels, and so when idling, each box (have 5) has a
 > >>> different freq/temperature value, ranging
 > >>>> from 125/69.1C, 600/59.0C to 75/56.0C
 > >>>> 
 > >>>> FreeBSD apu-4 11.1-STABLE FreeBSD 11.1-STABLE #5 f565b5a06ab3 (11) tip:
 > >>> Mon Jul 31 09:36:33 IDT 2017
 > >>>> apu-4# sysctl dev.cpu.0.freq_levels
 > >>>> dev.cpu.0.freq_levels: 1000/980 800/807 600/609
 > >>> 
 > >>> That looks about right.

Time to cut out lots and summarise a bit, from your dmesgs:

apu-3 dmesg that you posted, presumably the same 11.1-STABLE as the 
apu-4 above, to within a few days, shows only:

hwpstate0: <Cool`n'Quiet 2.0> on cpu0
random: harvesting attach, 8 bytes (4 bits) from cpufreq0
random: harvesting attach, 8 bytes (4 bits) from hwpstate0
Device configuration finished.

Which appears to be what you want - but are you seeing the hwpstate 
errors from powerd that Karl commented on?

 > >>> hint.p4tcc.0.disabled=1
 > >>> hint.acpi_throttle.0.disabled=1

 > >>>> FreeBSD apu-5 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #0 21e9d1ca9b80
 > >>> (11) tip: Tue May 30 11:51:48 IDT 2017
 > >>>> apu-5# sysctl dev.cpu.0.freq_levels
 > >>>> dev.cpu.0.freq_levels: 1000/966 875/845 800/795 700/695 600/600 525/525
 > >>> 450/450 375/375 300/300 225/225 150/150 75/75
 > >>> 
 > >>> Looks like either p4tcc or acpi_throttle is enabled?  See cpufreq(4).

hwpstate0: <Cool`n'Quiet 2.0> on cpu0
random: harvesting attach, 8 bytes (4 bits) from hwpstate0
acpi_throttle1: <ACPI CPU Throttling> on cpu1
acpi_throttle1: failed to attach P_CNT
device_attach: acpi_throttle1 attach returned 6
acpi_throttle2: <ACPI CPU Throttling> on cpu2
acpi_throttle2: failed to attach P_CNT
device_attach: acpi_throttle2 attach returned 6
acpi_throttle3: <ACPI CPU Throttling> on cpu3
acpi_throttle3: failed to attach P_CNT
device_attach: acpi_throttle3 attach returned 6
Device configuration finished.

So it's loaded hwpstate(0) but only apparently successfully attached to 
cpu0, and failed to attach acpi_throttle to cpus 1-3, yet the cpu0 
freq_levels are those of your 3 real freqs (1000, 800, 600) times all 
x/8 factors.  So that one may not have hint.acpi_throttle.0.disabled=1?

 > >>>> FreeBSD apu-1 10.3-STABLE FreeBSD 10.3-STABLE #4 267788fd852c (10) tip:
 > >>> Tue Jan 10 09:09:00 IST 2017
 > >>>> apu-1# sysctl dev.cpu.0.freq_levels
 > >>>> dev.cpu.0.freq_levels: 1000/-1 875/-1 750/-1 625/-1 500/-1 375/-1
 > >>> 250/-1 125/-1
 > >>> 
 > >>> And that looks like est(4) isn't enabled/attaching at all .. see dmesg
 > >>> on all of these for clues.

This is a different board entirely.  Different CPU, L2 unified cache, 
ethernet devices (Realtek vs Intel), less memory (4G vs 4.5G) and 2 vs 4 
CPUs (unless HT is off on this and on on the others?), SATA-2 vs SATA-3 
on ada0, only USB2 vs some USB3 (XHCI), and a different cpufreq setup 
again .. no sign of hwpstate and:

acpi_throttle0: <ACPI CPU Throttling> on cpu0
acpi_throttle0: P_CNT from P_BLK 0x810
acpi_throttle1: <ACPI CPU Throttling> on cpu1
acpi_throttle1: failed to attach P_CNT
device_attach: acpi_throttle1 attach returned 6
Device configuration finished.

Sounds like a bogon must have found its way into your batch?

 > > Danny, can you put up a verbose boot dmesg.boot of one(?) for a browse? 
 > > Or maybe apu-4 and -1, if not all.  I'd expect error msgs on -1 anyway.

 > they are now available	at:
 > 	http://www.cs.huji.ac.il/~danny/pcengines/ <http://www.cs.huji.ac.il/~danny/pcengines/>

Thanks, that made it all pretty clear.  Not that I know much about lots 
of this stuff, especially nowadays, but some things stuck out.

Kevin wrote:
 > >> Temperature is a totally separate issue. It is VERY sensitive to external
 > >> issue like airflow and position of the CPU in relation to other components
 > >> in the chassis Also, unless you have a lot of cores, you probably should
 > >> set both economy_cx_lowest and performance_cx_lowest to Cmax. Economy
 > >> should default to that, but  performance will not as that can cause issues
 > >> on systems with large numbers of cores, so is set to C2. Many such system
 > >> used to disable deeper sleep modes in BIOS, but I am way behind the times
 > >> and don't know about the current state of affairs. Certainly for systems
 > >> with 32 or fewer cores, this should not be an issue. In any case, Cx state
 > >> can sharply impact temperature.
 > > 
 > > Indeed.  But as these are low-power devices already, it's likely less of 
 > > a concern, but maximising efficiency and minimising stress never hurts.

Yes, it might be helpful to see Danny's version of the data Karl showed:
$ sysctl -a|grep cpu.0
$ sysctl -a|grep cx
on an 11.1-STABLE one at least.

In fact Karl's 59.2C temperature (at 1000MHz, perhaps only momentarily 
as 'sysctl -a' has powerd take my older box to 1133) ~matches Danny's.

 > > Danny, is powerd running on all these?  I doubt it would load on apu-1 
 > > as it stands.  
 > 
 > it is working on the apu-1!

Ok, but using bogus x/8 clock multipliers of 1000MHz.  But I expect 
you'll be wanting to exchange that box for one of the others anyway?

Is it working on the others?  Does it actually idle at 600MHz?  If in 
doubt, running 'powerd -v' for a while will show you what's happening.  
Despite being low power, running slower when more or less idle - along 
with hopefully getting to use C2 state - should cool these down a lot.

Perhaps there were hwpstate and/or cpufreq updates between 11.1-PRE and 
-STABLE?  Any deeper out of my depth and I mightn't come up for air!

cheers, Ian


More information about the freebsd-stable mailing list