problems getting AMD C-70 APU working with powerd/cpufreq

[Ian Smith]

On Sat, 14 Oct 2017 22:26:02 +0100, tech-lists wrote:
 > On Sat, Oct 14, 2017 at 10:36:02PM +1100, Ian Smith wrote:
 > > On Fri, 13 Oct 2017 13:37:21 +0100, tech-lists wrote:

 > > > system: FreeBSD 11.1-STABLE #0 r324342
 > > >
 > > > # sysctl debug.cpufreq.verbose=1
 > > > debug.cpufreq.verbose: 0 -> 1
 > > 
 > > This shows that cpufreq was alreasy loaded.  It's in the GENERIC kernel.
 > > Have a good browse through cpufreq(4).
 > 
 > I can't comment about earlier versions of FreeBSD, but this sysctl is present
 > on 11.1-stable without cpufreq loaded. I'm using a modified kernel - modified
 > to the extent that superfluous stuff has been removed, because this machine
 > is hardware-challenged. Without cpufreq loaded, the following sysctls are
 > present:
 > 
 > # sysctl -a | grep cpufreq
 > debug.cpufreq.verbose: 0
 > debug.cpufreq.lowest: 0

Right you are; likely all|most of the debug. tunables and sysctls are.

 > # uname -i
 > ACER
 > # cat /sys/amd64/conf/ACER |grep cpufreq
 > #
 > # cat /boot/loader.conf amdtemp_load="YES"
 > #
 > 
 > I've known this machine has had issues with cpufreq for a while, but
 > this is the first time I've sat down to try work out why. This is one
 > of the reasons why cpufreq isn't in my kernel.
 > 
 > which is why I was able to
 > 
 > > > # kldload cpufreq
 > > > #
 > 
 > no message

Indeed, sorry for bad assumption.  However, it poses other questions ..

 > (I set debug.cpufreq.verbose to 1 in order to hopefully see more
 > output)

However, this is after you've booted, right?  Might you need to add 
cpufreq_load="YES" to /boot/loader.conf, so it's loaded before being 
needed for detection / attachment during boot probing, perhaps?

I may again be misinterpreting how your dmesg arose .. you can select 
verbose boot or add boot_verbose="YES" and maybe verbose_loading="YES" 
to loader.conf too .. I often run that way and quote /var/run/dmesg.boot

 > > > dev.acpi_perf.1.%parent: cpu1
 > > > dev.acpi_perf.0.%parent: cpu0
 > > 
 > > These are interesting.  In cpufreq(4) you'll see acpi_perf is one of the
 > > absolute frequency control drivers, presumably used (see also in dmesg)
 > > because the expected driver for AMD processors, powernow, did not attach
 > > - though your verbose dmesg shows nothing about any failure/s to attach.

Again, might this be rather because cpufreq wasn't loaded before boot?

 > > > dev.cpu.1.cx_usage: 11.14% 88.85% last 156us
 > > > dev.cpu.1.cx_lowest: C2
 > > 
 > > At least you're getting plentiful use of C2 state, though I'm not aware
 > > how much power saving that might buy you on that AMD CPU.
 > 
 > Not a lot! ;)

The APU is only 9W THD anyway, and assuming it's the same or similar to
 https://www.notebookcheck.net/AMD-C-Series-C-70-Notebook-Processor.82852.0.html
and
 https://www.notebookcheck.net/Review-Acer-Aspire-One-725-C7Xkk-Notebook.89991.0.html 
then battery life should be ok?  Or maybe was, 3-4 years ago?

 > One of the reasons I'm interested in powerd/cpufreq is that I beleive it
 > can make turbo kick in. Apparently this chip has a turbo mode @1.333GHz.

As far as I know, from following various 'Turbo' mode descriptions on 
several Intel CPUs (mine is Core2Duo) - the CPU itself chooses to kick a 
core into turbo mode when conditions such as total thermal load across 
cores allows, so that one (or more, with enough cores) may run flat-out 
for a while when others are relatively idle.  That's likely a bit too
simplistic, but so is my understanding :)

powerd can be used to _prevent_ selection of turbo mode, by setting 
maximum freq (-M) to a lower freq, where turbo mode freq is represented 
(symbolically) by the maximum freq +1, eg here:
dev.cpu.0.freq_levels: 2401/35000 2400/35000 1600/15000 800/12000
dev.cpu.0.freq: 800

and powerd_flags="-a adp -b adp -i 70 -r 90 -M 2400" disables it (on 
particular advice for my CPU, which otherwise overheats on buildworld)

Mind, I did read one article somewhere suggesting powerd was needed to 
use turbo mode, but I found several aspects of that piece unconvincing.

 > might be wrong about that though.

Moi aussi :)

 > > So, there's no dev.cpu.0.freq nor dev.cpu.0.freq_levels - therefore
 > > powerd has nothing to work with.  Its (misleading?) message doesn't mean
 > > cpufreq not loaded, but that the sysctls powerd relies upon don't exist.

In this case you manually loaded cpufreq before running powerd, but I'm 
not sure that'd be enough - see if it differs any if loaded pre-boot?

 > [...]
 > 
 > > Nothing in any of those suggests that this cpu has any other frequency
 > > available than 1000MHz, which seems quite bizarre to me.  Of course it's
 > > possible FreeBSD hasn't been taught to recognise this particular cpu.
 > > 
 > > You haven't disabled anything in $BIOS related to power or freq control?
 > 
 > The bios has only a very limited number of options for this machine -
 > possibly by design as the machine is a netbook. Options for overclocking are
 > not present at all.
 > 
 > > The cpuid output has a heading "Advanced Power Management Feature Flags"
 > > near the bottom, but none are shown.
 > 
 > yeah, odd that

Well unless booting with cpufreq loaded - assuming you didn't before - 
provides any more info on why powernow(0) (STILL no manpage!) didn't at 
least try to attach, I'm out of ideas.

If you do get any further, sysctl hw.acpi might shed some light too.

cheers, Ian