AMD A12-8800B ACPI questions (turbo mode, temp zones)
Johannes Dieterich
dieterich.joh at gmail.com
Thu Dec 17 01:56:18 UTC 2015
On Wed, Dec 16, 2015 at 12:55 PM, Ian Smith <smithi at nimnet.asn.au> wrote:
> On Tue, 15 Dec 2015 10:05:36 -0500, Johannes Dieterich wrote:
> > thanks for the response!
> >
> > On Tue, Dec 15, 2015 at 9:15 AM, Ian Smith <smithi at nimnet.asn.au> wrote:
> > > On Sun, 13 Dec 2015 19:53:52 -0500, Johannes Dieterich wrote:
> > > > Dear list,
> > > >
> > > > I am running CURRENT on an HP elitebook 745 G3 which comes with a AMD
> > > > A12-8800B CPU. All in all, it runs very well with just a few nits to
> > > > pick. Two of them are ACPI related.
> > > >
> > > > 1) there are 5 thermal zones defined out of which only two provide
> > > > reasonable numbers it seems:
> > > >
> > > > hw.acpi.thermal.tz4.temperature: 34.1C
> > > > hw.acpi.thermal.tz3.temperature: 0.1C
> > > > hw.acpi.thermal.tz2.temperature: 0.1C
> > > > hw.acpi.thermal.tz1.temperature: 0.1C
> > > > hw.acpi.thermal.tz0.temperature: 56.1C
> > > >
> > > > my gut feeling is that tz0-tz3 may be the CPU cores and tz4 would be
> > > > the GPU (which does not work in BSD ATM, hence consistently lower
> > > > temp). I guess this is not a big deal (everything works) but I still
> > > > wonder how to fix it.
> > >
> > > Not sure if anything needs fixing, but I only have Intel gear these
> > > days and am not up on the AMD side of things. However, please show:
> > >
> > > % sysctl dev.cpu
>
> > dev.cpu.3.cx_method: C1/hlt C2/io
> > dev.cpu.3.cx_usage_counters: 25314 20561
>
> These are both new in 11.0, I suppose _counters shows relative use of
> each C-state per CPU, which is then reflected in:
>
> > dev.cpu.3.cx_usage: 55.18% 44.81% last 979us
>
> > dev.cpu.2.cx_usage_counters: 25676 20634
> > dev.cpu.2.cx_usage: 55.44% 44.55% last 1300us
>
> > dev.cpu.1.cx_usage_counters: 27544 21225
> > dev.cpu.1.cx_usage: 56.47% 43.52% last 1836us
>
> > dev.cpu.0.cx_usage_counters: 35013 29515
> > dev.cpu.0.cx_usage: 54.26% 45.73% last 1686us
> > dev.cpu.0.cx_lowest: C2
> > dev.cpu.0.cx_supported: C1/1/0 C2/2/400
> > dev.cpu.0.freq_levels: 2100/4717 1800/3450 1400/2320
> > dev.cpu.0.freq: 2100
> > 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:
>
> OK, noting that 400ns penalty for C2 state seems quite a lot, and that
> 4.7, 3.45 and 2.32W suggests a very low power usage CPU (more below).
The thermal envelope is 15W sustained, 25W for (I believe) up to 15 min turbo.
Do you think the 400ns is too high, i.e., a problem in reading the
CPU? Would this indicate some wrong parsing of ASL?
> > > % sysctl hw.acpi.thermal
> > hw.acpi.thermal.tz4._TSP: 300
> > hw.acpi.thermal.tz4._TC2: 0
> > hw.acpi.thermal.tz4._TC1: 50
> > hw.acpi.thermal.tz4._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
> > hw.acpi.thermal.tz4._CRT: 128.1C
> > hw.acpi.thermal.tz4._HOT: -1
> > hw.acpi.thermal.tz4._PSV: 55.1C
> > hw.acpi.thermal.tz4.thermal_flags: 0
> > hw.acpi.thermal.tz4.passive_cooling: 1
> > hw.acpi.thermal.tz4.active: -1
> > hw.acpi.thermal.tz4.temperature: 29.1C
>
> This is interesting; it's the only one using passive cooling, and has a
> very low _PSV cut-in temperature at 55C. I think the .1C shown with
> each of these is probably bogus, slight miscalculation? Unless this is
> CPU temperature, I don't know how passive cooling might be applied, but
> then I don't know anything about the 8-core GPU in this thing either, so
> it might indeed be for the GPU(s).
>
> If it is the CPU(s) then the low _PSV figure of 55C might have something
> to do with controlling whether it could/would use the turbo mode/s, but
> that's merely wild speculation .. it may be controlled by CPU microcode
> without OS intervention, for all I know .. I've no time to research it.
See below for link to the whitepaper. I am far from an expert but the
language does indicate for me some hardware control in terms of what
states are even allowed at a given point (probably associated with
thermals).
> > hw.acpi.thermal.tz3._TSP: -1
> > hw.acpi.thermal.tz3._TC2: -1
> > hw.acpi.thermal.tz3._TC1: -1
> > hw.acpi.thermal.tz3._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
> > hw.acpi.thermal.tz3._CRT: 128.1C
> > hw.acpi.thermal.tz3._HOT: -1
> > hw.acpi.thermal.tz3._PSV: -1
> > hw.acpi.thermal.tz3.thermal_flags: 0
> > hw.acpi.thermal.tz3.passive_cooling: 0
> > hw.acpi.thermal.tz3.active: -1
> > hw.acpi.thermal.tz3.temperature: 0.1C
>
> [ and exactly the same for tz2 and tz1 - I've no idea about these ]
>
> > hw.acpi.thermal.tz0._TSP: -1
> > hw.acpi.thermal.tz0._TC2: -1
> > hw.acpi.thermal.tz0._TC1: -1
> > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
> > hw.acpi.thermal.tz0._CRT: 128.1C
> > hw.acpi.thermal.tz0._HOT: 102.1C
> > hw.acpi.thermal.tz0._PSV: -1
> > hw.acpi.thermal.tz0.thermal_flags: 0
> > hw.acpi.thermal.tz0.passive_cooling: 0
> > hw.acpi.thermal.tz0.active: -1
> > hw.acpi.thermal.tz0.temperature: 48.1C
>
> This looks more like a typical active cooling setup, active meaning with
> a fan or such to control temperature, however there are no trip points
> set (_ACx) only the _HOT setting, so I'm really not sure. I'm less sure
> this is likely to be a CPU temperature, though, though tz0 typically is.
> See acpi_thermal(4).
>
> Have you tried running powerd(8) with it?
powerd is enabled.
> If you run it on battery and run acpiconf -i0 occasionally, what sort of
> power usage do you see - in mW or maybe in mA - a) when idle and b) when
> cranked up as hard as possible? Just curious, as the chip TDP's rated
> at 15W which seems very low for 4 cores at 2.1GHz, let alone 3.4GHz, and
> then plus 8 GPU cores.
1508 mA (18954 mW) when firefox runs in background
3373 mA (40088 mW) when building kernel w/ 4 threads
Indeed reviews point out that the CPU cannot meet the 15W envelope
with the GPU under full load AND the CPU even at base (i.e., 2.1GHz)
so it'll downclock the CPU. It is supposedly quite capable of
maintaining base when the GPU is not stressed too much and typically
runs even above base.
> > hw.acpi.thermal.user_override: 0
> > hw.acpi.thermal.polling_rate: 10
> > hw.acpi.thermal.min_runtime:
> >
> > That does indeed show an awful lot of -1, or?
>
> -1 in general just means 'unset', 'not used' or 'not applicable' in this
> context; in the case of .active it means 'inactive'.
>
> > > which may provide more clues. Perhaps all 4 cores are in one package,
> > > in which case individual CPU temperatures may not be too meaningful. I
> > > don't know whether there's any equivalent to coretemp(4) for AMD CPUs?
> > >
> > > Yours won't use est(4) but perhaps powernow(0) - 0 meaning no manpage :)
> > > but both are in GENERIC kernels. You should be able to glean from dmesg
> > > which driver/s are in use; a verbose dmesg.boot might come in handy.
>
> > verbose boot does show neither powernow nor est.
> >
> > http://llamapost.net/verbose_boot holds the verbose boot.
>
> Ok, it's already using hwpstate (creating hwpstate0 on boot), see
> http://svnweb.freebsd.org/base/head/sys/x86/cpufreq/hwpstate.c?view=log
>
> This code hasn't changed substantially since my stable/9 version; no
> mention at all of any 'turbo' mode handling. It can work well, it says,
> with acpi_perf, but that's likely disabled as it douesn't appear (except
> regarding random noisily harvesting entropy) so:
>
> /*
> * If we cannot get info from acpi_perf,
> * Let's get info from MSRs.
> */
> if (error)
> error = hwpstate_get_info_from_msr(dev);
> if (error)
> return (error);
>
> device_set_desc(dev, "Cool`n'Quiet 2.0");
> return (0);
>
> which is the description in your dmesg, so it is loaded and running, and
> doesn't need loading. You could try setting the debug.hwpstate_verbose
> tunable if you want to see it chatting about what it's doing for a bit?
Did that at runtime, I see no output in messages.
> > > > 2) turbo mode: this is a more major issue. sysctl reports the
> > > > following for all four cores:
> > > >
> > > > dev.cpu.0.cx_lowest: C2
> > > > dev.cpu.0.cx_supported: C1/1/0 C2/2/400
> > > > dev.cpu.0.freq_levels: 2100/4717 1800/3450 1400/2320
> > > > dev.cpu.0.freq: 2100
> > > >
> > > > >From the intel CPUs w/ turbo mode I had before I know that there
> > > > should be (at least) a 2101 frequency indicating the turbo clock. This
> > > > frequency is absent, I suspect this means turbo mode does not work.
> > >
> > > Or that these CPUs just don't have a turbo mode, as such? I expect the
> > > specs on AMD's site should mention that, either way?
> > http://products.amd.com/en-us/search/APU/AMD-PRO-A-Series-Processors/AMD-PRO-A-Series-A12-APU-for-Laptops/AMD-PRO-A12-8800B-with-Radeon%E2%84%A2-R7-Graphics/164
>
> That's a bit thin. It says it has 'max turbo core speed' of 3.4GHz, but
> I didn't know where to go digging for a description of how it works; in
> any case, it seems currently entirely unsupported.
>From http://support.amd.com/TechDocs/50742_15h_Models_60h-6Fh_BKDG.pdf
(which I assume applies to my CPU) on p59, I understand that there may
be multiple boosted P states (Pb states) w/ there own registers, see
table 10. I understand you need to query NumBoostStates which in turn
allows you to enumerate the Pb states.
No idea if this is maybe a culprit but 2.5.2.1.7.3.2, p63 states
explicitly that only non-boosted P states get a _PSS object in the
ACPI. Could that be why PB states are not being picked up?
> > So it does have a turbo mode up to 3.4 GHz, I recall reading from a
> > review (sorry, no link) that it should also have multiple steps in
> > between 2.1 and 3.4 (it would supposedly typically run in between the
> > two).
>
> I wonder if anyone is working on that? Andriy? (cc'd)
>
> > > > How can I debug this? I believe also that this AMD chip has multiple
> > > > frequencies above the base clock of 2100, so how would that show?
> > >
> > > What leads you to believe that? Where is this documented?
> > > > Loaded modules:
> > > >
> > > > Id Refs Address Size Name
> > > > 1 23 0xffffffff80200000 1e79670 kernel
> > > > 2 1 0xffffffff8207b000 384858 zfs.ko
> > > > 3 2 0xffffffff82400000 ca38 opensolaris.ko
> > > > 4 1 0xffffffff8240d000 22b98 geom_eli.ko
> > > > 5 1 0xffffffff82431000 ac60 aesni.ko
> > > > 6 1 0xffffffff8243d000 1c520 fuse.ko
> > > > 7 1 0xffffffff82621000 358b ums.ko
> > > > 8 1 0xffffffff82625000 223c4 ipfw.ko
> > > >
> > > > I should note that I boot in legacy mode, not EFI.
> > > >
> > > > asl dump available from http://llamapost.net/elitebook.asl
> > >
> > > If it cxomes to that ..
> > >
> > > > Thanks a lot!
> > > >
> > > > Johannes
> > >
> > > Not much help, but I see noone else springing to your aid so far ..
> > Thanks either way!
>
> No worries, but I've waded in over my head. Hopefully the big kids will
> now rescue me and say something useful about your prospects with it.
>
> cheers, Ian
Johannes
More information about the freebsd-acpi
mailing list