Bug 221621
| Summary: | Ryzen Threadripper - hwpstate0 - repeated set frequency failed err 6 | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Sean P.R. <seanpr> |
| Component: | kern | Assignee: | Conrad Meyer <cem> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | CC: | cem, emaste, mailsed |
| Priority: | --- | ||
| Version: | 11.1-STABLE | ||
| Hardware: | amd64 | ||
| OS: | Any | ||
| URL: | https://reviews.freebsd.org/D12082 | ||
| See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219213 | ||
| Bug Depends on: | |||
| Bug Blocks: | 219213 | ||
|
Description
Sean P.R.
2017-08-19 05:42:16 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. By the way, setting 'debug.hwpstate_verbose="1"' in loader.conf may show a little more of what is going on. 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 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 (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. (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. 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 :-)? (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. (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.) 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. 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 ^^^^ ^^^^^^^^^^^^^^^^^^^^ 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 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. Resolved by r326383 + r326407. Now we simply do not verify if the value set reads back from MSR. |
