Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

38 views
Skip to first unread message

tech-lists

unread,
Oct 13, 2017, 8:44:04 AM10/13/17
to
Hi,

I have a netbook with amd c-70 cpu and am trying to get powerd
to work with it. Will this chip not work with cpufreq/powerd?

system: FreeBSD 11.1-STABLE #0 r324342

# sysctl debug.cpufreq.verbose=1
debug.cpufreq.verbose: 0 -> 1
# kldload cpufreq
#
# powerd -vv
powerd: no cpufreq(4) support -- aborting: No such file or directory

# sysctl -a | grep cpu

kern.smp.cpus: 2
kern.smp.maxcpus: 256
kern.ccpu: 0
<cpu count="2" mask="3,0,0,0">0, 1</cpu>
<cpu count="1" mask="1,0,0,0">0</cpu>
<cpu count="1" mask="2,0,0,0">1</cpu>
kern.sched.cpusetsize: 32
kern.pin_pcpu_swi: 0
kern.racct.pcpu_threshold: 1
cpu HAMMER
kern.vt.splash_cpu_duration: 10
kern.vt.splash_cpu_style: 2
kern.vt.splash_ncpu: 0
kern.vt.splash_cpu: 0
vfs.ncpurgeminvnodes: 256
net.inet.tcp.per_cpu_timers: 0
debug.cpufreq.verbose: 1
debug.cpufreq.lowest: 0
debug.acpi.cpu_unordered: 0
hw.ncpu: 2
hw.acpi.cpu.cx_lowest: C2
dev.acpi_perf.1.%parent: cpu1
dev.acpi_perf.0.%parent: cpu0
dev.cpu.1.cx_method: C1/hlt C2/io
dev.cpu.1.cx_usage_counters: 237351 1893186
dev.cpu.1.cx_usage: 11.14% 88.85% last 156us
dev.cpu.1.cx_lowest: C2
dev.cpu.1.cx_supported: C1/1/0 C2/2/100
dev.cpu.1.temperature: 65.6C
dev.cpu.1.%parent: acpi0
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%location: handle=\_PR_.C001
dev.cpu.1.%driver: cpu
dev.cpu.1.%desc: ACPI CPU
dev.cpu.0.cx_method: C1/hlt C2/io
dev.cpu.0.cx_usage_counters: 368369 2358900
dev.cpu.0.cx_usage: 13.50% 86.49% last 13us
dev.cpu.0.cx_lowest: C2
dev.cpu.0.cx_supported: C1/1/0 C2/2/100
dev.cpu.0.temperature: 65.6C
dev.cpu.0.%parent: acpi0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%location: handle=\_PR_.C000
dev.cpu.0.%driver: cpu
dev.cpu.0.%desc: ACPI CPU
dev.cpu.%parent:
security.jail.param.cpuset.id: 0

cpuid output: https://www.zyxst.net/txt/amd-c70-netbook/20171011-cpuid-c70.txt
dmidecode output: https://www.zyxst.net/txt/amd-c70-netbook/20171011-dmidecode-c70.txt
detailed dmesg: https://www.zyxst.net/txt/amd-c70-netbook/20171011-2.detailed-dmesg.txt

many thanks,
--
J.
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardwa...@freebsd.org"

Ian Smith

unread,
Oct 14, 2017, 7:36:27 AM10/14/17
to
On Fri, 13 Oct 2017 13:37:21 +0100, tech-lists wrote:
> Hi,
>
> I have a netbook with amd c-70 cpu and am trying to get powerd
> to work with it. Will this chip not work with cpufreq/powerd?

Perhaps not.

> 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).

> # kldload cpufreq
> #

Hmm, no message. When I do that (albeit verbose boot enabled) on 9.3:
kldload: can't load cpufreq: module already loaded or in kernel
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.

> dev.cpu.1.cx_method: C1/hlt C2/io
> dev.cpu.1.cx_usage_counters: 237351 1893186
> 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.

> dev.cpu.1.cx_supported: C1/1/0 C2/2/100
> dev.cpu.1.temperature: 65.6C
> dev.cpu.1.%parent: acpi0
> dev.cpu.1.%pnpinfo: _HID=none _UID=0
> dev.cpu.1.%location: handle=\_PR_.C001
> dev.cpu.1.%driver: cpu
> dev.cpu.1.%desc: ACPI CPU
> dev.cpu.0.cx_method: C1/hlt C2/io
> dev.cpu.0.cx_usage_counters: 368369 2358900
> dev.cpu.0.cx_usage: 13.50% 86.49% last 13us
> dev.cpu.0.cx_lowest: C2

Ditto.

> dev.cpu.0.cx_supported: C1/1/0 C2/2/100
> dev.cpu.0.temperature: 65.6C
> dev.cpu.0.%parent: acpi0
> dev.cpu.0.%pnpinfo: _HID=none _UID=0
> dev.cpu.0.%location: handle=\_PR_.C000
> dev.cpu.0.%driver: cpu
> dev.cpu.0.%desc: ACPI CPU

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.
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 cpuid output has a heading "Advanced Power Management Feature Flags"
near the bottom, but none are shown.

Hope someone else has something more useful to offer, and thanks for
mailing me those files when my browser was deemed too old for your site.

cheers, Ian

Ian Smith

unread,
Oct 15, 2017, 11:58:43 AM10/15/17
to
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.

tech-lists

unread,
Oct 21, 2017, 9:15:58 AM10/21/17
to
On Wed, Oct 18, 2017 at 12:42:42PM +0100, tech-lists wrote:
>On Tue, Oct 17, 2017 at 06:23:06PM -0400, Anthony Jenkins wrote:
>>cpufreq(4) does not support AMD processor family 0x14 (20), which I
>>believe your dmesg showed your processor to be.
>
>aha!
>
>>I had added support for controlling the frequency on some later AMD
>>families last year, but the AMD documentation for the 0x14 family is
>>pretty complicated for my tiny brain.  The other families control
>>processor frequency with a single register, but AFACT you use P-states
>>on family 0x14.  You can have up to 8 P-states, each of which specifies
>>a power/frequency configuration.  If someone could point me to a
>>reference for controlling the frequency for this family, I could submit
>>something for review...no idea what Linux does for this family.
>
>Would it help if I were to get hardware output from booting temporarily
>to linux mint?

[thought I'd try it anyway]

Linux info here:
https://www.zyxst.net/txt/amd-c70-netbook/linux-dmesg-amdc70.txt
https://www.zyxst.net/txt/amd-c70-netbook/linux-cpufreq-info-amdc70.txt

cpufreq appears to be working on linux. Because of this and that
brightness control works, I've installed linux mint permanently. If you
need me to, I can easily boot into freebsd to run tests; equally can run
tests from linux. I'd prefer to run freebsd, but the inability to turn
down screen brightness was a showstopper.

many thanks,
--
J.
0 new messages