On Tue, Jul 02, 2024 at 11:15:14AM +0200, Greg Kroah-Hartman wrote: > On Mon, Jul 01, 2024 at 04:53:20PM -0500, Mario Limonciello wrote: > > On 7/1/2024 11:13, Lars Wendler wrote: > > > Hello Mario, > > > > > > Am Mon, 1 Jul 2024 10:58:17 -0500 > > > schrieb Mario Limonciello <mario.limonciello@xxxxxxx>: > > > > > > > > I've tested both, 6.9.7 and 6.10-rc6 and they both don't have that > > > > > issue. I can disable CPU boost with both kernel versions. > > > > > > > > Thanks for checking those. That's good to hear it's only an issue in > > > > the LTS series. > > > > > > > > It means we have the option to either drop that patch from LTS kernel > > > > series or identify the other commit(s) that helped it. > > > > > > > > Can you see if adding this commit to 6.6.y helps you? > > > > > > > > https://git.kernel.org/superm1/c/8164f743326404fbe00a721a12efd86b2a8d74d2 > > > > > > that commit does not fix the regression. > > > > > > > I think I might have found the issue. > > > > With that commit backported on 6.6.y in amd_pstate_set_boost() the policy > > max frequency is nominal *1000 [1]. > > > > However amd_get_nominal_freq() already returns nominal *1000 [2]. > > > > If you compare on 6.9 get_nominal_freq() doesn't return * 1000 [3]. > > > > So the patch only makes sense on 6.9 and later. > > > > We should revert it in 6.6.y. > > > > > > > > Greg, > > > > > > Can you please revert 8f893e52b9e0 ("cpufreq: amd-pstate: Fix the > > inconsistency in max frequency units") in 6.6.y? > > Sure, but why only 6.6.y? What about 6.1.y, should it be reverted from > there as well? And have now done so.
