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/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D234733 --- Comment #11 from Conrad Meyer <cem@freebsd.org> --- Very interesting, thanks! It's the low bits of 0xc0010061 following 0xc001= 0062 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 CurPstateLi= mit to a value greater (lower performance) than PStateCurLim[PstateMaxVal] leav= es CurPstateLimit unchanged.") So I'm not really sure if software/firmware can write it. Maybe the CPU's power-governor is misconfigured and is attemptin= g to limit itself? I don't have any explanation for why it would "follow" c0010= 062 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? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-234733-227-lD2oVQ7Mxu>