Comment 1 Conrad Meyer 2017-08-19 06:19:01 UTC

Well, I don't know what is actually logging that line.  But I expect the problem lies in hwpstates, probably in the family-specific MSR support that does not yet include 17h (Zen):

https://svnweb.freebsd.org/base/head/sys/x86/cpufreq/hwpstate.c?view=markup#l397

I don't have this hardware around yet (waiting on a board to come back in stock), but I know a couple others do.

Comment 2 Conrad Meyer 2017-08-19 06:25:00 UTC

By the way, setting 'debug.hwpstate_verbose="1"' in loader.conf may show a little more of what is going on.

Comment 3 Conrad Meyer 2017-08-19 06:42:43 UTC

Please try the following patch:

--- a/sys/x86/cpufreq/hwpstate.c
+++ b/sys/x86/cpufreq/hwpstate.c
@@ -83,6 +83,10 @@ __FBSDID("$FreeBSD$");
 #define        AMD_10H_11H_CUR_DID(msr)                (((msr) >> 6) & 0x07)
 #define        AMD_10H_11H_CUR_FID(msr)                ((msr) & 0x3F)

+#define        AMD_17H_CUR_VID(msr)                    (((msr) >> 14) & 0xFF)
+#define        AMD_17H_CUR_DID(msr)                    (((msr) >> 8) & 0x3F)
+#define        AMD_17H_CUR_FID(msr)                    ((msr) & 0xFF)
+
 #define        HWPSTATE_DEBUG(dev, msg...)                     \
        do{                                             \
                if(hwpstate_verbose)                    \
@@ -427,6 +431,15 @@ hwpstate_get_info_from_msr(device_t dev)
                case 0x16:
                        hwpstate_set[i].freq = (100 * (fid + 0x10)) >> did;
                        break;
+               case 0x17:
+                       did = AMD_17H_CUR_DID(msr);
+                       if (did == 0) {
+                               HWPSTATE_DEBUG(dev, "unexpected did: 0\n");
+                               did = 1;
+                       }
+                       fid = AMD_17H_CUR_FID(msr);
+                       hwpstate_set[i].freq = (200 * fid) / did;
+                       break;
                default:
                        HWPSTATE_DEBUG(dev, "get_info_from_msr: AMD family"
                            " 0x%02x CPUs are not supported yet\n", family);

It is based on the Family 17h Reference manual and compiles, but obviously I am unable to test it.

(In reply to Conrad Meyer from comment #2)

Thanks.  Here's what verbose mode returns.  I'll take the system down to apply the patch in the morning and report back:

2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu0
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu1
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu2
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu3
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu4
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu5
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu6
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu7
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu8
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu9
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu10
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu11
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu12
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu13
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu14
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu15
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu16
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu17
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu18
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu19
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu20
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu21
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu22
2017-08-19 01:24:03	gzy	kernel	hwpstate0: setting P1-state on cpu23
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu0
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu1
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu2
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu3
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu4
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu5
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu6
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu7
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu8
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu9
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu10
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu11
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu12
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu13
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu14
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu15
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu16
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu17
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu18
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu19
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu20
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu21
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu22
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: result  P2-state on cpu23
2017-08-19 01:24:03	gzy	kernel	hwpstate0: error: loop is not enough.
2017-08-19 01:24:03	gzy	kernel	hwpstate0: set freq failed, err 6

Comment 5 Conrad Meyer 2017-08-19 18:13:45 UTC

Hm, it's interesting that setting pstates fails like that.  The current code should be valid on Zen.  I don't see any documentation in the reference manual on transition latency, but given this loop is processed sequentially it seems that it never succeeded even after 24 * 0.01 = 0.24 seconds.  That seems like it should be plenty of time to me, but I don't know.

Maybe hardware or some other system is controlling the p-state on your system?

(In reply to Conrad Meyer from comment #5)
As your last post suspected, that patch didn't change the hwpstate0 error.  

I ran powerd -v and it returns the following messages, if they're helpful.  

I only hesitate in saying that you're almost certainly right that something in the hardware or firmware is controlling the power because of the powerd output below  (says no frequency adjustments happening).  OTOH, the system has definitely been running much (_much_) cooler than I thought it would.

I'll install Windows later today to see if its power management changes the temperature,fan speed, etc. in any way that's noticeably different.

Any other ideas?  And, if not, what's the cleanest way to stop the hwpstate0 messages from filling my log without losing any important functionality?

Thanks again.  Here's the powerd output:

powerd -v
powerd: unable to determine AC line status
load   7%, current freq 3500 MHz ( 0), wanted freq 3390 MHz
load  14%, current freq 3500 MHz ( 0), wanted freq 3284 MHz
load   0%, current freq 3500 MHz ( 0), wanted freq 3181 MHz
load   6%, current freq 3500 MHz ( 0), wanted freq 3081 MHz
load  10%, current freq 3500 MHz ( 0), wanted freq 2984 MHz
changing clock speed from 3500 MHz to 3000 MHz
powerd: error setting CPU frequency 3000: Device not configured
load  83%, current freq 3500 MHz ( 0), wanted freq 7000 MHz
load  17%, current freq 3500 MHz ( 0), wanted freq 6781 MHz
load   0%, current freq 3500 MHz ( 0), wanted freq 6569 MHz
load  19%, current freq 3500 MHz ( 0), wanted freq 6363 MHz
load   3%, current freq 3500 MHz ( 0), wanted freq 6164 MHz
load  19%, current freq 3500 MHz ( 0), wanted freq 5971 MHz
load   2%, current freq 3500 MHz ( 0), wanted freq 5784 MHz
load   4%, current freq 3500 MHz ( 0), wanted freq 5603 MHz
load   0%, current freq 3500 MHz ( 0), wanted freq 5427 MHz
load   0%, current freq 3500 MHz ( 0), wanted freq 5257 MHz
load   2%, current freq 3500 MHz ( 0), wanted freq 5092 MHz
load   0%, current freq 3500 MHz ( 0), wanted freq 4932 MHz
load   9%, current freq 3500 MHz ( 0), wanted freq 4777 MHz
load  14%, current freq 3500 MHz ( 0), wanted freq 4627 MHz
load   5%, current freq 3500 MHz ( 0), wanted freq 4482 MHz
load   0%, current freq 3500 MHz ( 0), wanted freq 4341 MHz
load   5%, current freq 3500 MHz ( 0), wanted freq 4205 MHz
load   0%, current freq 3500 MHz ( 0), wanted freq 4073 MHz
load   6%, current freq 3500 MHz ( 0), wanted freq 3945 MHz
load   0%, current freq 3500 MHz ( 0), wanted freq 3821 MHz
load   3%, current freq 3500 MHz ( 0), wanted freq 3701 MHz
load   0%, current freq 3500 MHz ( 0), wanted freq 3585 MHz
load  14%, current freq 3500 MHz ( 0), wanted freq 3472 MHz
load   5%, current freq 3500 MHz ( 0), wanted freq 3363 MHz
load   0%, current freq 3500 MHz ( 0), wanted freq 3257 MHz
load   4%, current freq 3500 MHz ( 0), wanted freq 3155 MHz
load   0%, current freq 3500 MHz ( 0), wanted freq 3056 MHz
load   6%, current freq 3500 MHz ( 0), wanted freq 2960 MHz
changing clock speed from 3500 MHz to 3000 MHz
powerd: error setting CPU frequency 3000: Device not configured
load 142%, current freq 3500 MHz ( 0), wanted freq 7000 MHz
load   0%, current freq 3500 MHz ( 0), wanted freq 6781 MHz
load   7%, current freq 3500 MHz ( 0), wanted freq 6569 MHz
load   5%, current freq 3500 MHz ( 0), wanted freq 6363 MHz
load   8%, current freq 3500 MHz ( 0), wanted freq 6164 MHz
load   0%, current freq 3500 MHz ( 0), wanted freq 5971 MHz
load   6%, current freq 3500 MHz ( 0), wanted freq 5784 MHz
load   3%, current freq 3500 MHz ( 0), wanted freq 5603 MHz
load  11%, current freq 3500 MHz ( 0), wanted freq 5427 MHz
load   0%, current freq 3500 MHz ( 0), wanted freq 5257 MHz
load  20%, current freq 3500 MHz ( 0), wanted freq 5092 MHz
load   4%, current freq 3500 MHz ( 0), wanted freq 4932 MHz
load  34%, current freq 3500 MHz ( 0), wanted freq 4932 MHz
load   6%, current freq 3500 MHz ( 0), wanted freq 4777 MHz
load   3%, current freq 3500 MHz ( 0), wanted freq 4627 MHz
load   5%, current freq 3500 MHz ( 0), wanted freq 4482 MHz
load   0%, current freq 3500 MHz ( 0), wanted freq 4341 MHz
load   2%, current freq 3500 MHz ( 0), wanted freq 4205 MHz
load   0%, current freq 3500 MHz ( 0), wanted freq 4073 MHz
load   6%, current freq 3500 MHz ( 0), wanted freq 3945 MHz
load   0%, current freq 3500 MHz ( 0), wanted freq 3821 MHz
load   6%, current freq 3500 MHz ( 0), wanted freq 3701 MHz
load   4%, current freq 3500 MHz ( 0), wanted freq 3585 MHz
load   3%, current freq 3500 MHz ( 0), wanted freq 3472 MHz
load   0%, current freq 3500 MHz ( 0), wanted freq 3363 MHz
load  10%, current freq 3500 MHz ( 0), wanted freq 3257 MHz
load   6%, current freq 3500 MHz ( 0), wanted freq 3155 MHz
load  28%, current freq 3500 MHz ( 0), wanted freq 3155 MHz
load   8%, current freq 3500 MHz ( 0), wanted freq 3056 MHz
load   0%, current freq 3500 MHz ( 0), wanted freq 2960 MHz
changing clock speed from 3500 MHz to 3000 MHz
powerd: error setting CPU frequency 3000: Device not configured
load 103%, current freq 3500 MHz ( 0), wanted freq 7000 MHz
load   6%, current freq 3500 MHz ( 0), wanted freq 6781 MHz
load   0%, current freq 3500 MHz ( 0), wanted freq 6569 MHz
load  14%, current freq 3500 MHz ( 0), wanted freq 6363 MHz
^Ctotal joules used: 71.757

Comment 7 Conrad Meyer 2017-08-19 19:13:02 UTC

(In reply to Sean P.R. from comment #6)
I suspect the repeated logging is coming from powerd's attempts to change the p-state (error 6 == ENXIO == "Device not configured").  If you disable the powerd service, does the log spam go away?  It doesn't seem like powerd is doing anything for now anyway, so disabling it seems harmless.

It's interesting that powerd is reporting the machine in P0, and attempting to transition to P1.  Attempting to set P1 matches what the hwpstate module is logging; however, hwpstate is reporting that the machine is actually in P2 instead!

So it seems there is some discrepancy between what hwpstate sees and what powerd sees.  Perhaps powerd is just seeing stale cached data from hwpstate.

Either way, if the CPU is truly in P2 (2.2GHz base), that would explain the low temperatures.

(In reply to Conrad Meyer from comment #7)

The hwpstate0 error messages stay the same regardless whether I have powerd disabled or enabled...  Sounds like nothing else to try at the moment then?  thanks again.

Comment 9 Conrad Meyer 2017-08-19 19:32:07 UTC

(In reply to Sean P.R. from comment #8)
Yeah, sorry, I don't have any other ideas.  I couldn't find that specific log message so I don't know where it's coming from.

Comment 10 Conrad Meyer 2017-08-19 19:48:06 UTC

The error message is the same as https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167018 .  Unfortunately, the change that fixed it for those processors is already included in CURRENT and 11.1, so it seems we have a different issue here.  Perhaps the MSRC001_0071 register mentioned in https://lists.freebsd.org/pipermail/freebsd-stable/2012-May/067758.html would work better on Zen?  I don't see it documented in the reference manual, though.

Instead, there is MSRC001_0293 "Hardware PState Status," which has HW p-state in bits 22-24?

But the text seems to indicate that the existing register is the right one to check:

> § 2.1.5.2.1.2    Core P-state Visibility
>
> MSRC001_0063[CurPstate] reflects the current non-boosted P-state number for
> each core. For example, if Core::X86::Msr::PStateStat[CurPstate]=001b on core
> 1, then core 1 is in the P1 state.

Sorry I'm not more help :-).

(In reply to Conrad Meyer from comment #10)

Hi,

I want to know where the text is. Because
in https://support.amd.com/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf ,
There is no content of the section "2.1.3 CPU Power Management".
the next line is the section 2.1.4.
If you have this section's content, you can go forward, I think.
I'm waiting for this section's content.

By the way, the error messages should be gone away, if powerd is not running.
I wonder why :-)?

Comment 12 Conrad Meyer 2017-08-21 15:59:23 UTC

(In reply to mailsed from comment #11)
The updated (in-progress, not finalized) version of the PPR on AMD's developer hub has some content in "CPU Power Management," now numbered 2.1.5 (but that may change).

(In reply to Conrad Meyer from comment #12)

After some playing around yesterday I think your earlier suspicious is right - pretty sure the BIOS is controlling the p-state. 

MB is msi X399 "Gaming Pro Carbon AC."  Uses AMI BIOS.  Same behavior under BIOS versions 1.2 (shipped), 1.3 (official release, flashed), and 1.43 (beta release, flashed)

Since the sensors aren't giving much useful information, I've been focused on watching the fans; I can see that the fans increase and decrease speed according to the load.  Very unscientifically, fan behavior looks about the same under ordinary use as in Windows, where I can see from the MB manufacturer's tool that the p-state varies a bit under load.  Of course, there are also AMD chipset drivers that allow more fine-grained control under Windows, so BIOS control shouldn't be mutually exclusive.

One possible lead:  I am pretty sure that the MB LEDs always read "AA" when booted into FreeBSD.  According to the manual, that means "System has transitioned into ACPI mode. Interrupt controller is in APIC mode." - while the CPU temperature should be displayed "after the CPU has fully booted into the OS."  It's possible I'm misreading "99" as "AA," but I'm pretty sure not.  See PDF page 48 of http://download.msi.com/archive/mnu_exe/E7B09v1.0.zip

Re error messages- In addition to disabling powerd, I turned everything I could find related to AHCI software control (I'm impatient :P).  That fixed it and things are running acceptably* (*in terms of power management; performance is great under FreeBSD and most common tasks are faster than Windows).

Happy to help debug more if you like.


[public service p.s. in case someone having other trouble with this MB happens across this message in a search:  (1) turn off the XHCI hand off or there's a high probability the USB controller will go into a reset loop; and (2) virtualization is turned off by default and BIOS versions < the 1.43 beta inexplicably lack the option to turn it on, so bhyve and vbox will fail until you flash the BIOS and enable "SVM"]

One more data point - OpenBSD's power management appears to work fine with no errors reported, in case their code's helpful in debugging.  Set to hw.perfpolicy=auto it switches between "low" (2200MHz) and "high" (3500MHz) based on how hard I'm working the machine, or at least that's what the daemon log reports (in a series of short tests).  Manually switching to low keeps things at 2200MHz in the same tests.

Comment 15 Conrad Meyer 2017-08-22 04:53:55 UTC

(In reply to Sean P.R. from comment #14)
If someone wants to investigate what OpenBSD does differently here, I think the relevant files are:

https://github.com/openbsd/src/blob/master/sys/arch/amd64/amd64/k1x-pstate.c
https://github.com/openbsd/src/blob/master/sys/dev/acpi/acpicpu.c

(Grep for cpu_setperf(), which is a callback called by the "auto" hw.perfpolicy policy in sched_bsd.c.)

Comment 16 Conrad Meyer 2017-09-06 02:09:45 UTC

I've noticed a curious thing on my 1950X.  Setting P0 or P2 works fine.  But P1 does not:

$ sysctl dev.cpu.0.freq=2800
dev.cpu.0.freq: 3400
sysctl: dev.cpu.0.freq=2800: Device not configured
$ sysctl dev.cpu.0.freq=2200
dev.cpu.0.freq: 3400 -> 2200
$ sysctl dev.cpu.0.freq=3400
dev.cpu.0.freq: 2200 -> 3400

Do you observe the same (well, similar) thing on your 1920X?  OpenBSD's power management might "work" by only toggling between P0 and P2.  Or otherwise ignoring the inability to set P1.

Comment 17 Conrad Meyer 2017-09-06 02:36:40 UTC

By the way, I also note that the failure to set P1 drives the load average up enough that powerd thinks P0 is correct again.  So we don't just try P2 eventually because of that, I think.  I see the same thing as you (comment 6) (except my P0 is 3400 and P2 is only 2800):

load  10%, current freq 3500 MHz ( 0), wanted freq 2984 MHz
changing clock speed from 3500 MHz to 3000 MHz
powerd: error setting CPU frequency 3000: Device not configured
load  83%, current freq 3500 MHz ( 0), wanted freq 7000 MHz
      ^^^                              ^^^^^^^^^^^^^^^^^^^^
...
load   6%, current freq 3500 MHz ( 0), wanted freq 2960 MHz
changing clock speed from 3500 MHz to 3000 MHz
powerd: error setting CPU frequency 3000: Device not configured
load 142%, current freq 3500 MHz ( 0), wanted freq 7000 MHz
     ^^^^                              ^^^^^^^^^^^^^^^^^^^^
...
load   0%, current freq 3500 MHz ( 0), wanted freq 2960 MHz
changing clock speed from 3500 MHz to 3000 MHz
powerd: error setting CPU frequency 3000: Device not configured
load 103%, current freq 3500 MHz ( 0), wanted freq 7000 MHz
     ^^^^                              ^^^^^^^^^^^^^^^^^^^^

Comment 18 Conrad Meyer 2017-09-06 20:02:25 UTC

I've changed hwpstate's mechanism to wait for CPUs to switch frequency levels from DELAY() to sleep()[0].   This allows the CPU to idle instead of spinning for the duration of the failed transition to P1.  This at least allows powerd to switch to P2 eventually:

$ powerd -v
...
// Load is added
...
load  34%, current freq 2200 MHz ( 2), wanted freq 2200 MHz
load 100%, current freq 2200 MHz ( 2), wanted freq 6800 MHz
changing clock speed from 2200 MHz to 3400 MHz
load 100%, current freq 3400 MHz ( 0), wanted freq 6800 MHz
...
// Load is removed
...
load   0%, current freq 3400 MHz ( 0), wanted freq 2877 MHz
load   0%, current freq 3400 MHz ( 0), wanted freq 2787 MHz
changing clock speed from 3400 MHz to 2800 MHz
powerd: error setting CPU frequency 2800: Device not configured
load   2%, current freq 3400 MHz ( 0), wanted freq 2699 MHz
changing clock speed from 3400 MHz to 2800 MHz
powerd: error setting CPU frequency 2800: Device not configured
load   2%, current freq 3400 MHz ( 0), wanted freq 2614 MHz
changing clock speed from 3400 MHz to 2800 MHz
powerd: error setting CPU frequency 2800: Device not configured
load   2%, current freq 3400 MHz ( 0), wanted freq 2532 MHz
changing clock speed from 3400 MHz to 2800 MHz
powerd: error setting CPU frequency 2800: Device not configured
load   2%, current freq 3400 MHz ( 0), wanted freq 2452 MHz
changing clock speed from 3400 MHz to 2800 MHz
powerd: error setting CPU frequency 2800: Device not configured
load   0%, current freq 3400 MHz ( 0), wanted freq 2375 MHz
changing clock speed from 3400 MHz to 2800 MHz
powerd: error setting CPU frequency 2800: Device not configured
load   0%, current freq 3400 MHz ( 0), wanted freq 2300 MHz
changing clock speed from 3400 MHz to 2800 MHz
powerd: error setting CPU frequency 2800: Device not configured
load   0%, current freq 3400 MHz ( 0), wanted freq 2228 MHz
changing clock speed from 3400 MHz to 2800 MHz
powerd: error setting CPU frequency 2800: Device not configured
load   2%, current freq 3400 MHz ( 0), wanted freq 2200 MHz
changing clock speed from 3400 MHz to 2200 MHz
load   0%, current freq 2200 MHz ( 2), wanted freq 2200 MHz

[0]: https://reviews.freebsd.org/D12260

Comment 19 commit-hook 2017-09-07 20:21:31 UTC

A commit references this bug:

Author: cem
Date: Thu Sep  7 20:20:12 UTC 2017
New revision: 323286
URL: https://svnweb.freebsd.org/changeset/base/323286

Log:
  cpufreq(4) hwpstate: Yield CPU awaiting frequency change

  It doesn't seem necessary to busy the CPU while waiting to transition
  into a different p-state.

  PR:		221621 (related, but does not completely address)
  Reviewed by:	truckman
  Sponsored by:	Dell EMC Isilon
  Differential Revision:	https://reviews.freebsd.org/D12260

Changes:
  head/sys/x86/cpufreq/hwpstate.c

(In reply to Conrad Meyer from comment #18)

Sorry I dropped off for a while.  Please let me know if there's something I can help test this weekend.

Comment 21 Conrad Meyer 2017-11-30 20:32:56 UTC

Resolved by r326383 + r326407.  Now we simply do not verify if the value set reads back from MSR.