[Bug 217931] New: amd-pstate lacks crucial features: CPU frequency and boost control

[Bug 217931] New: amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

            Bug ID: 217931
           Summary: amd-pstate lacks crucial features: CPU frequency and
                    boost control
           Product: Power Management
           Version: 2.5
          Hardware: AMD
                OS: Linux
            Status: NEW
          Severity: high
          Priority: P3
         Component: cpufreq
          Assignee: linux-pm@vger.kernel.org
          Reporter: aros@gmx.com
        Regression: No

Created attachment 305131
  --> https://bugzilla.kernel.org/attachment.cgi?id=305131&action=edit
Power Options: Processor Power Management in Windows

It would be really great if amd-pstate had a feature parity with acpi-cpufreq,
namely

1) Being able to set operating frequencies (maximum, minimum and user-defined)

2) Being able to enable/disable boost

Currently both features are not available and frequency control is simply
ignored (bug 215800).

Rationale:

1) This is required for benchmarking and proper temperature control. Boost
frequencies are subject to multiple limitations (power in watts, amperage,
voltage, temperature, BIOS limitations) and can change depending on the
workload. Setting a low enough frequency allows to run benchmarks in the
controlled environment and get proper data.

Windows allows to do that easily, see the attached screenshot.

2) Disabling boost is an easy option to subdue operating temperatures though if
the previous issue is tackled, it's not really needed.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #1 from Artem S. Tashkinov (aros@gmx.com) ---
*** Bug 215800 has been marked as a duplicate of this bug. ***

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

Re: [Bug 217931] New: amd-pstate lacks crucial features: CPU frequency and boost control

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 1916 bytes --]

On Wed, Sep 20, 2023 at 11:06:51AM +0000, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=217931
> 
>             Bug ID: 217931
>            Summary: amd-pstate lacks crucial features: CPU frequency and
>                     boost control
>            Product: Power Management
>            Version: 2.5
>           Hardware: AMD
>                 OS: Linux
>             Status: NEW
>           Severity: high
>           Priority: P3
>          Component: cpufreq
>           Assignee: linux-pm@vger.kernel.org
>           Reporter: aros@gmx.com
>         Regression: No
> 
> Created attachment 305131
>   --> https://bugzilla.kernel.org/attachment.cgi?id=305131&action=edit
> Power Options: Processor Power Management in Windows
> 
> It would be really great if amd-pstate had a feature parity with acpi-cpufreq,
> namely
> 
> 1) Being able to set operating frequencies (maximum, minimum and user-defined)

ondemand, conservative, performance?

> 
> 2) Being able to enable/disable boost

What is boost?

> 
> Currently both features are not available and frequency control is simply
> ignored (bug 215800).
> 
> Rationale:
> 
> 1) This is required for benchmarking and proper temperature control. Boost
> frequencies are subject to multiple limitations (power in watts, amperage,
> voltage, temperature, BIOS limitations) and can change depending on the
> workload. Setting a low enough frequency allows to run benchmarks in the
> controlled environment and get proper data.
> 
> Windows allows to do that easily, see the attached screenshot.
> 
> 2) Disabling boost is an easy option to subdue operating temperatures though if
> the previous issue is tackled, it's not really needed.

For example, after compiling the kernel one needs to cool down system,
right?

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #2 from Bagas Sanjaya (bagasdotme@gmail.com) ---
On Wed, Sep 20, 2023 at 11:06:51AM +0000, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=217931
> 
>             Bug ID: 217931
>            Summary: amd-pstate lacks crucial features: CPU frequency and
>                     boost control
>            Product: Power Management
>            Version: 2.5
>           Hardware: AMD
>                 OS: Linux
>             Status: NEW
>           Severity: high
>           Priority: P3
>          Component: cpufreq
>           Assignee: linux-pm@vger.kernel.org
>           Reporter: aros@gmx.com
>         Regression: No
> 
> Created attachment 305131
>   --> https://bugzilla.kernel.org/attachment.cgi?id=305131&action=edit
> Power Options: Processor Power Management in Windows
> 
> It would be really great if amd-pstate had a feature parity with
> acpi-cpufreq,
> namely
> 
> 1) Being able to set operating frequencies (maximum, minimum and
> user-defined)

ondemand, conservative, performance?

> 
> 2) Being able to enable/disable boost

What is boost?

> 
> Currently both features are not available and frequency control is simply
> ignored (bug 215800).
> 
> Rationale:
> 
> 1) This is required for benchmarking and proper temperature control. Boost
> frequencies are subject to multiple limitations (power in watts, amperage,
> voltage, temperature, BIOS limitations) and can change depending on the
> workload. Setting a low enough frequency allows to run benchmarks in the
> controlled environment and get proper data.
> 
> Windows allows to do that easily, see the attached screenshot.
> 
> 2) Disabling boost is an easy option to subdue operating temperatures though
> if
> the previous issue is tackled, it's not really needed.

For example, after compiling the kernel one needs to cool down system,
right?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #3 from Artem S. Tashkinov (aros@gmx.com) ---
> ondemand, conservative, performance?

(Intel|AMD) CPU pstate drivers work differently and those are ignored:

https://www.kernel.org/doc/html/latest/admin-guide/pm/amd-pstate.html
https://www.kernel.org/doc/html/latest/admin-guide/pm/intel_pstate.html
https://wiki.archlinux.org/title/CPU_frequency_scaling

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

Perry Yuan(AMD) (Perry.Yuan@amd.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Perry.Yuan@amd.com

--- Comment #4 from Perry Yuan(AMD) (Perry.Yuan@amd.com) ---
(In reply to Artem S. Tashkinov from comment #0)
> Created attachment 305131 [details]
> Power Options: Processor Power Management in Windows
> 
> It would be really great if amd-pstate had a feature parity with
> acpi-cpufreq, namely
> 
> 1) Being able to set operating frequencies (maximum, minimum and
> user-defined)
> 
> 2) Being able to enable/disable boost
> 
> Currently both features are not available and frequency control is simply
> ignored (bug 215800).
> 
> Rationale:
> 
> 1) This is required for benchmarking and proper temperature control. Boost
> frequencies are subject to multiple limitations (power in watts, amperage,
> voltage, temperature, BIOS limitations) and can change depending on the
> workload. Setting a low enough frequency allows to run benchmarks in the
> controlled environment and get proper data.
> 
> Windows allows to do that easily, see the attached screenshot.
> 
> 2) Disabling boost is an easy option to subdue operating temperatures though
> if the previous issue is tackled, it's not really needed.

Thanks for the suggestion.
There are two modes for amd pstate driver, one passive, and another active
mode,  the passive mode already has the boost control feature.

# cat /sys/devices/system/cpu/cpufreq/boost
1

I have raised this requestion and will get active mode supported with a new
patch.

Perry.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #5 from Artem S. Tashkinov (aros@gmx.com) ---
(In reply to Perry Yuan(AMD) from comment #4)
> (In reply to Artem S. Tashkinov from comment #0)
> > Created attachment 305131 [details]
> > Power Options: Processor Power Management in Windows
> > 
> > It would be really great if amd-pstate had a feature parity with
> > acpi-cpufreq, namely
> > 
> > 1) Being able to set operating frequencies (maximum, minimum and
> > user-defined)
> > 
> > 2) Being able to enable/disable boost
> > 
> > Currently both features are not available and frequency control is simply
> > ignored (bug 215800).
> > 
> > Rationale:
> > 
> > 1) This is required for benchmarking and proper temperature control. Boost
> > frequencies are subject to multiple limitations (power in watts, amperage,
> > voltage, temperature, BIOS limitations) and can change depending on the
> > workload. Setting a low enough frequency allows to run benchmarks in the
> > controlled environment and get proper data.
> > 
> > Windows allows to do that easily, see the attached screenshot.
> > 
> > 2) Disabling boost is an easy option to subdue operating temperatures
> though
> > if the previous issue is tackled, it's not really needed.
> 
> Thanks for the suggestion.
> There are two modes for amd pstate driver, one passive, and another active
> mode,  the passive mode already has the boost control feature.
> 
> # cat /sys/devices/system/cpu/cpufreq/boost
> 1
> 
> I have raised this requestion and will get active mode supported with a new
> patch.
> 

Thank you for chiming in, Perry!

I'm looking forward to being able to control min/max frequency which kinda
negates the need for boost control. I know this can be done since the Windows
CPPC driver allows that perfectly.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #6 from Artem S. Tashkinov (aros@gmx.com) ---
This would also be hugely useful for hundreds of thousands of AMD handheld
users (not limited to Steam Deck).

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

hej@hot.ee changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hej@hot.ee

--- Comment #7 from hej@hot.ee ---
I'm also looking for a way to contol min/max frequency. I tried active, passive
and guided modes and was surprised none obeyed scaling_max_freq.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #8 from Artem S. Tashkinov (aros@gmx.com) ---
(In reply to hej from comment #7)
> I'm also looking for a way to contol min/max frequency. I tried active,
> passive and guided modes and was surprised none obeyed scaling_max_freq.

It's currently not implemented at all in amd-pstate, so those knobs
(scaling_max_freq|scaling_min_freq|scaling_setspeed) do nothing.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #9 from Artem S. Tashkinov (aros@gmx.com) ---
Mario, it would be great if AMD devoted some resources to adding these
features.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #10 from Perry Yuan(AMD) (Perry.Yuan@amd.com) ---
Hi Artem 

I have implemented the boost control for amd-pstate passive and active mode
driver, the patches are under reviewing, will sent out for testing once we
finish internal review procvess. 

Perry

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #11 from hej@hot.ee ---
Hi Perry, is it possible to also add scaling_max_freq support to amd-pstate?
I'd like to restrict max frequency on the cpu. Thanks.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #12 from Pedro (voidpointertonull+kernelorgbugzilla@gmail.com) ---
Got to test the new changes in 6.7 , and it does work, but max frequency
changes didn't really seem to apply well.
Initially I figured that changes were just not deterministic, but later I
successfully figured that the first change (after boot?) just doesn't take
effect, and then setting the same value also doesn't make any change, so
setting a higher then desired value, then setting the desired value does the
trick.

According to htop reported values, the frequency still exceeds the maximum, but
based on both power consumption and performance, the max frequency setting does
something after all, I'm just not really sure how reliable it is, but it's neat
to have something.

Almost forgot to report here as planned, but coincidentally I needed to use
CUDA, and totally fortunately Nvidia doesn't feel like supporting the latest
kernel yet, so I'm back on 6.5 and I get to enjoy the heat again with long
running test which reminded me of this bug report.

So generally recommending updating to 6.7 if this feature is really desired.
I'm surely missing it, the stupid high frequency by default is okay for bursty
tasks, but it's definitely great to be able to restrict it on demand.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #13 from Perry Yuan(AMD) (Perry.Yuan@amd.com) ---
Hello,

Thank you for reaching out. I am currently in OOO until 12/29
response will be delayed.

Best regards,
Perry Yuan

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #14 from Pedro (voidpointertonull+kernelorgbugzilla@gmail.com) ---
Got back to a more recent kernel and found out that apparently the issue is
sillier than expected.
It's not the first change that's failing, but when setting a new frequency
limit, the previous limit gets applied instead.

So for example after a fresh boot:
- Set 4.0 GHz -> Nothing changes
- Set 4.5 GHz -> 4.0 GHz limit gets applied
- Set 4.3 GHz -> 4.5 GHz limit gets applied
- Set 4.3 GHz -> Nothing changes because it's already supposed to be 4.3 GHz
- Set 4.2 GHz -> 4.3 GHz limit gets applied

Way better than nothing, but it's surely odd this way.
Good to know its quirk though, earlier I just thought it was simply not really
reliable, but explicitly working around its silly issue makes it useful.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

AlexDeLorenzo.dev (alex.delorenzo@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alex.delorenzo@gmail.com

--- Comment #15 from AlexDeLorenzo.dev (alex.delorenzo@gmail.com) ---
Can confirm the same behavior Pedro experienced with 6.7.0. Definitely is odd. 

One way I've reliably found to set a max frequency is to first set the
frequency you desire, and then set the max frequency to a value that is either
lower than the minimum, or higher than the maximum, supported frequencies.

Seemingly related, but as of 6.7.0, the system sometimes gets stuck at its
lowest supported frequency, requiring a manual increase to the maximum
frequency that involves the process I described above. It's the issue that led
down this rabbit hole originally.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #16 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
When you say getting stuck in lowest supported frequency does it resemble bug
218305 perhaps?

What is your CPU scaling governor when it happened?  And does it only happen
with suspend/resume or only with reboot?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #17 from Artem S. Tashkinov (aros@gmx.com) ---
> When you say getting stuck in lowest supported frequency does it resemble bug
> 218305 perhaps?

It's the same bug I've just refiled it.

> What is your CPU scaling governor when it happened?  And does it only happen
> with suspend/resume or only with reboot?

cpupower frequency-info
analyzing CPU 4:
  driver: amd-pstate-epp
  CPUs which run at the same hardware frequency: 4
  CPUs which need to have their frequency coordinated by software: 4
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 400 MHz - 5.61 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 5.61 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 1.40 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
    AMD PSTATE Highest Performance: 214. Maximum Frequency: 5.61 GHz.
    AMD PSTATE Nominal Performance: 145. Nominal Frequency: 3.80 GHz.
    AMD PSTATE Lowest Non-linear Performance: 42. Lowest Non-linear Frequency:
1.10 GHz.
    AMD PSTATE Lowest Performance: 16. Lowest Frequency: 400 MHz.

It happens both with amd-pstate-epp and acpi-cpufreq.

It only happens after a random number of suspend/resume cycles (as low as one,
as high as three or four). Rebooting/power cycling always fixes the issue.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #18 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
I was meaning #14/#15.  I want to see if they're finding the same thing as you.
 Looking for a pattern.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #19 from Artem S. Tashkinov (aros@gmx.com) ---
(In reply to Mario Limonciello (AMD) from comment #18)
> I was meaning #14/#15.  I want to see if they're finding the same thing as
> you.  Looking for a pattern.

The amd-pstate driver doesn't allow to set any frequency limits, so I'm not
sure how people here have achieved this.

And I'm not using acpi-cpufreq any longer. I like amd-pstate more since it
shows CPU cores frequency better/more precisely.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #20 from Pedro (voidpointertonull+kernelorgbugzilla@gmail.com) ---
Haven't seen any other issue than the one I described earlier, but then I also
haven't experimented a whole lot, just wanted to figure out what gets me a
reliable frequency cap I can adjust at will, and I have that in the scripted
form of:
- Set [target] freq
- Safety sleep
- Set [target + 1] freq
That never failed to set [target] frequency so far.
The sleep part should be optional, but then the whole script shouldn't be
required as a starter, so I just chose to fight bugs with hacks.

> The amd-pstate driver doesn't allow to set any frequency limits, so I'm not
> sure how people here have achieved this.

Are you using a recent enough kernel as discussed earlier?
It's quite unlikely to have that by just using a distribution provided stock
kernel.

Once the kernel version is recent enough, it's as easy as running something
like the following as root:
`echo 3000000 | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq`
Just keep in mind the mentioned issue of the current limit always being what
was requested previously.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #21 from Artem S. Tashkinov (aros@gmx.com) ---
I did

echo 3000000 | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
3000000

on Linux 6.6.x and it did exactly nothing.

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
3000000
3000000
3000000
3000000
3000000
3000000
3000000
3000000
3000000
3000000
3000000
3000000
3000000
3000000
3000000
3000000

Cores continue to hit their respective max frequencies all the time.

Fedora hasn't yet published Linux 6.7.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #22 from Mark Haun (haunma@keteu.org) ---
I repeated Artem's test on 6.7.0-rc6 (Void Linux with custom kernel---a bit
old, sorry).  My energy performance preference is set to "power".  I think I am
seeing roughly what Pedro describes.  Writing twice to scaling_max_freq is
definitely doing something, at least if we believe the numbers reported by htop
or cpupower.  Usually I cannot keep all of my cores (7840U) at 400 MHz; the
active ones are habitually between 1-3 GHz.  After following the above recipe,
the active cores seem limited to ~544 MHz instead.

(Although, since the amd-pstate-epp driver reputedly does not allow setting
limits at all, I suppose we should consider the possibility that these reported
numbers are incorrect ;)

It would sure be nice to have the non-determinism (i.e. bugs) ironed out of the
driver first, then consider supporting scaling_max_frequency.  I am actually
open to the idea---in principle---that the EPP stuff obsoletes max_frequency,
but I have to say, the entire scale is still biased too far towards
performance.  There ought to be a way for the user to basically tell the system
"POWER POWER POWER above all, and I really mean it!!" but as it stands, the
furthest that we are allowed to push things is still fairly weak:  any core
with the slightest activity is immediately boosted way up, so even an "idle"
system constantly has a few cores way above idle speed.  This might be why
folks are asking for a frequency cap.  Why isn't EPP more of a logarithmic
scale, where both ends of the scale are so ridiculously overkill that most
people will want a setting closer to the middle?  *That* is how it should be
designed.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #23 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
6.7-rc4 was /supposed/ to fix the kind of bug that Pedro described.  See this
commit.
https://github.com/torvalds/linux/commit/febab20caebac959fdc3d7520bc52de8b1184455

There must be another problem though; I wonder if something isn't getting
flushed out still.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #24 from Mark Haun (haunma@keteu.org) ---
I'll try to update to 6.7.0 or 6.7.1 this weekend and see how/if the behavior
changes on my system.  Do I read that commit correctly, that
scaling_max_frequency *is* supposed to cap the CPU frequencies, in the latest
kernels?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #25 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
Writing scaling_max_freq updates the cpufreq policy (see store_##file_name). 
That function through a series of events (see freq_qos_update_request()) is
supposed to be calling into amd-pstate to flush it out to hardware.

For passive/guided mode it uses .target() callback for amd-pstate.  For active
mode it uses ,setpolicy() callback for amd-pstate-epp.

Can you guys try turning on the dynamic debugging for amd-pstate?  It has a
debug line that will confirm when policies are flushed from the core into the
driver.

        pr_debug("set_policy: cpuinfo.max %u policy->max %u\n",
                                policy->cpuinfo.max_freq, policy->max);

That can help give a hint if this is a core or driver issue that it's not
working immediately.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #26 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
I tried on a Phoenix system myself, and I can reproduce what I think is the
same issue here.  I did experiment with writing MSR_AMD_CPPC_ENABLE after
writing MSR_AMD_CPPC_REQ to force the request but it didn't work.

I'll talk to some people offline about it.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #27 from AlexDeLorenzo.dev (alex.delorenzo@gmail.com) ---
(In reply to Mario Limonciello (AMD) from comment #16)
> When you say getting stuck in lowest supported frequency does it resemble
> bug 218305 perhaps?

Looking at bug 218305, I haven't noticed if the issue is triggered by
suspend/resume or restart cycles. I'm on a laptop that regularly goes through
several days of use before being rebooted, so it's possible. I'll keep an eye
out to see if that's related. From what I experienced, the issue would occur
while using the machine for a few hours, and the issue would "fix" itself upon
a suspend/resume or restart.

As far as similarities to bug 218305, I'm also running a Ryzen APU (on Zen 3
and not 4) on an HP Dev One, which I believe is a modified Elitebook 845 G8 or
G9. However, I've been told by HP support and the System76 team they outsourced
the project to that the firmware on the Dev One was custom written for the
project and unrelated to the standard Elitebook line's firmware.

I also use `ryzenadj` to set STAPM, PPT FAST and SLOW limits. Like in bug
218305, I also leave my laptop plugged in the majority of the time.

When I experience the issue again, I'll look at more diagnostics to see if it's
like bug 218305. 

> What is your CPU scaling governor when it happened? 

I use the amd-pstate-epp driver in active mode, and alternate between the
powersave and performance governors depending on whether I'm on battery power
or not, and delegate that switch to power-profiles-daemon versus using sysfs.

It's happened while on AC power, so it is likely I was using the performance
governor when I experienced the issue.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #28 from AlexDeLorenzo.dev (alex.delorenzo@gmail.com) ---
Created attachment 305727
  --> https://bugzilla.kernel.org/attachment.cgi?id=305727&action=edit
sysfs, ryzenadj and cpupower output

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #29 from AlexDeLorenzo.dev (alex.delorenzo@gmail.com) ---
It happened again ~90min after doing a `systemctl kexec` and using `ryzenadj`,
so I can better answer your questions.

(In reply to Mario Limonciello (AMD) from comment #16)
> When you say getting stuck in lowest supported frequency does it resemble
> bug 218305 perhaps?

It seems to differ from bug 218305 in that the values `ryzenadj -i` returns
seem sane on my machine, whereas in the other bug report they weren't. I'm also
getting the correct reporting for the maximum supported frequency for all of my
cores.

I can't say what triggers it, but I've noticed it most when using the machine
for a couple of hours, sometimes while using the processor moderately but not
excessively. 

> What is your CPU scaling governor when it happened?  And does it only happen
> with suspend/resume or only with reboot?

This time it happened with the performance governor. 

I added an attachment with the output of ryzenadj, cpupower and sysfs taken
while the machine was stuck at 400MHz

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #30 from Pedro (voidpointertonull+kernelorgbugzilla@gmail.com) ---
(In reply to Mario Limonciello (AMD) from comment #23)
> 6.7-rc4 was /supposed/ to fix the kind of bug that Pedro described.  See
> this commit.
> https://github.com/torvalds/linux/commit/
> febab20caebac959fdc3d7520bc52de8b1184455
> 
> There must be another problem though; I wonder if something isn't getting
> flushed out still.

Figured that was for getting the functionality working at all.
There are only 3 relevant commits in 2 days, and one from that is only a visual
change. Before those the functionality simply just didn't work at all, and
after those apparently the silly behavior described is easy to reproduce.

(In reply to AlexDeLorenzo.dev from comment #29)
> It happened again ~90min after doing a `systemctl kexec` and using
> `ryzenadj`, so I can better answer your questions.

Apparently ryzenadj directly communicates with the SMU without using an in-tree
kernel module to use an interface blessed by AMD, so that's highly unlikely to
get support from them.

Recommending reproducing the issue without using that at all first, it's going
to keep on getting the blame until it's proven not to interfere.

Do you happen to know such tools for Raphael (7000 series, Zen 4 based
desktop)?
Investigating silly memory and/or IMC issues, was happy to see ryzen_smu
reporting a whole lot of relevant info, but then it turned out to be abandoned,
and forks claiming to support Raphael don't seem to target my root complex
(PCI_DEVICE_ID_AMD_19H_M60H_ROOT).
Worst case I'll make a Windows setup and check the tools there, just hoped to
be able to avoid that. I hate BIOS "Auto" settings with a passion not even
showing current values, and the CPU's memory controller seems to be quite
finicky.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #31 from Pedro (voidpointertonull+kernelorgbugzilla@gmail.com) ---
Not sure if related, but apparently a bug was introduced back in November which
could cause the CPU to be stuck at the lowest frequency, and it was fixed
recently:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b0d326da462e20285236e11e4cbc32085de9f363

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #32 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
> Apparently ryzenadj directly communicates with the SMU without using an
> in-tree kernel module to use an interface blessed by AMD, so that's highly
> unlikely to get support from them.
> Recommending reproducing the issue without using that at all first, it's
> going to keep on getting the blame until it's proven not to interfere.

Yes please do it without *anything* abusing that mailbox at all during the boot
(like ryzenadj or ryzen_smu).  It's entirely possible that another piece of
firmware fights over the same interfaces or data structures and that's part of
a problem.

It's also possible that attempts to read information using that tool
unintentionally causes information to also be written (as it's a reverse
engineered tool that uses an undocumented engineering interface anything is
possible)

The simpler the reproduce the better.

As I mentioned in the other issue, to rule out a kernel bug we may want to look
at the output of these MSRs while the issue happened.  If those are correct for
what has been programmed to scaling_max_freq, then we may be dealing with a
firmware bug.

#define MSR_AMD_CPPC_CAP1               0xc00102b0
#define MSR_AMD_CPPC_ENABLE             0xc00102b1
#define MSR_AMD_CPPC_CAP2               0xc00102b2
#define MSR_AMD_CPPC_REQ                0xc00102b3
#define MSR_AMD_CPPC_STATUS             0xc00102b4

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #33 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
Can you please try this patch?

diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
index 1f6186475715..935376d8861d 100644
--- a/drivers/cpufreq/amd-pstate.c
+++ b/drivers/cpufreq/amd-pstate.c
@@ -1233,9 +1233,9 @@ static void amd_pstate_epp_update_limit(struct
cpufreq_policy *policy)
        min_limit_perf = div_u64(policy->min * cpudata->highest_perf,
cpudata->max_freq);

        max_perf = clamp_t(unsigned long, max_perf, cpudata->min_limit_perf,
-                       cpudata->max_limit_perf);
+                       max_limit_perf);
        min_perf = clamp_t(unsigned long, min_perf, cpudata->min_limit_perf,
-                       cpudata->max_limit_perf);
+                       min_limit_perf);

        WRITE_ONCE(cpudata->max_limit_perf, max_limit_perf);
        WRITE_ONCE(cpudata->min_limit_perf, min_limit_perf);

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #34 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
Can you guys please test this:

https://lore.kernel.org/linux-pm/20240119113319.54158-1-mario.limonciello@amd.com/T/#u

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #35 from Pedro (voidpointertonull+kernelorgbugzilla@gmail.com) ---
Bah, tried to test #33 first based on emails, but found out the hard way that
deb packaged kernel installation stopped properly replacing the previous kernel
at some point so I was testing nothing, and the comment is gone anyway.

(In reply to Mario Limonciello (AMD) from comment #34)
> Can you guys please test this:
> 
> https://lore.kernel.org/linux-pm/20240119113319.54158-1-mario.
> limonciello@amd.com/T/#u

This one seems to be a winner, the frequency limit seems to be updated
correctly after applying the changes (by hand).

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #36 from AlexDeLorenzo.dev (alex.delorenzo@gmail.com) ---
(In reply to Pedro from comment #30)
> Recommending reproducing the issue without using that at all first, it's
> going to keep on getting the blame until it's proven not to interfere.

So I shutdown the PC and started it, disabled any scripts that might trigger
`ryzenadj` beforehand. There were no suspend/resume cycles since booting.

About 4 hours later, the CPU was stuck at 400MHz.


(In reply to Mario Limonciello (AMD) from comment #32)
> As I mentioned in the other issue, to rule out a kernel bug we may want to
> look at the output of these MSRs while the issue happened.  If those are
> correct for what has been programmed to scaling_max_freq, then we may be
> dealing with a firmware bug.
> 
> #define MSR_AMD_CPPC_CAP1             0xc00102b0
> #define MSR_AMD_CPPC_ENABLE           0xc00102b1
> #define MSR_AMD_CPPC_CAP2             0xc00102b2
> #define MSR_AMD_CPPC_REQ              0xc00102b3
> #define MSR_AMD_CPPC_STATUS           0xc00102b4

MSRs before:

    0xc00102b0:  ba46290fba46290f
    0xc00102b1:  1
    0xc00102b2:  0
    0xc00102b3:  a6a6
    0xc00102b4:  0

MSRs while forced underclock:

    0xc00102b0:  ba46290fba46290f
    0xc00102b1:  1
    0xc00102b2:  0
    0xc00102b3:  e0e
    0xc00102b4:  0


(In reply to Mario Limonciello (AMD) from comment #34)
> Can you guys please test this:
> 
> https://lore.kernel.org/linux-pm/20240119113319.54158-1-mario.
> limonciello@amd.com/T/#u

I'll give this a go.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #37 from AlexDeLorenzo.dev (alex.delorenzo@gmail.com) ---
(In reply to Mario Limonciello (AMD) from comment #34)
> Can you guys please test this:
> 
> https://lore.kernel.org/linux-pm/20240119113319.54158-1-mario.
> limonciello@amd.com/T/#u

I applied the amd-pstate patch to 6.7.0, and have been running it for the day
without problems. There were several suspend/resume cycles in that time.
Haven't used ryzenadj or rebooted.

Before the patch, I would experience the issue within a few hours.

After waiting ~20 hours, I tried using cpupower to set the maximum frequency
and was successful. Didn't have to do it twice.

The patch seems to be the fix.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #38 from AlexDeLorenzo.dev (alex.delorenzo@gmail.com) ---
It's been ~2 days and haven't run into this issue once while using the patch.
I've also used ryzenadj without issue during that time. 


Pretty sure it's the fix to this issue entirely.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #39 from Perry Yuan(AMD) (Perry.Yuan@amd.com) ---
Hi all,

The new boost control patches are under reviewing now.

https://lore.kernel.org/lkml/cover.1706255676.git.perry.yuan@amd.com/

It will be great if anyone would like help to test this on your system if you
are interested in this feature. 


Perry.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

Sjoer van der Ploeg (sfjuocekr@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sfjuocekr@gmail.com

--- Comment #40 from Sjoer van der Ploeg (sfjuocekr@gmail.com) ---
Could this be the reason why some CPU's do not boost to their maximum
frequency, while they are happy to do so on Windows?

For example my 5800X3D never reaches 4550 on Linux, but on Windows it seems to
have no problem getting there.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #41 from Perry Yuan(AMD) (Perry.Yuan@amd.com) ---
(In reply to Sjoer van der Ploeg from comment #40)
> Could this be the reason why some CPU's do not boost to their maximum
> frequency, while they are happy to do so on Windows?
> 
> For example my 5800X3D never reaches 4550 on Linux, but on Windows it seems
> to have no problem getting there.

Could you share the output with below commands? then I can check that.

echo "=============norminal freq==============================="
cat /sys/devices/system/cpu/cpu*/acpi_cppc/nominal_freq

echo "=============norminal perf==============================="
cat /sys/devices/system/cpu/cpu*/acpi_cppc/nominal_perf

echo "=============highest_perf perf==============================="
cat /sys/devices/system/cpu/cpu*/acpi_cppc/highest_perf

echo "=============lowest_nonlinear_perf perf==============================="
cat /sys/devices/system/cpu/cpu*/acpi_cppc/lowest_nonlinear_perf

echo "=============lowest perf==============================="
cat /sys/devices/system/cpu/cpu*/acpi_cppc/lowest_perf

echo "=============lowest freq==============================="
cat /sys/devices/system/cpu/cpu*/acpi_cppc/lowest_freq

Perry.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #42 from Artem S. Tashkinov (aros@gmx.com) ---
So, how does setting the maximum frequency work?

Running 6.7.3 here, Ryzen 7 5800X.

$ grep . /sys/devices/system/cpu/cpu0/cpufreq/*
/sys/devices/system/cpu/cpu0/cpufreq/affected_cpus:0
/sys/devices/system/cpu/cpu0/cpufreq/amd_pstate_highest_perf:166
/sys/devices/system/cpu/cpu0/cpufreq/amd_pstate_lowest_nonlinear_freq:1752000
/sys/devices/system/cpu/cpu0/cpufreq/amd_pstate_max_freq:4929000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:4929000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:550000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency:0
/sys/devices/system/cpu/cpu0/cpufreq/energy_performance_available_preferences:default
performance balance_performance balance_power power 
/sys/devices/system/cpu/cpu0/cpufreq/energy_performance_preference:performance
/sys/devices/system/cpu/cpu0/cpufreq/related_cpus:0
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors:performance
powersave
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:550000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:amd-pstate-epp
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:powersave
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:4000000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:550000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed:<unsupported>

The CPU happily runs at its maximum frequency despite scaling_max_freq=4000000.

# echo 4000000 > amd_pstate_max_freq
bash: amd_pstate_max_freq: Permission denied

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #43 from Artem S. Tashkinov (aros@gmx.com) ---
Lastly, this looks wrong:

# cat /sys/devices/system/cpu/cpu*/cpufreq/amd_pstate_max_freq
4929000
4929000
4929000
4929000
4929000
4929000
4929000
4929000
4929000
4929000
4929000
4929000
4929000
4929000
4929000
4929000

This CPU cores boost to _different_ frequencies.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #44 from Perry Yuan(AMD) (Perry.Yuan@amd.com) ---
cpufreq_freq_attr_ro(amd_pstate_max_freq);

the sysfs entry is ready only, so it is not allowing to write the new max freq
value to it.

you can try to limit the freq with scaling_max_freq and scaling_min_freq.

The boost patches and scaling_max_freq support are not same topics, if the
boost patches can work, however scaling_max_freq is not working, we can file a
new ticket to track that problem.

Perry.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #45 from Perry Yuan(AMD) (Perry.Yuan@amd.com) ---
/sys/devices/system/cpu/cpu0/cpufreq$ ll
total 0
drwxr-xr-x  2 root root    0 Jan 11 00:41 ./
drwxr-xr-x 26 root root    0 Jan 11 00:41 ../
-r--r--r--  1 root root 4096 Feb  1 03:54 affected_cpus
-r--r--r--  1 root root 4096 Feb  1 03:54 amd_pstate_highest_perf
-r--r--r--  1 root root 4096 Feb  1 03:54 amd_pstate_lowest_nonlinear_freq
-r--r--r--  1 root root 4096 Feb  1 03:54 amd_pstate_max_freq
-r--r--r--  1 root root 4096 Jan 11 00:41 cpuinfo_max_freq
-r--r--r--  1 root root 4096 Jan 11 00:41 cpuinfo_min_freq
-r--r--r--  1 root root 4096 Feb  1 03:54 cpuinfo_transition_latency
-r--r--r--  1 root root 4096 Feb  1 03:54
energy_performance_available_preferences
-rw-r--r--  1 root root 4096 Feb  1 03:54 energy_performance_preference
-r--r--r--  1 root root 4096 Feb  1 03:54 related_cpus
-r--r--r--  1 root root 4096 Feb  1 03:54 scaling_available_governors
-r--r--r--  1 root root 4096 Feb  1 03:54 scaling_cur_freq
-r--r--r--  1 root root 4096 Jan 15 01:16 scaling_driver
-rw-r--r--  1 root root 4096 Feb  1 03:54 scaling_governor
-rw-r--r--  1 root root 4096 Feb  1 03:54 scaling_max_freq
-rw-r--r--  1 root root 4096 Feb  1 03:54 scaling_min_freq
-rw-r--r--  1 root root 4096 Feb  1 03:54 scaling_setspeed

You can see, only the last three entries are allowed to write new values.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #46 from Artem S. Tashkinov (aros@gmx.com) ---
(In reply to Perry Yuan(AMD) from comment #44)
> cpufreq_freq_attr_ro(amd_pstate_max_freq);
> 
> the sysfs entry is ready only, so it is not allowing to write the new max
> freq value to it.
> 
> you can try to limit the freq with scaling_max_freq and scaling_min_freq.

Exactly what I did, I set scaling_max_freq for all cores to 4GHz (4000000) - it
had zero effect.

> 
> The boost patches and scaling_max_freq support are not same topics, if the
> boost patches can work, however scaling_max_freq is not working, we can file
> a new ticket to track that problem.
>

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #47 from Perry Yuan(AMD) (Perry.Yuan@amd.com) ---
[AMD Official Use Only - General]

thanks for confirming this, we will take a look the issue and get a fix for the
max,min scaling set function.

Perry.

获取 Outlook for iOS<https://aka.ms/o0ukef>
________________________________
发件人: bugzilla-daemon@kernel.org <bugzilla-daemon@kernel.org>
发送时间: Thursday, February 1, 2024 5:58:58 PM
收件人: Yuan, Perry <Perry.Yuan@amd.com>
主题: [Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost
control

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #46 from Artem S. Tashkinov (aros@gmx.com) ---
(In reply to Perry Yuan(AMD) from comment #44)
> cpufreq_freq_attr_ro(amd_pstate_max_freq);
>
> the sysfs entry is ready only, so it is not allowing to write the new max
> freq value to it.
>
> you can try to limit the freq with scaling_max_freq and scaling_min_freq.

Exactly what I did, I set scaling_max_freq for all cores to 4GHz (4000000) - it
had zero effect.

>
> The boost patches and scaling_max_freq support are not same topics, if the
> boost patches can work, however scaling_max_freq is not working, we can file
> a new ticket to track that problem.
>

--
You may reply to this email to add a comment.

You are receiving this mail because:
You are on the CC list for the bug.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #48 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
Did you pick up
https://lore.kernel.org/linux-pm/20240119113319.54158-1-mario.limonciello@amd.com/T/#u
?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #49 from Artem S. Tashkinov (aros@gmx.com) ---
(In reply to Mario Limonciello (AMD) from comment #48)
> Did you pick up
> https://lore.kernel.org/linux-pm/20240119113319.54158-1-mario.
> limonciello@amd.com/T/#u ?

I'm running 6.7.3 which ostensibly includes it:

commit c794cc65bb3eef3142bbecd48f1fd43f1fa8d478
Author: Mario Limonciello
Date:   Fri Jan 19 05:33:19 2024 -0600

    cpufreq/amd-pstate: Fix setting scaling max/min freq values

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #50 from Artem S. Tashkinov (aros@gmx.com) ---
And just in case:

$ cat /sys/devices/system/cpu/amd_pstate/status
active

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #51 from Perry Yuan(AMD) (Perry.Yuan@amd.com) ---
(In reply to Artem S. Tashkinov from comment #50)
> And just in case:
> 
> $ cat /sys/devices/system/cpu/amd_pstate/status
> active

Got it, thanks for the info. 
We will get the scaling_max/min fixed with other patches.
This ticket is focusing on the boost control feature.

Perry.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #52 from Sjoer van der Ploeg (sfjuocekr@gmail.com) ---
(In reply to Perry Yuan(AMD) from comment #41)
> (In reply to Sjoer van der Ploeg from comment #40)
> > Could this be the reason why some CPU's do not boost to their maximum
> > frequency, while they are happy to do so on Windows?
> > 
> > For example my 5800X3D never reaches 4550 on Linux, but on Windows it seems
> > to have no problem getting there.
> 
> Could you share the output with below commands? then I can check that.
> 
> echo "=============norminal freq==============================="
> cat /sys/devices/system/cpu/cpu*/acpi_cppc/nominal_freq
> 
> echo "=============norminal perf==============================="
> cat /sys/devices/system/cpu/cpu*/acpi_cppc/nominal_perf
> 
> echo "=============highest_perf perf==============================="
> cat /sys/devices/system/cpu/cpu*/acpi_cppc/highest_perf
> 
> echo "=============lowest_nonlinear_perf perf==============================="
> cat /sys/devices/system/cpu/cpu*/acpi_cppc/lowest_nonlinear_perf
> 
> echo "=============lowest perf==============================="
> cat /sys/devices/system/cpu/cpu*/acpi_cppc/lowest_perf
> 
> echo "=============lowest freq==============================="
> cat /sys/devices/system/cpu/cpu*/acpi_cppc/lowest_freq
> 
> Perry.

=============nominal freq===============================
3401
=============nominal perf===============================
124
=============highest_perf perf===============================
196
171
196
166
186
181
191
176
171
196
166
186
181
191
196
176
=============lowest_nonlinear_perf perf===============================
64
=============lowest perf===============================
21
=============lowest freq===============================
550

Only removed repeating values

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #53 from Perry Yuan(AMD) (Perry.Yuan@amd.com) ---
(In reply to Sjoer van der Ploeg from comment #52)
> (In reply to Perry Yuan(AMD) from comment #41)
> > (In reply to Sjoer van der Ploeg from comment #40)
> > > Could this be the reason why some CPU's do not boost to their maximum
> > > frequency, while they are happy to do so on Windows?
> > > 
> > > For example my 5800X3D never reaches 4550 on Linux, but on Windows it
> seems
> > > to have no problem getting there.
> > 
> > Could you share the output with below commands? then I can check that.
> > 
> > echo "=============norminal freq==============================="
> > cat /sys/devices/system/cpu/cpu*/acpi_cppc/nominal_freq
> > 
> > echo "=============norminal perf==============================="
> > cat /sys/devices/system/cpu/cpu*/acpi_cppc/nominal_perf
> > 
> > echo "=============highest_perf perf==============================="
> > cat /sys/devices/system/cpu/cpu*/acpi_cppc/highest_perf
> > 
> > echo "=============lowest_nonlinear_perf
> perf==============================="
> > cat /sys/devices/system/cpu/cpu*/acpi_cppc/lowest_nonlinear_perf
> > 
> > echo "=============lowest perf==============================="
> > cat /sys/devices/system/cpu/cpu*/acpi_cppc/lowest_perf
> > 
> > echo "=============lowest freq==============================="
> > cat /sys/devices/system/cpu/cpu*/acpi_cppc/lowest_freq
> > 
> > Perry.
> 
> =============nominal freq===============================
> 3401
> =============nominal perf===============================
> 124
> =============highest_perf perf===============================
> 196
> 171
> 196
> 166
> 186
> 181
> 191
> 176
> 171
> 196
> 166
> 186
> 181
> 191
> 196
> 176
> =============lowest_nonlinear_perf perf===============================
> 64
> =============lowest perf===============================
> 21
> =============lowest freq===============================
> 550
> 
> Only removed repeating values

How about the output of "lscpu -ae"?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #54 from Sjoer van der Ploeg (sfjuocekr@gmail.com) ---
(In reply to Perry Yuan(AMD) from comment #53)
> How about the output of "lscpu -ae"?

Sorry for the late reply:

CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE    MAXMHZ   MINMHZ       MHZ
  0    0      0    0 0:0:0:0          yes 4550.0000 550.0000 3569.5090
  1    0      0    1 1:1:1:0          yes 4550.0000 550.0000 3552.6860
  2    0      0    2 2:2:2:0          yes 4550.0000 550.0000 3559.3779
  3    0      0    3 3:3:3:0          yes 4550.0000 550.0000 3854.7759
  4    0      0    4 4:4:4:0          yes 4550.0000 550.0000 3590.6599
  5    0      0    5 5:5:5:0          yes 4550.0000 550.0000 3552.8989
  6    0      0    6 6:6:6:0          yes 4550.0000 550.0000 3840.7690
  7    0      0    7 7:7:7:0          yes 4550.0000 550.0000 3584.2910
  8    0      0    0 0:0:0:0          yes 4550.0000 550.0000 3546.3811
  9    0      0    1 1:1:1:0          yes 4550.0000 550.0000 3551.5229
 10    0      0    2 2:2:2:0          yes 4550.0000 550.0000 3591.2500
 11    0      0    3 3:3:3:0          yes 4550.0000 550.0000 3594.0801
 12    0      0    4 4:4:4:0          yes 4550.0000 550.0000 3552.0400
 13    0      0    5 5:5:5:0          yes 4550.0000 550.0000 3572.1050
 14    0      0    6 6:6:6:0          yes 4550.0000 550.0000 4124.7349
 15    0      0    7 7:7:7:0          yes 4550.0000 550.0000 3583.7170

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #55 from Perry Yuan(AMD) (Perry.Yuan@amd.com) ---
(In reply to Sjoer van der Ploeg from comment #54)
> (In reply to Perry Yuan(AMD) from comment #53)
> > How about the output of "lscpu -ae"?
> 
> Sorry for the late reply:
> 
> CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE    MAXMHZ   MINMHZ       MHZ
>   0    0      0    0 0:0:0:0          yes 4550.0000 550.0000 3569.5090
>   1    0      0    1 1:1:1:0          yes 4550.0000 550.0000 3552.6860
>   2    0      0    2 2:2:2:0          yes 4550.0000 550.0000 3559.3779
>   3    0      0    3 3:3:3:0          yes 4550.0000 550.0000 3854.7759
>   4    0      0    4 4:4:4:0          yes 4550.0000 550.0000 3590.6599
>   5    0      0    5 5:5:5:0          yes 4550.0000 550.0000 3552.8989
>   6    0      0    6 6:6:6:0          yes 4550.0000 550.0000 3840.7690
>   7    0      0    7 7:7:7:0          yes 4550.0000 550.0000 3584.2910
>   8    0      0    0 0:0:0:0          yes 4550.0000 550.0000 3546.3811
>   9    0      0    1 1:1:1:0          yes 4550.0000 550.0000 3551.5229
>  10    0      0    2 2:2:2:0          yes 4550.0000 550.0000 3591.2500
>  11    0      0    3 3:3:3:0          yes 4550.0000 550.0000 3594.0801
>  12    0      0    4 4:4:4:0          yes 4550.0000 550.0000 3552.0400
>  13    0      0    5 5:5:5:0          yes 4550.0000 550.0000 3572.1050
>  14    0      0    6 6:6:6:0          yes 4550.0000 550.0000 4124.7349
>  15    0      0    7 7:7:7:0          yes 4550.0000 550.0000 3583.7170

The max frequency value is correct to be 4.55GHZ on your system by the CPPC
capabilities reported by your firmware.
4.55GHZ is boost frequency which cannot maintain long time, it can try EPP mode
& performance profile, and run some lighter workload, the freq will be reaching
to max freq. 

>  14    0      0    6 6:6:6:0          yes 4550.0000 550.0000 4124.7349

seeing from this, the freq is close to 4.5GHz, please try the EPP and
performance profile on your system. 
then check the lscpu -ae output to confirm if it can reach 4.5GHz as well.

Perry.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #56 from Artem S. Tashkinov (aros@gmx.com) ---
Here's my report for 6.8.4 and Ryzen 7 7840HS:

1. Setting scaling_max_freq works, cool, but you cannot go below 544MHz. You
can set 400MHz but the CPU will continue to jump to 544MHz, not a big deal.

2. Setting scaling_min_freq sort of works, the CPU _prefers_ to stay at this
specified frequency but occasionally drops to 400MHz. Then, the CPU doesn't
totally respect it, i.e. for values below 1.4GHz it stays around 1397MHz. The
relationship is not linear, setting 4GHz results in the CPU preferring 3766Mhz.
Or 2GHz -> 1982MHz. Not a big deal. Unlikely anyone would want to set the
lowest frequency.

3. /sys/devices/system/cpu/amd_pstate/cpb_boost is missing altogether:

# find /sys -iname '*boost*'
[nothing]

So, my only remaining question is where's boost support? Or it's not supported
for all Zen CPUs?

Thanks a lot for your work regardless!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #57 from Perry Yuan(AMD) (Perry.Yuan@amd.com) ---

Hello,

Thank you for your message. I am currently out of the office from afternoon
today to 4/8 for Chinese QingMing Festival. response will be delayed.


Best wishes,
Perry Yuan

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #58 from Artem S. Tashkinov (aros@gmx.com) ---
Thank you, Perry, there's no rush!

Not the last question, here's one more, I wrote about it earlier.

cpuinfo_max_freq is invalid for multiple cores here as it often reports insane
values:

$ lscpu -ae
CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE    MAXMHZ   MINMHZ       MHZ
  0    0      0    0 0:0:0:0          yes 5137.0000 400.0000  400.0000
  1    0      0    0 0:0:0:0          yes 5137.0000 400.0000 1394.3910
  2    0      0    1 1:1:1:0          yes 6080.0000 400.0000  400.0000
  3    0      0    1 1:1:1:0          yes 6080.0000 400.0000  400.0000
  4    0      0    2 2:2:2:0          yes 5608.0000 400.0000 1396.2390
  5    0      0    2 2:2:2:0          yes 5608.0000 400.0000  400.0000
  6    0      0    3 3:3:3:0          yes 5293.0000 400.0000  400.0000
  7    0      0    3 3:3:3:0          yes 5293.0000 400.0000  400.0000
  8    0      0    4 4:4:4:0          yes 5449.0000 400.0000 1381.5620
  9    0      0    4 4:4:4:0          yes 5449.0000 400.0000 1393.0980
 10    0      0    5 5:5:5:0          yes 6080.0000 400.0000 1383.3900
 11    0      0    5 5:5:5:0          yes 6080.0000 400.0000 1397.3979
 12    0      0    6 6:6:6:0          yes 5764.0000 400.0000 1397.4200
 13    0      0    6 6:6:6:0          yes 5764.0000 400.0000  400.0000
 14    0      0    7 7:7:7:0          yes 5924.0000 400.0000 1396.0959
 15    0      0    7 7:7:7:0          yes 5924.0000 400.0000  400.0000

5137MHz is probably the best my CPU cores can do. No way 6080MHz is possible. I
wonder if you could fix it. HWiNFO64 reads maximum CPU cores frequencies
correctly.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #59 from Perry Yuan(AMD) (Perry.Yuan@amd.com) ---
(In reply to Artem S. Tashkinov from comment #56)
> Here's my report for 6.8.4 and Ryzen 7 7840HS:
> 
> 1. Setting scaling_max_freq works, cool, but you cannot go below 544MHz. You
> can set 400MHz but the CPU will continue to jump to 544MHz, not a big deal.
> 
> 2. Setting scaling_min_freq sort of works, the CPU _prefers_ to stay at this
> specified frequency but occasionally drops to 400MHz. Then, the CPU doesn't
> totally respect it, i.e. for values below 1.4GHz it stays around 1397MHz.
> The relationship is not linear, setting 4GHz results in the CPU preferring
> 3766Mhz. Or 2GHz -> 1982MHz. Not a big deal. Unlikely anyone would want to
> set the lowest frequency.
> 
> 3. /sys/devices/system/cpu/amd_pstate/cpb_boost is missing altogether:
> 
> # find /sys -iname '*boost*'
> [nothing]
> 
> So, my only remaining question is where's boost support? Or it's not
> supported for all Zen CPUs?
> 
> Thanks a lot for your work regardless!
1.  please try to apply the two patches for your cpb testing. 
https://lore.kernel.org/lkml/cover.1711335714.git.perry.yuan@amd.com/
https://lore.kernel.org/lkml/Zfqv3ckVU4km+RLr@BLR-5CG11610CF.amd.com/

2. are you testing under EPP driver mode? the 400MHz is the lowest freq,
however it dose not mean the CPU will be keeping at 400MHz, it will wake up and
idle and  bump up frequency shortly according to the workload.  you need to
know, when the Core is idle, kernel will not get the realtime frequency by
APERF/MPERF, cpufreq just show the lowest freq as 400MHz. It is not an issue. 

There is one idle frequency defined by power firmware, it is 1.4GHz for some
client system, the lowest active frequency is not 400MHz, it is 1.4GHz.  so you
have no need to worry the 1.4GHz or 400MHz, it is not a problem.

3. the invalid max frequency value issue is caused by wrong highest perf value
defined by pstate driver, I have been working a solution to fix that. with EPP
driver mode, it will not cause any performance problem, just a little
uncomfortable to see the wrong value listed.  

Perry.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #60 from Artem S. Tashkinov (aros@gmx.com) ---
Under Linux 6.9.4 the amd-pstate driver doesn't adhere to the maximum set
frequency for my Ryzen 7 5800X:

# cpupower frequency-info
analyzing CPU 10:
  driver: amd-pstate-epp
  CPUs which run at the same hardware frequency: 10
  CPUs which need to have their frequency coordinated by software: 10
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 550 MHz - 4.93 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 550 MHz and 1000 MHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 3.54 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
    AMD PSTATE Highest Performance: 166. Maximum Frequency: 4.93 GHz.
    AMD PSTATE Nominal Performance: 128. Nominal Frequency: 3.80 GHz.
    AMD PSTATE Lowest Non-linear Performance: 59. Lowest Non-linear Frequency:
1.75 GHz.
    AMD PSTATE Lowest Performance: 19. Lowest Frequency: 550 MHz.

# lscpu -ae
CPU SOCKET CORE L1d:L1i:L2:L3 ONLINE    MAXMHZ   MINMHZ       MHZ
  0      0    0 0:0:0:0          yes 4929.0000 550.0000 3124.8250
  1      0    1 1:1:1:0          yes 4929.0000 550.0000 3585.6809
  2      0    2 2:2:2:0          yes 4929.0000 550.0000  550.0000
  3      0    3 3:3:3:0          yes 4929.0000 550.0000 3554.8350
  4      0    4 4:4:4:0          yes 4929.0000 550.0000 3434.6189
  5      0    5 5:5:5:0          yes 4929.0000 550.0000 3589.3491
  6      0    6 6:6:6:0          yes 4929.0000 550.0000  550.0000
  7      0    7 7:7:7:0          yes 4929.0000 550.0000  550.0000
  8      0    0 0:0:0:0          yes 4929.0000 550.0000 3377.0410
  9      0    1 1:1:1:0          yes 4929.0000 550.0000 3545.8970
 10      0    2 2:2:2:0          yes 4929.0000 550.0000 3487.3730
 11      0    3 3:3:3:0          yes 4929.0000 550.0000 3185.1221
 12      0    4 4:4:4:0          yes 4929.0000 550.0000  550.0000
 13      0    5 5:5:5:0          yes 4929.0000 550.0000 4315.6221
 14      0    6 6:6:6:0          yes 4929.0000 550.0000 3148.2390
 15      0    7 7:7:7:0          yes 4929.0000 550.0000 3555.2141

---------------------------------------------------------------------------------------

And it's even more confusing since we now have:

1. * /sys/devices/system/cpu/cpufreq/policyX/scaling_available_governors
  performance powersave

2. How is it related to 

/sys/devices/system/cpu/cpufreq/policy0/energy_performance_preference which can
be of 
default performance balance_performance balance_power power?

3. And what's the "default" state?

---------------------------------------------------------------------------------------

It's all so simple with acpi-cpufreq :-(

1. I can enable/disable boost (not possible under amd-pstate on 6.9.4)
2. I can easily set maximum CPU core clock frequency (not possible for Ryzen 7
5800X under amd-pstate on 6.9.4)
3. I can set governors (performance powersave ondemand conservative)

With amd-pstate it's a huge maddening mess.

I'm going back to acpi-cpufreq until 6.10 at least for my desktop.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #61 from Artem S. Tashkinov (aros@gmx.com) ---
energy_performance_preference doesn't accept "default":

tee: /sys/devices/system/cpu/cpufreq/policy0/energy_performance_preference:
Invalid argument
tee: /sys/devices/system/cpu/cpufreq/policy10/energy_performance_preference:
Invalid argument
tee: /sys/devices/system/cpu/cpufreq/policy11/energy_performance_preference:
Invalid argument
tee: /sys/devices/system/cpu/cpufreq/policy12/energy_performance_preference:
Invalid argument
tee: /sys/devices/system/cpu/cpufreq/policy13/energy_performance_preference:
Invalid argument
tee: /sys/devices/system/cpu/cpufreq/policy14/energy_performance_preference:
Invalid argument
tee: /sys/devices/system/cpu/cpufreq/policy15/energy_performance_preference:
Invalid argument
tee: /sys/devices/system/cpu/cpufreq/policy1/energy_performance_preference:
Invalid argument
tee: /sys/devices/system/cpu/cpufreq/policy2/energy_performance_preference:
Invalid argument
tee: /sys/devices/system/cpu/cpufreq/policy3/energy_performance_preference:
Invalid argument
tee: /sys/devices/system/cpu/cpufreq/policy4/energy_performance_preference:
Invalid argument
tee: /sys/devices/system/cpu/cpufreq/policy5/energy_performance_preference:
Invalid argument
tee: /sys/devices/system/cpu/cpufreq/policy6/energy_performance_preference:
Invalid argument
tee: /sys/devices/system/cpu/cpufreq/policy7/energy_performance_preference:
Invalid argument
tee: /sys/devices/system/cpu/cpufreq/policy8/energy_performance_preference:
Invalid argument
tee: /sys/devices/system/cpu/cpufreq/policy9/energy_performance_preference:
Invalid argument

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #62 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
> 1. * /sys/devices/system/cpu/cpufreq/policyX/scaling_available_governors
>   performance powersave
> 2. How is it related to 
> /sys/devices/system/cpu/cpufreq/policy0/energy_performance_preference which
> can > be of 
> default performance balance_performance balance_power power?

When using EPP then the frequency selection is done by the firmware not the
kernel.  The kernel will set upper and lower performance targets and a bias
between performance and efficiency is configured using the EPP value.

> 1. I can enable/disable boost (not possible under amd-pstate on 6.9.4)

Boost support in EPP mode is not yet merged.  Perry shared some patches for
this, but they will need to spin again.  We're aiming for 6.11 to get this
merged.

> 3. And what's the "default" state?

As per kernel documentation [1]:

"default represents the epp value is set by platform firmware"

> energy_performance_preference doesn't accept "default":

Thanks for mentioning.  I've sent a patch for discussion on that [2].

[1] https://www.kernel.org/doc/html/latest/admin-guide/pm/amd-pstate.html
[2]
https://lore.kernel.org/linux-pm/20240612145737.1618-1-mario.limonciello@amd.com/T/#u

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

Miroslav Pavleski (miroslav@pavleski.net) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |miroslav@pavleski.net

--- Comment #63 from Miroslav Pavleski (miroslav@pavleski.net) ---
amd_pstate still is going haywire, testing on mainline 6.14.0-rc2. Upon fresh
boot, both active and passive drivers seem to adhere to scaling_max_freq.
Passive definitely. 

After S3 sleeping the machine, it goes haywire, even boosting CPUs (ignoring
boost flag) and going above the set limits. It is really frustrating on a
notebook machine, heating up and draining battery too fast, without some
significant workload, making it unusable as a portable.

I went back to acpi_cpufreq and the machine is much more well-behaved, even
though the minimal frequencies are much higher.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #64 from Artem S. Tashkinov (aros@gmx.com) ---
(In reply to Miroslav Pavleski from comment #63)
> amd_pstate still is going haywire, testing on mainline 6.14.0-rc2. Upon
> fresh boot, both active and passive drivers seem to adhere to
> scaling_max_freq. Passive definitely. 
> 
> After S3 sleeping the machine, it goes haywire, even boosting CPUs (ignoring
> boost flag) and going above the set limits. It is really frustrating on a
> notebook machine, heating up and draining battery too fast, without some
> significant workload, making it unusable as a portable.

What's your CPU/APU?

> 
> I went back to acpi_cpufreq and the machine is much more well-behaved, even
> though the minimal frequencies are much higher.

acpi_cpufreq's minimum reported frequencies shouldn't affect your power
consumption.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #65 from Miroslav Pavleski (miroslav@pavleski.net) ---
AMD Ryzen 9 6900HS, ROG Zephyrus G14 GA402RK

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #66 from Artem S. Tashkinov (aros@gmx.com) ---
(In reply to Miroslav Pavleski from comment #65)
> AMD Ryzen 9 6900HS, ROG Zephyrus G14 GA402RK

Thanks.

The issues that you're seeing past resume, have they always been there or they
are a 6.14 regression?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #67 from Miroslav Pavleski (miroslav@pavleski.net) ---
They were there even on 6.13 Arch builds and probably also on older kernel.
Since I've switched to acpi_cpufreq today it seems the machine has not been
this quiet in a long time.

I am speculating, it might be also an issue of the Asus firmware.  There is a
setting in the UEFI called ErP. Behavior is same regardless of that setting.
Currently turned off.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #68 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
This bug should have been closed a while ago (boost is landed a while now)
rather than cargo culted for the new issue.  In any case let's work through
your new issue and then we can close it once and for all.

> AMD Ryzen 9 6900HS, ROG Zephyrus G14 GA402RK
> After S3 sleeping the machine

S3 resume?  I don't believe that's a POR configuration for Ryzen 6000.  Are you
sure you don't mean s0i3/s2idle?  Or have you done some hacking on your BIOS to
try to get S3 back?

It would be really illustrative to me if you can please clone this repo and run
amd_s2idle.py and share the report.

https://git.kernel.org/pub/scm/linux/kernel/git/superm1/amd-debug-tools.git/

> it goes haywire, even boosting CPUs (ignoring boost flag) and going above the
> set limits.

I'm wondering if there is a case that the CPPC registers are in the wrong state
after resume.  In addition to running amd_s2idle.py, can you please run
amd_pstate.py both at bootup and then again after suspend?  Save two separate
reports and attach them here.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #69 from Miroslav Pavleski (miroslav@pavleski.net) ---
Created attachment 307677
  --> https://bugzilla.kernel.org/attachment.cgi?id=307677&action=edit
2025.02.17 Testing report

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #70 from Miroslav Pavleski (miroslav@pavleski.net) ---
😅 Um.. yeah, I was using modified ACPI to enable S3. I did that because s2idle
was freezing either on suspend or on resume in most of the cases.

The modification was done as documented in **S3_Instructions.md** in the
uploaded **2025.02.17_Report_Miroslav.zip** .


Now for testing, I've removed the **acpi-cpufreq=disable** and removed the ACPI
modification.

First attempt of sleeping, to s2idle - System frooze (never turned fans off,
never got blinking power led)
Second attempt - same result
Third attempt - It went sleeping (fans off, led blinking). Did not resume, got
stuck.
Fourth attempt - It supsended and resumed ok.
Fifth attempt - On the same boot as the fourth, froze the system again, never
reaching suspend.

In all cases where it got stuck I had to power off using holding the power
button.

I'm attaching the part the first two attempts journals.

Also I'm attaching the results (**s2idle_report-2025-02-17.txt**) of running
**amd_s2idle.py** with unmodified ACPI, so with s2idle sleep.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #71 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
> 😅 Um.. yeah, I was using modified ACPI to enable S3. I did that because
> s2idle was freezing either on suspend or on resume in most of the cases.

That's a really slippery slope.  There are absolutely low-level firmware areas
that aren't expecting an S3 flow that you're going to trip over.  I /suspect/
this issue you raise is one of them.

> 2025-02-17 19:17:25,726 ERROR:        👀 Suspend must be initiated by root
> user
> 2025-02-17 19:17:25,726 INFO: Your system does not meet s2idle prerequisites!

Can you please run it as root?  There are checks that require root that I'm
looking for.

> 2025-02-17 19:17:23,452 DEBUG:        bios_date: 06/06/2023

Is this the latest for your system?  Please check.


In your two logs I see this.

> feb 17 19:01:59 greenstation kernel: amd_pmc AMDI0007:00: Last suspend didn't
> reach deepest state
> feb 17 19:01:59 greenstation kernel: amd_pmc AMDI0007:00: Last suspend didn't
> reach deepest state

In order to explain this I need /sys/power/pm_debug_messages to be set and see
the logs associated with it.  Running that script as root should do a full
attempt and set /sys/power/pm_debug_messages or you can manually do this and
share the related dmesg nearby.

After that attempt it looks like there is a series of failure to recover for
your system.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #72 from Miroslav Pavleski (miroslav@pavleski.net) ---
Created attachment 307678
  --> https://bugzilla.kernel.org/attachment.cgi?id=307678&action=edit
amd_pstate.py test results

I'm adding the amd_pstate.py reports as 2025.02.17_pstate_reports_Miroslav.zip.

I've added a screenshot after resume (did not crash this time). It shows CPUs
going above 1.6GHz.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #73 from Miroslav Pavleski (miroslav@pavleski.net) ---
Created attachment 307679
  --> https://bugzilla.kernel.org/attachment.cgi?id=307679&action=edit
s2idle reports run with root

Mario, just to be clear, I've run all tests now on unmodified system. 

Regarding the latest BIOS update, unfortunately, I confirm this is the latest
one published by Asus.

This is from my dmidecode:
=====
BIOS Information
        Vendor: American Megatrends International, LLC.
        Version: GA402RK.319
        Release Date: 06/06/2023
        Address: 0xF0000
        Runtime Size: 64 kB
        ROM Size: 32 MB
==== 

This is from Asus support site for ROG Zephyrus G14 (2022) GA402:
===
BIOS Update for Windows
Version 319
10.22 MB 2023/08/11
===

I'm attaching two new s2idle reports run as root. On the second one I've set
manually the /sys/power/pm_debug_messages to 1. Seems the script is reverting
it to 0 after running.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #74 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
Created attachment 307680
  --> https://bugzilla.kernel.org/attachment.cgi?id=307680&action=edit
patch to invalidate cached CPPC request at suspend

> Mario, just to be clear, I've run all tests now on unmodified system. 

OK.

> I'm attaching two new s2idle reports run as root. On the second one I've set
> manually the /sys/power/pm_debug_messages to 1. Seems the script is reverting
> it to 0 after running.

Both of these reports look good.  It successfully made it down to HW sleep
state and spent a good amount of time there.

This is how s2idle should generally be looking.

> 2025-02-17 20:08:39,757 DEBUG:        Disabling GPIO #8 interrupt for
> suspend.
> 2025-02-17 20:08:39,805 INFO: ○ GPIOs active: ['8']

Just want to point this out that this GPIO appears to be active over suspend
and the Linux kernel intentionally ignores it.  It's not in _AEI() or _EVT()
ACPI methods.  It could be a red herring, but do you know what it's connected
to?  If not; can you share your full acpidump?  I might be able to figure it
out.

> I'm adding the amd_pstate.py reports as
> 2025.02.17_pstate_reports_Miroslav.zip.

I don't see a problem with CPPC enable register here, which is what my
suspicion was.

BUT what I can see is that there is a problem with the values programmed in
MSR_AMD_CPPC_REQ.  You can see comparing the two that all of the values for min
and max and EPP are totally wrong.

This is most likely an amd-pstate bug you're finding.  I think I see the issue.
 Here's a patch against 6.14-rc for you to try.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #75 from Miroslav Pavleski (miroslav@pavleski.net) ---
Created attachment 307681
  --> https://bugzilla.kernel.org/attachment.cgi?id=307681&action=edit
s2idle and pstate reports after applying the 'invalidate cppc' patch on 6.14rc2

Maybe those GPIOs are used on the Asus machine for handling the Hybrid
graphics. I'm just speculating here. 

The laptop has the onboard 6900HS GPU and also an AMD Radeon RX 6800S.

I've applied the patch on 6.14rc2. Attaching
2025.02.17_s2idle_and_pstate_reports_post-patch.zip:

- s2idle_report-2025-02-17-post_patch.txt -> run after fresh boot to 6.14rc2
with the patch. Suspend/resume cycle worked normal.
- rebooted
- amd_pstate_report-2025-02-17_post_patch.txt -> run after fresh boot
- s2idle_rs2idle_report-2025-02-17-post_patch2.txt -> succeeded suspend /
resume cycle
- amd_pstate_report-2025-02-17_post_patch2.txt -> run after the resume

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #76 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
> s2idle and pstate reports after applying the 'invalidate cppc' patch on
> 6.14rc2
> Maybe those GPIOs are used on the Asus machine for handling the Hybrid
> graphics. > I'm just speculating here. 

OK; let's not worry about that for now.  If you find a power consumption issue
later over s2idle we can figure it out then.

> I've applied the patch on 6.14rc2. Attaching
> 2025.02.17_s2idle_and_pstate_reports_post-patch.zip:

I'm confused here on the timing of all of these events, do you mean to say that
the patch did nothing?  That's what it seems like at least.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #77 from Miroslav Pavleski (miroslav@pavleski.net) ---
> I'm confused here on the timing of all of these events, do you mean to say
> that
the patch did nothing?  That's what it seems like at least.

All the files in the zip are after applying the patched kernel and rebooting. 
amd_pstate_report-2025-02-17_post_patch2.txt is report created after resuming
from s2idle.

I've just double checked in the source tree used for building the kernel
package. The patch is applied. 

In addition, I did some more testing after resuming from sleep. Seems now it is
not jumping above the scaling_max_freq when not stressed. 

I stress tested all 16 cores and then it ramped up towards boost freq. (above
nominal 3.3), while having scaling_max_freq set to 1.6GHz and boost 0. However
when I stopped the cpu hogging, it ramped back down idling between 400MHz and
1400MHz. Subjectively I would say the behavior is now *way better*, the CPU is
not drawing a lot of power when not stressed, under light desktop use. The fans
stay quiet.

Seems like the amd-pstate-epp has complex algorithm that takes the
scaling_max_freq as a hint, not as hard limit. The upside is that when needed,
it adapts to those needs. The downside is that this is not ideal under battery
use, as rogue processes (e.g. browser tabs) might drain battery without the
user realizing it.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

Mario Limonciello (AMD) (mario.limonciello@amd.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #307680|0                           |1
        is obsolete|                            |

--- Comment #78 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
Created attachment 307682
  --> https://bugzilla.kernel.org/attachment.cgi?id=307682&action=edit
possible patch (v2)

Here is an updated patch for another problem I see in this seqeuence.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #79 from Miroslav Pavleski (miroslav@pavleski.net) ---
Created attachment 307683
  --> https://bugzilla.kernel.org/attachment.cgi?id=307683&action=edit
s2idle and pstate reports after patchv2

I applied the second patch to mainline 6.14rc2, rebooted.

- run amd_pstate.py, results in
amd_pstate_report-2025-02-17-patchv2_pre_sleep.txt
- run amd_s2idle.py, system failed to suspend, hard reset, journal in
patchv2_suspend_freeze_journal.txt
- rebooted, run amd_pstate.py again =>
amd_pstate_report-2025-02-17-patchv2_pre_sleep_2nd_attempt.txt
- run amd_s2idle.py , succeeded cycling suspend/resume, report in
s2idle_report-2025-02-17_patchv2.txt
- run amd_pstate.py again after resume =>
amd_pstate_report-2025-02-17-patchv2_post_resume_2nd_attempt.txt

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #80 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---

OK great, it looks like the amd-pstate issue is fixed.  I'll include this in my
next patch series for amd-pstate.  It's good timing because I'm overhauling a
lot of this code for 6.15.

Unfortunately; your suspend failure is missing the thing I need to tell me some
important info about the failure mode(the idle mask print).  This is the line
we should have seen printed.  
https://github.com/torvalds/linux/blob/master/drivers/platform/x86/amd/pmc/pmc.c#L733

I notice this at the top before your sequence starts though:

> feb 17 22:06:52 greenstation kernel: NOHZ tick-stop error: local softirq work
> is pending, handler #08!!!

And that has me most concerned that the kernel wasn't really ready for suspend.
 Let's split out your s2idle suspend issue to it's own bug and try to figure
out the pattern and what debug we'll need.  We can keep this one for the
amd-pstate issue, and I expect we can land the patch for a later 6.14-rc.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #81 from Miroslav Pavleski (miroslav@pavleski.net) ---
> OK great, it looks like the amd-pstate issue is fixed.  I'll include this in
> my next patch series for amd-pstate.  It's good timing because I'm
> overhauling a lot of this code for 6.15.

That is great news! Glad I could be of some use there.


> Unfortunately; your suspend failure is missing the thing I need to tell me
> some important info about the failure mode(the idle mask print).  This is the
> line we should have seen printed.  
>
> https://github.com/torvalds/linux/blob/master/drivers/platform/x86/amd/pmc/pmc.c#L733
> 
> I notice this at the top before your sequence starts though:

>> feb 17 22:06:52 greenstation kernel: NOHZ tick-stop error: local softirq
>> work
>> is pending, handler #08!!!

> And that has me most concerned that the kernel wasn't really ready for
> suspend.  Let's split out your s2idle suspend issue to it's own bug and try
> to figure out the pattern and what debug we'll need.  We can keep this one
> for the amd-pstate issue, and I expect we can land the patch for a later
> 6.14-rc.

Well, I see line 733 calls amd_pmc_idlemask_read which includes the strings
"SMU" and "idlemask" in the output. Unfortunately, idlemask is not found in the
journal.
When grepping for "SMU" I got this:

===
feb 17 22:03:18 greenstation kernel: amdgpu 0000:03:00.0: amdgpu: SMU driver if
version not matched
feb 17 22:03:18 greenstation kernel: amdgpu 0000:03:00.0: amdgpu: SMU is
initialized successfully!
feb 17 22:03:18 greenstation kernel: amdgpu 0000:07:00.0: amdgpu: SMU is
initialized successfully!
feb 17 22:07:09 greenstation kernel: amdgpu 0000:07:00.0: amdgpu: SMU is
resuming...
feb 17 22:07:09 greenstation kernel: amdgpu 0000:07:00.0: amdgpu: SMU is
resumed successfully!
feb 17 22:07:09 greenstation kernel: amdgpu 0000:03:00.0: amdgpu: SMU is
resuming...
feb 17 22:07:09 greenstation kernel: amdgpu 0000:03:00.0: amdgpu: SMU driver if
version not matched
feb 17 22:07:09 greenstation kernel: amdgpu 0000:03:00.0: amdgpu: SMU: I'm not
done with your previous command: SMN_C2PMSG_66:0x00000036
SMN_C2PMSG_82:0x00000000
===

Regarding the NOHZ tick-stop error. I've seen on another thread somewhere that
it is probably related to the external USB-C hub I use. I cannot judge if it is
interfering with the s2idle suspend process.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

Artem S. Tashkinov (aros@gmx.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |CODE_FIX

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.