Re: [REGRESSION] amd-pstate doesn't work since v5.18.11
From: Limonciello, Mario
Date: Tue Jul 12 2022 - 16:07:48 EST
On 7/12/2022 12:54, Oleksandr Natalenko wrote:
Hello.
On úterý 12. července 2022 19:50:33 CEST Limonciello, Mario wrote:
[Public]
+ Ray
-----Original Message-----
From: Yuan, Perry <Perry.Yuan@xxxxxxx>
Sent: Tuesday, July 12, 2022 12:50
To: Oleksandr Natalenko <oleksandr@xxxxxxxxxxxxxx>; Limonciello, Mario
<Mario.Limonciello@xxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx
Cc: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>; Sasha Levin
<sashal@xxxxxxxxxx>; x86@xxxxxxxxxx; H. Peter Anvin <hpa@xxxxxxxxx>;
Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [REGRESSION] amd-pstate doesn't work since v5.18.11
[AMD Official Use Only - General]
Hi Oleksandr:
-----Original Message-----
From: Oleksandr Natalenko <oleksandr@xxxxxxxxxxxxxx>
Sent: Wednesday, July 13, 2022 1:40 AM
To: Limonciello, Mario <Mario.Limonciello@xxxxxxx>; linux-
kernel@xxxxxxxxxxxxxxx
Cc: Yuan, Perry <Perry.Yuan@xxxxxxx>; Rafael J. Wysocki
<rafael.j.wysocki@xxxxxxxxx>; Sasha Levin <sashal@xxxxxxxxxx>;
x86@xxxxxxxxxx; H. Peter Anvin <hpa@xxxxxxxxx>; Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx>
Subject: [REGRESSION] amd-pstate doesn't work since v5.18.11
[CAUTION: External Email]
Hello Mario.
The following commits were pulled into v5.18.11:
```
$ git log --oneline --no-merges v5.18.10..v5.18.11 | grep ACPI
2783414e6ef7 ACPI: CPPC: Don't require _OSC if X86_FEATURE_CPPC is
supported
3068cfeca3b5 ACPI: CPPC: Only probe for _CPC if CPPC v2 is acked
8beb71759cc8 ACPI: bus: Set CPPC _OSC bits for all and when CPPC_LIB is
supported
13bb696dd2f3 ACPI: CPPC: Check _OSC for flexible address space ```
and now this happens:
```
$ sudo modprobe amd-pstate shared_mem=1
modprobe: ERROR: could not insert 'amd_pstate': No such device ```
With v5.18.10 this worked just fine.
In your upstream commit 8b356e536e69f3a4d6778ae9f0858a1beadabb1f
you write:
```
If there is additional breakage on the shared memory designs also missing
this _OSC, additional follow up changes may be needed.
```
So the question is what else should be pulled into the stable tree to
unbreak amd-pstate?
Thanks.
--
Oleksandr Natalenko (post-factum)
Could you share the lscpu output ?
Here's my `lscpu`:
```
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 43 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 24
On-line CPU(s) list: 0-23
Vendor ID: AuthenticAMD
Model name: AMD Ryzen 9 3900XT 12-Core Processor
CPU family: 23
Model: 113
Thread(s) per core: 2
Core(s) per socket: 12
Socket(s): 1
Stepping: 0
Frequency boost: enabled
CPU(s) scaling MHz: 59%
CPU max MHz: 3800,0000
CPU min MHz: 2200,0000
BogoMIPS: 7589.71
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip rdpid overflow_recov succor smca sev sev_es
Virtualization: AMD-V
L1d cache: 384 KiB (12 instances)
L1i cache: 384 KiB (12 instances)
L2 cache: 6 MiB (12 instances)
L3 cache: 64 MiB (4 instances)
NUMA node(s): 1
NUMA node0 CPU(s): 0-23
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Mmio stale data: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Retpolines, IBPB conditional, STIBP conditional, RSB filling
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
```
Perry.
Thanks this is the sort of thing I was worried might happen as a result of requiring
the _OSC. It was introduced as part of that commit 8beb71759cc8.
To solve it I think we need to add more things to cpc_supported_by_cpu
(https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftorvalds%2Flinux%2Fblob%2F525496a030de4ae64bb9e1d6bfc88eec6f5fe6e2%2Farch%2Fx86%2Fkernel%2Facpi%2Fcppc.c%23L19&data=05%7C01%7CMario.Limonciello%40amd.com%7C96addaab0edc4e22779908da642f84ac%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637932453099304670%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4KHD3UUlfDJEmpTpqDCmuV1x%2F7nj%2F0iuhwdnhJqtQeU%3D&reserved=0)
The question is how do we safely detect the shared memory designs?
These are a fixed quantity as newer designs /should/ be using the MSR.
I am tending to thing that unfortunately we need to have an allow-list of shared
memory design here unless someone has other ideas.
Happy to test any patches as needed.
See if this helps out:
diff --git a/arch/x86/kernel/acpi/cppc.c b/arch/x86/kernel/acpi/cppc.c
index 734b96454896..88a81e6b9228 100644
--- a/arch/x86/kernel/acpi/cppc.c
+++ b/arch/x86/kernel/acpi/cppc.c
@@ -16,6 +16,13 @@ bool cpc_supported_by_cpu(void)
switch (boot_cpu_data.x86_vendor) {
case X86_VENDOR_AMD:
case X86_VENDOR_HYGON:
+ if (boot_cpu_data.x86 == 0x19 &&
+ ((boot_cpu_data.x86_model >= 0x00 &&
boot_cpu_data.x86_model <= 0x0f) ||
+ (boot_cpu_data.x86_model >= 0x20 &&
boot_cpu_data.x86_model <= 0x2f)))
+ return true;
+ else if (boot_cpu_data.x86 == 0x17 &&
+ boot_cpu_data.x86_model >= 0x70 &&
boot_cpu_data.x86_model <= 0x7f)
+ return true;
return boot_cpu_has(X86_FEATURE_CPPC);
}
return false;
If that works and no one has a better idea how to do it for these
systems I'll send out a proper proper patch tomorrow.