From owner-freebsd-bugs@freebsd.org Wed Jan 22 18:02:06 2020 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1D06F1F79FD for ; Wed, 22 Jan 2020 18:02:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 482tXG016Nz4KGf for ; Wed, 22 Jan 2020 18:02:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 004AC1F79FC; Wed, 22 Jan 2020 18:02:06 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 000FC1F79FB for ; Wed, 22 Jan 2020 18:02:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 482tXF6DsZz4KGd for ; Wed, 22 Jan 2020 18:02:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D171615FB for ; Wed, 22 Jan 2020 18:02:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 00MI25o4020389 for ; Wed, 22 Jan 2020 18:02:05 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 00MI25a7020388 for bugs@FreeBSD.org; Wed, 22 Jan 2020 18:02:05 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f 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 Date: Wed, 22 Jan 2020 18:02:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: sigsys@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 18:02:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D234733 --- Comment #4 from sigsys@gmail.com --- Created attachment 210970 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D210970&action= =3Dedit acpidump -dt (In reply to Conrad Meyer from comment #3) Alright I tested a bunch of things based on that. It doesn't seem to be related to CPB in this case. The 0x02000000 bit never gets set (it always shows "MSR 0xc0010015: 0x00000000 0x09000011"). I trie= d to toggle it on and off again anyway in case it would reset something but it doesn't seem like it does. The CPU just seems to get stuck at the lowest frequency it has been set to. I tested by timing this: dd if=3D/dev/zero bs=3D32k count=3D20000 | cpuset -l 0 time sha1 And by setting the frequency to 3200 (maximum), 2800 and 1550: 3200: 1.34 real 1.15 user 0.17 sys 2800: 1.78 real 1.47 user 0.30 sys 1550: 3.18 real 2.78 user 0.39 sys After lowering the frequency to a given value, there's no way to get the performance back (but it lets you set the frequency higher with sysctl with= out any apparent errors). With debug.hwpstate_verbose set, there's that during boot: hwpstate0: going to fetch info from acpi_perf hwpstate0: on cpu0 And a bunch of messages like that when setting the frequency with sysctl: hwpstate0: setting P1-state on cpu0 hwpstate0: setting P1-state on cpu1 hwpstate0: setting P1-state on cpu2 hwpstate0: setting P1-state on cpu3 hwpstate0: setting P1-state on cpu4 hwpstate0: setting P1-state on cpu5 hwpstate0: setting P1-state on cpu6 hwpstate0: setting P1-state on cpu7 hwpstate0: setting P1-state on cpu8 hwpstate0: setting P1-state on cpu9 hwpstate0: setting P1-state on cpu10 hwpstate0: setting P1-state on cpu11 hwpstate0: setting P1-state on cpu12 hwpstate0: setting P1-state on cpu13 hwpstate0: setting P1-state on cpu14 hwpstate0: setting P1-state on cpu15 hwpstate0: setting P2-state on cpu0 hwpstate0: setting P2-state on cpu1 hwpstate0: setting P2-state on cpu2 hwpstate0: setting P2-state on cpu3 hwpstate0: setting P2-state on cpu4 hwpstate0: setting P2-state on cpu5 hwpstate0: setting P2-state on cpu6 hwpstate0: setting P2-state on cpu7 hwpstate0: setting P2-state on cpu8 hwpstate0: setting P2-state on cpu9 hwpstate0: setting P2-state on cpu10 hwpstate0: setting P2-state on cpu11 hwpstate0: setting P2-state on cpu12 hwpstate0: setting P2-state on cpu13 hwpstate0: setting P2-state on cpu14 hwpstate0: setting P2-state on cpu15 Never anything other than P1 and P2. I tested after a reboot and an update to recent 12-STABLE r356965 and the results were all pretty much the same. That's a B450 Pro4 still with BIOS version P3.20. Using non-UEFI boot. An= d I reset it to default settings before the last test. At the time I first reported this it had the latest BIOS version but not anymore. So maybe a B= IOS update would fix it. I'm gonna wait updating it in case more testing could= be helpful. Thanks for looking into it! No other problems apart from that on this computer. And yeah after that I figured that you don't really need to run powerd on these CPUs since they'll throttle themselves automatically anyway and they seem to be doing a good j= ob of it. But if someone does run powerd (or mess with the frequency directly) the permanent and silent slowdown can be a pretty bad surprise. --=20 You are receiving this mail because: You are the assignee for the bug.=