Bug 215938

Could you please check if bug 215800 affects you?

(In reply to Artem S. Tashkinov from comment #1)
> Could you please check if bug 215800 affects you?

No, I can set my frequency to 3GHZ and run stress and my scaling_cur_freq value reports ~3GHZ. I'm also on a AMD Ryzen 7 4800U, which is a Zen2 model.

(In reply to Alex Maras from comment #2)
> (In reply to Artem S. Tashkinov from comment #1)
> > Could you please check if bug 215800 affects you?
> 
> No, I can set my frequency to 3GHZ and run stress and my scaling_cur_freq
> value reports ~3GHZ. I'm also on a AMD Ryzen 7 4800U, which is a Zen2 model.

Hi Alex.
Could you help to attach the dmesg log and all CPU model info ?
Meanwhile I will check if I can reproduce the issue on my side if I have the any similar CPU model.

Perry.

Created attachment 301003 [details]
dmesg output after sleeping

1. Started up laptop fresh
2. Set governor to ondemand and frequency to 1.4GHZ
3. Checked CPU frequency, settings respected
4. Shut laptop lid, waited 10 seconds, opened laptop lid
5. Checked CPU frequency, settings disregarded
6. Grabbing dmesg output

Created attachment 301004 [details]
cpuinfo

CPUInfo output

Hey Perry,

I've attached the /proc/cpuinfo output and dmesg output after the listed process. Do you want anything more for the moment? Let me know if you need anything, happy to help.

Alex

(In reply to Alex Maras from comment #6)
> Hey Perry,
> 
> I've attached the /proc/cpuinfo output and dmesg output after the listed
> process. Do you want anything more for the moment? Let me know if you need
> anything, happy to help.
> 
> Alex

Thanks for your info.
Could you try this kernel ?

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/cpufreq/amd-pstate.c?h=v5.18

add this to grub.

amd-pstate.dyndbg=+p  acpi-cpufreq.dyndbg=+p freq_table.dyndbg=+p cpufreq.dyndbg=+p cpufreq_governor.dyndbg=+p

I didn't find amd pstate driver related log in your last dmesg.
more debug logs will be helpful.

Thanks.
Perry.

Created attachment 301080 [details]
dmesg output after sleeping - with debug params

I've attached the dmesg output here after applying those kernel params. My kernel version has the latest commit. I'll compile from git to ensure the results are the same in the meantime. 

The dmesg results are interesting - cat-ing scaling_cur_freq still shows the same behavior, but dmesg doesn't show any values above 1.4gHz. I ran `stress` either side of sleeping and watched the scaling_cur_freq, and can confirm that it was maxing out at 1.4gHz before suspend, and not limited after suspend.

Created attachment 301137 [details]
dmesg output - 5.18

same process with dmesg output with kernel built from 5.18 release tag

Note - in the most recent test, I was limiting to 1gHz instead of 1.4 - results are the same, successfully stating at 1gHz prior to sleeping, unbound after waking from sleep.

(In reply to Alex Maras from comment #10)
> Note - in the most recent test, I was limiting to 1gHz instead of 1.4 -
> results are the same, successfully stating at 1gHz prior to sleeping,
> unbound after waking from sleep.

Hi Alex.
Thanks for your detail and info share, I will check the logs soon. then will give you some feedback.

(In reply to Alex Maras from comment #8)
> Created attachment 301080 [details]
> dmesg output after sleeping - with debug params
> 
> I've attached the dmesg output here after applying those kernel params. My
> kernel version has the latest commit. I'll compile from git to ensure the
> results are the same in the meantime. 
> 
> The dmesg results are interesting - cat-ing scaling_cur_freq still shows the
> same behavior, but dmesg doesn't show any values above 1.4gHz. I ran
> `stress` either side of sleeping and watched the scaling_cur_freq, and can
> confirm that it was maxing out at 1.4gHz before suspend, and not limited
> after suspend.

Hi Alex.
Could you help to try if you can change the cores frequency when you switch to userspace governor after suspend/resume test?


 # sudo cpupower frequency-set -g userspace
 # systemctl suspend 
 Resume from Suspend pressing power button or keyboards.
 # cd /sys/devices/system/cpu/cpufreq/policy0
 # echo 1752589 > scaling_setspeed  //change this core freq to see if it can be changed 
 # cat scaling_setspeed
 # cat scaling_governor
 # cat scaling_cur_freq


I would like to see if the cpu cores still can change freq or not after resuming.

If the cpu freq cannot be changed, even you change the cpuinfo_max_freq, core freq(scaling_cur_freq) will not be limited  successfully as well. 


Perry.

Hey Perry, results below:

[I] alex@alex-laptop ~> sudo cpupower frequency-set -g userspace
[sudo] password for alex:
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
Setting cpu: 4
Setting cpu: 5
Setting cpu: 6
Setting cpu: 7
Setting cpu: 8
Setting cpu: 9
Setting cpu: 10
Setting cpu: 11
Setting cpu: 12
Setting cpu: 13
Setting cpu: 14
Setting cpu: 15
[I] alex@alex-laptop ~> systemctl suspend
[I] alex@alex-laptop ~> cd /sys/devices/system/cpu/cpufreq/policy0
[I] alex@alex-laptop /s/d/s/c/c/policy0> echo 1752589 | sudo tee scaling_setspeed
1752589
[I] alex@alex-laptop /s/d/s/c/c/policy0> cat scaling_setspeed
1752589
[I] alex@alex-laptop /s/d/s/c/c/policy0> cat scaling_governor
userspace
[I] alex@alex-laptop /s/d/s/c/c/policy0> cat scaling_cur_freq
2796520
[I] alex@alex-laptop /s/d/s/c/c/policy0>


Looks like the same issue continuing. Do you want the same dmesg with pstate logging turned on?

(In reply to Alex Maras from comment #13)
> Hey Perry, results below:
> 
> [I] alex@alex-laptop ~> sudo cpupower frequency-set -g userspace
> [sudo] password for alex:
> Setting cpu: 0
> Setting cpu: 1
> Setting cpu: 2
> Setting cpu: 3
> Setting cpu: 4
> Setting cpu: 5
> Setting cpu: 6
> Setting cpu: 7
> Setting cpu: 8
> Setting cpu: 9
> Setting cpu: 10
> Setting cpu: 11
> Setting cpu: 12
> Setting cpu: 13
> Setting cpu: 14
> Setting cpu: 15
> [I] alex@alex-laptop ~> systemctl suspend
> [I] alex@alex-laptop ~> cd /sys/devices/system/cpu/cpufreq/policy0
> [I] alex@alex-laptop /s/d/s/c/c/policy0> echo 1752589 | sudo tee
> scaling_setspeed
> 1752589
> [I] alex@alex-laptop /s/d/s/c/c/policy0> cat scaling_setspeed
> 1752589
> [I] alex@alex-laptop /s/d/s/c/c/policy0> cat scaling_governor
> userspace
> [I] alex@alex-laptop /s/d/s/c/c/policy0> cat scaling_cur_freq
> 2796520
> [I] alex@alex-laptop /s/d/s/c/c/policy0>
> 
> 
> Looks like the same issue continuing. Do you want the same dmesg with pstate
> logging turned on?

Seeing from you result, issue can be reproduced by my side, the core frequency is not updated by low level firmware.
I suppose that the issue was caused by suspend/resume , firmware has problem to resume the CPU frequency control, so any new frequency set will be ignored.
I will further do some debugging and try to resolve the problem.
Thanks for your confirm.

Perry.

Hi Alex.

I have been preparing some fix patches to resolve the prolem.
Will update here after patches sent.

Perry.

*** Bug 216189 has been marked as a duplicate of this bug. ***

(In reply to Alex Maras from comment #13)
> Hey Perry, results below:
> 
> [I] alex@alex-laptop ~> sudo cpupower frequency-set -g userspace
> [sudo] password for alex:
> Setting cpu: 0
> Setting cpu: 1
> Setting cpu: 2
> Setting cpu: 3
> Setting cpu: 4
> Setting cpu: 5
> Setting cpu: 6
> Setting cpu: 7
> Setting cpu: 8
> Setting cpu: 9
> Setting cpu: 10
> Setting cpu: 11
> Setting cpu: 12
> Setting cpu: 13
> Setting cpu: 14
> Setting cpu: 15
> [I] alex@alex-laptop ~> systemctl suspend
> [I] alex@alex-laptop ~> cd /sys/devices/system/cpu/cpufreq/policy0
> [I] alex@alex-laptop /s/d/s/c/c/policy0> echo 1752589 | sudo tee
> scaling_setspeed
> 1752589
> [I] alex@alex-laptop /s/d/s/c/c/policy0> cat scaling_setspeed
> 1752589
> [I] alex@alex-laptop /s/d/s/c/c/policy0> cat scaling_governor
> userspace
> [I] alex@alex-laptop /s/d/s/c/c/policy0> cat scaling_cur_freq
> 2796520
> [I] alex@alex-laptop /s/d/s/c/c/policy0>
> 
> 
> Looks like the same issue continuing. Do you want the same dmesg with pstate
> logging turned on?

The suspend issue has been fixed by below patch.
Please try the below patch for the suspend/resume issue.

https://patchwork.kernel.org/project/linux-pm/patch/20220623031509.555269-1-Jinzhou.Su@amd.com/

Thanks Perry - tested and working as expected. I'm now able to set the CPU freq with amd-pstate, suspend, resume and see that the cpu frequency limits are now respected correctly, and changing both the governor and the frequency limits works as expected. 

I've set this to resolved with a code fix.

(In reply to Alex Maras from comment #18)
> Thanks Perry - tested and working as expected. I'm now able to set the CPU
> freq with amd-pstate, suspend, resume and see that the cpu frequency limits
> are now respected correctly, and changing both the governor and the
> frequency limits works as expected. 
> 
> I've set this to resolved with a code fix.

HI Alex.

Good to hear that. 
Thanks for your confirm. 

Perry.

Guys, have you get amd_pstate working with schedutil governor?  
On my system, it completely ignores frequency limits and boost state. 

```
~  sudo cpupower frequency-set -g schedutil -d 1200MHz -u 1600MHz                                                                                            
~  sudo cpupower frequency-info                                                                                                                              
analyzing CPU 0:
  driver: amd-pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 131 us
  hardware limits: 400 MHz - 1.90 GHz
  available cpufreq governors: ondemand performance schedutil
  current policy: frequency should be within 1.20 GHz and 1.60 GHz.
                  The governor "schedutil" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 2.60 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: no
    AMD PSTATE Highest Performance: 166. Maximum Frequency: 4.51 GHz.
    AMD PSTATE Nominal Performance: 70. Nominal Frequency: 1.90 GHz.
    AMD PSTATE Lowest Non-linear Performance: 41. Lowest Non-linear Frequency: 1.11 GHz.
    AMD PSTATE Lowest Performance: 15. Lowest Frequency: 400 MHz.
```

Other governors (ondemand/performance) works as intended.  
Is it a bug or something else?

(In reply to a from comment #20)
> Guys, have you get amd_pstate working with schedutil governor?  
> On my system, it completely ignores frequency limits and boost state. 

On my 5800HS using amd-pstate, the lowest clock speed schedutil goes to is 2500mhz compared to other governors which go down to 400mhz, we should probably log a separate bug report? This is any time not just when waking from suspend

I am seeing this issue back with 6.13.8

(In reply to Vincent Maurin from comment #22)
> I am seeing this issue back with 6.13.8

It was remove with this commit https://github.com/torvalds/linux/commit/2064543f5ba0d2929e3e9b3a616c3262a57c7925