[CachyOS / kernel-patches] Kernel 6.1.0 module compilation fails Zen3

[Slaviusz]

Hello,

I just want to report an issue building corefreqk.ko with latest master and develop on kernel 6.1.0 on x86_64 with Zen3 (5950x).

I have this kernel patch applied but IIRC I also had this issue compiling without applying it.

I can compile the module just fine before commit 4bf9f02d6fa20d144e3508e5b99bfabf59574cb0

make -j1 -C /lib/modules/6.1.0-tkg-bore-llvm/build M=/root/CoreFreq modules
make[1]: warning: -j1 forced in submake: resetting jobserver mode.
make[1]: Entering directory '/usr/src/linux-6.1.0-tkg-bore-llvm'
  CC [M]  /root/CoreFreq/corefreqk.o
/root/CoreFreq/corefreqk.c:3943:12: fatal error: call to undeclared function 'cppc_get_epp_caps'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
        if ((rc = cppc_get_epp_caps(cpu, &CPPC_Caps)) == 0)
                  ^
/root/CoreFreq/corefreqk.c:3943:12: note: did you mean 'cppc_get_perf_caps'?
./include/acpi/cppc_acpi.h:143:12: note: 'cppc_get_perf_caps' declared here
extern int cppc_get_perf_caps(int cpu, struct cppc_perf_caps *caps);
           ^
1 error generated.
make[2]: *** [scripts/Makefile.build:250: /root/CoreFreq/corefreqk.o] Error 1
make[1]: *** [Makefile:1992: /root/CoreFreq] Error 2
make[1]: Leaving directory '/usr/src/linux-6.1.0-tkg-bore-llvm'
make: *** [Makefile:86: all] Error 2

Thank You for your help.

[cyring]

Hello,

The CPPC/EPP implementation has been made on the Arch AUR package linux-cachyos-bore

Searching for the missing cppc_get_epp_caps in the CachyOS repository, I'm finding this patch 0009-Implement-AMD-Pstate-EPP-Driver.patch

Can you apply it to your kernel and try to build CoreFreq again ?

[Slaviusz]

Hello, I'm afraid these patches are mutually exclusive. The amd_pstate=guided (PASSIVE GUIDED) is not compatible with amd_pstate=active (EPP). Both are developments to amd_pstate. I can try to apply both patches but only one can be active at a time.

Update: I was able to apply both patches (amd_pstate=guided and amd_pstate=active v6) and kernel compilation went fine. I will try to reboot with amd_pstate=guided kernel param to see if everything works.

[Slaviusz]

Sorry, my bad :(. I misconfigured my build and not both patches were applied. It seems that indeed, these patches are mutually exclusive. When I updated my config applying both patches fails:

 -> ######################################################
 ->
 -> Applying your own linux-6.1 patch /root/linux-tkg/linux61-tkg-userpatches/61_pstate_epp.mypatch
 ->
 -> ######################################################
patching file drivers/acpi/cppc_acpi.c
patching file include/acpi/cppc_acpi.h
patching file Documentation/admin-guide/pm/amd-pstate.rst
patching file arch/x86/include/asm/msr-index.h
patching file drivers/cpufreq/intel_pstate.c
Hunk #2 succeeded at 628 (offset -1 lines).
patching file include/linux/cpufreq_common.h
patching file drivers/cpufreq/amd-pstate.c
patching file include/linux/amd-pstate.h
patching file drivers/cpufreq/amd-pstate.c
patching file include/linux/amd-pstate.h
patching file drivers/cpufreq/amd-pstate.c
patching file drivers/cpufreq/amd-pstate.c
patching file drivers/cpufreq/amd-pstate.c
patching file Documentation/admin-guide/pm/amd-pstate.rst
patching file Documentation/admin-guide/kernel-parameters.txt
Hunk #1 succeeded at 6973 (offset 3 lines).
patching file drivers/cpufreq/amd-pstate.c
 -> ######################################################
 ->
 -> Applying your own linux-6.1 patch /root/linux-tkg/linux61-tkg-userpatches/61_pstate_guided_autonomous.mypatch
 ->
 -> ######################################################
patching file Documentation/admin-guide/kernel-parameters.txt
Hunk #2 FAILED at 6974.
1 out of 2 hunks FAILED -- saving rejects to file Documentation/admin-guide/kernel-parameters.txt.rej
patching file Documentation/admin-guide/pm/amd-pstate.rst
Hunk #1 succeeded at 284 (offset 19 lines).
patching file drivers/cpufreq/amd-pstate.c
Hunk #1 succeeded at 53 (offset 3 lines).
Hunk #2 FAILED at 76.
Hunk #3 succeeded at 364 (offset 136 lines).
Hunk #4 succeeded at 430 (offset 136 lines).
Hunk #5 succeeded at 464 (offset 136 lines).
Hunk #6 succeeded at 872 with fuzz 1 (offset 258 lines).
Hunk #7 succeeded at 1592 with fuzz 1 (offset 835 lines).
Hunk #8 succeeded at 1623 (offset 836 lines).
Hunk #9 FAILED at 823.
Hunk #10 FAILED at 830.
3 out of 10 hunks FAILED -- saving rejects to file drivers/cpufreq/amd-pstate.c.rej
patching file drivers/acpi/cppc_acpi.c
Hunk #1 succeeded at 1524 (offset 104 lines).
Hunk #2 succeeded at 1535 (offset 104 lines).
Hunk #3 succeeded at 1545 (offset 104 lines).
Hunk #4 succeeded at 1573 (offset 104 lines).
Hunk #5 succeeded at 1624 (offset 104 lines).
patching file drivers/acpi/cppc_acpi.c
Hunk #2 succeeded at 1366 with fuzz 2 (offset -1 lines).
patching file include/acpi/cppc_acpi.h
Hunk #1 FAILED at 108.
Hunk #2 FAILED at 149.
Hunk #3 succeeded at 214 (offset 12 lines).
2 out of 3 hunks FAILED -- saving rejects to file include/acpi/cppc_acpi.h.rej
patching file drivers/cpufreq/amd-pstate.c
Hunk #1 succeeded at 287 (offset 123 lines).
Hunk #2 succeeded at 924 (offset 245 lines).
 -> exit cleanup done

[cyring]

Sorry, my bad :(. I misconfigured my build and not both patches were applied. It seems that indeed, these patches are mutually exclusive. When I updated my config applying both patches fails:

So you mean we are back to square one with the issue pending.

If cppc_get_epp_caps is not available in your patches list then some kind of a definition, like any patch level or version, is needed to drive the CoreFreq build

As you can see in function Get_EPP_ACPI_CPPC https://github.com/cyring/CoreFreq/blob/870899ff427f21da4787042ecda167255232dd31/corefreqk.c#L3937 CONFIG_SCHED_BORE or CONFIG_CACHY will involve cppc_get_epp_caps

I'm now rebooting to Cachy to find any particular CONFIG_ ...

[Slaviusz]

It's kind of weird situation. To compile CoreFreq we need patch that has been scheduled to merge in linux 6.3 (that is 14-16 weeks ahead given typical 7-8 RC releases for each cycle). Until then we're stuck with old version with no new development. Could you please reconsider dependency on this particular patch or add some condition to depend on alternative API?

Thank You in advance.

[cyring]

It's kind of weird situation. To compile CoreFreq we need patch that has been scheduled to merge in linux 6.3 (that is 14-16 weeks ahead given typical 7-8 RC releases for each cycle). Until then we're stuck with old version with no new development. Could you please reconsider dependency on this particular patch or add some condition to depend on alternative API?

Thank You in advance.

Sure.

I was interested in the AUR package because its patch brings the firmware ACPI EPP handling.

My target is however the accepted EPP implementation into the mainline kernel and I don't know among all these patches which one is taking the good direction ?

[Slaviusz]

Well, nobody knows at the moment. It's however well appreciated that there are multiple developments regarding performance on Zen platforms. Personally (in some of my synthetic benchmarks using phoronix-test-suite) I found amd_pstate=guided with performance governor currently performing the best compared to ACPI, GUIDED, PASSIVE and EPP. However the difference was only 3-7% in very specific scenarios (stress-ng forking, system V passing and context switching).

[Slaviusz]

So I now tested v8 of the amd_pstate EPP patch from Dec. 19 2022 and it also breaks CoreFreq module compilation. It seems the API changes often.

make -j1 -C /lib/modules/6.1.0-tkg-bore-llvm/build M=/root/CoreFreq modules
make[1]: warning: -j1 forced in submake: resetting jobserver mode.
make[1]: Entering directory '/usr/src/linux-6.1.0-tkg-bore-llvm'
  CC [M]  /root/CoreFreq/corefreqk.o
/root/CoreFreq/corefreqk.c:3943:12: fatal error: call to undeclared function 'cppc_get_epp_caps'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
        if ((rc = cppc_get_epp_caps(cpu, &CPPC_Caps)) == 0)
                  ^
/root/CoreFreq/corefreqk.c:3943:12: note: did you mean 'cppc_get_perf_caps'?
./include/acpi/cppc_acpi.h:144:12: note: 'cppc_get_perf_caps' declared here
extern int cppc_get_perf_caps(int cpu, struct cppc_perf_caps *caps);
           ^
1 error generated.
make[2]: *** [scripts/Makefile.build:250: /root/CoreFreq/corefreqk.o] Error 1
make[1]: Leaving directory '/usr/src/linux-6.1.0-tkg-bore-llvm'
make[1]: *** [Makefile:1992: /root/CoreFreq] Error 2
make: *** [Makefile:86: all] Error 2

[cyring]

Here is my proposition: as a default, build will go without that cppc_get_epp_caps patch. ACPI EPP will consequently be not available during runtime.

One needs to set the directive FEAT_DBG of a least 100 to get the feature working again

make FEAT_DBG=100

You can now pull the develop branch to experiment this change.

PS: Beside that, let's hope the Manufacturer will soon upstream its final EPP interface.

[Slaviusz]

Thank you very much. I managed to get develop version to compile and working fine.

I hope that the EPP interface stabilizes soon enough.

Wish you good luck and Merry Christmas :) <3