Date: Mon, 27 Jan 2020 04:52:00 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 234733] Setting CPU frequency with sysctl dev.cpu.0.fr slows a Ryzen 2700X down Message-ID: <bug-234733-227-lD2oVQ7Mxu@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-234733-227@https.bugs.freebsd.org/bugzilla/> References: <bug-234733-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733 --- Comment #11 from Conrad Meyer <cem@freebsd.org> --- Very interesting, thanks! It's the low bits of 0xc0010061 following 0xc0010062 up that is surprising / causing hwpstate(4) to ignore the user's supplied configuration (side note: we should really produce at least a *debug* log message when we ignore the user-supplied P-state!). I don't have an explanation for why 0xc0010061 low bits are following 0xc0010062. Nothing in the kernel writes that MSR, as far as I can tell. The documentation I have for c0010061 says it's error-on-write. But it also suggests that the value may be changed: "Attempts to change the CurPstateLimit to a value greater (lower performance) than PStateCurLim[PstateMaxVal] leaves CurPstateLimit unchanged.") So I'm not really sure if software/firmware can write it. Maybe the CPU's power-governor is misconfigured and is attempting to limit itself? I don't have any explanation for why it would "follow" c0010062 stepwise, though. Any chance other people with the same motherboard have reported similar problems with Linux/Windows? Any chance there is a BIOS update available? -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-234733-227-lD2oVQ7Mxu>