search

cyring / CoreFreq

CoreFreq : CPU monitoring and tuning software designed for 64-bit processors.
https://www.cyring.fr
GNU General Public License v2.0
1.94k stars 127 forks source link

TUXEDO Linux 6.5 kernel compatibility? #462

Closed Technologicat closed 8 months ago

Technologicat commented 8 months ago

Hi,

I recently upgraded to kernel 6.5.0, and now CoreFreq will not compile:

jje@maia:~/Documents/koodit/CoreFreq$ make
cc  -Wall -Wfatal-errors -pthread -c corefreqd.c \
  -D CORE_COUNT=256 -D TASK_ORDER=5 -D MAX_FREQ_HZ=7125000000 -D UBENCH=0 -D DELAY_TSC=1 \
  -o corefreqd.o
cc  -Wall -Wfatal-errors -c corefreqm.c \
  -D CORE_COUNT=256 -D TASK_ORDER=5 -D MAX_FREQ_HZ=7125000000 -D UBENCH=0 -D DELAY_TSC=1 \
  -o corefreqm.o
cc  -Wall -Wfatal-errors corefreqd.c corefreqm.c \
  -D CORE_COUNT=256 -D TASK_ORDER=5 -D MAX_FREQ_HZ=7125000000 -D UBENCH=0 -D DELAY_TSC=1 \
  -o corefreqd -lpthread -lm -lrt
cc  -Wall -Wfatal-errors -c corefreq-cli.c \
  -D CORE_COUNT=256 -D TASK_ORDER=5 -D MAX_FREQ_HZ=7125000000 -D UBENCH=0 -D DELAY_TSC=1  \
  -o corefreq-cli.o
cc  -Wall -Wfatal-errors -c corefreq-ui.c \
  -D CORE_COUNT=256 -D TASK_ORDER=5 -D MAX_FREQ_HZ=7125000000 -D UBENCH=0 -D DELAY_TSC=1 \
  -o corefreq-ui.o
cc  -Wall -Wfatal-errors -c corefreq-cli-rsc.c \
  -D CORE_COUNT=256 -D TASK_ORDER=5 -D MAX_FREQ_HZ=7125000000 -D UBENCH=0 -D DELAY_TSC=1  \
  -o corefreq-cli-rsc.o
cc  -Wall -Wfatal-errors -c corefreq-cli-json.c \
  -D CORE_COUNT=256 -D TASK_ORDER=5 -D MAX_FREQ_HZ=7125000000 -D UBENCH=0 -D DELAY_TSC=1 \
  -o corefreq-cli-json.o
cc  -Wall -Wfatal-errors -c corefreq-cli-extra.c \
  -D CORE_COUNT=256 -D TASK_ORDER=5 -D MAX_FREQ_HZ=7125000000 -D UBENCH=0 -D DELAY_TSC=1 \
  -o corefreq-cli-extra.o
cc  -Wall -Wfatal-errors \
  corefreq-cli.c corefreq-ui.c corefreq-cli-rsc.c \
  corefreq-cli-json.c corefreq-cli-extra.c \
  -D CORE_COUNT=256 -D TASK_ORDER=5 -D MAX_FREQ_HZ=7125000000 -D UBENCH=0 -D DELAY_TSC=1  \
  -o corefreq-cli -lm -lrt
make -j1 -C /lib/modules/6.5.0-10005-tuxedo/build M=/home/jje/Documents/koodit/CoreFreq modules
make[1]: Entering directory '/usr/src/linux-headers-6.5.0-10005-tuxedo'
warning: the compiler differs from the one used to build the kernel
  The kernel was built by: x86_64-linux-gnu-gcc-11 (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
  You are using:           gcc-11 (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
  CC [M]  /home/jje/Documents/koodit/CoreFreq/corefreqk.o
/home/jje/Documents/koodit/CoreFreq/corefreqk.c: In function ‘CoreFreqK_FreqDriver_UnInit’:
/home/jje/Documents/koodit/CoreFreq/corefreqk.c:20624:12: error: void value not ignored as it ought to be
20624 |         rc = cpufreq_unregister_driver(&CoreFreqK.FreqDriver);
      |            ^
compilation terminated due to -Wfatal-errors.
make[3]: *** [scripts/Makefile.build:251: /home/jje/Documents/koodit/CoreFreq/corefreqk.o] Error 1
make[2]: *** [/usr/src/linux-headers-6.5.0-10005-tuxedo/Makefile:2037: /home/jje/Documents/koodit/CoreFreq] Error 2
make[1]: *** [Makefile:234: __sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-6.5.0-10005-tuxedo'
make: *** [Makefile:86: all] Error 2

Out of curiosity, I tried disabling -Wfatal-errors in the Makefile, but it did not help.

It seems something has changed in the kernel, somewhere after 6.2.0 (where CoreFreq worked correctly). And yes, I rebooted after upgrading the new kernel packages, so I'm sure it's seeing the correct kernel headers. :)

So, I'd like to ask, are there plans for Linux 6.5 support in CoreFreq?

cyring commented 8 months ago

Using ArchLinux, CoreFreq is building/running fine with both mainstream 6.5 and next 6.6

Looking at the compilation issue, you will notice your distribution must have CONFIG_CPU_FREQ Can you check if it is present in /proc/config ? But also if any patch has modified your kernel source tree ?

cyring commented 8 months ago

Also observed that up to the latest Linux rc cpufreq_unregister_driver is declared

cyring commented 8 months ago

https://www.tuxedocomputers.com/en/TUXEDO-OS_1.tuxedo#

Modified Linux kernel Optimized for TUXEDO-Hardware

cyring commented 8 months ago

It looks the same as the mainstream kernel.

cyring commented 8 months ago

Do you have rebooted PC since the 6.5 upgrade ?

Technologicat commented 8 months ago

Yes, I rebooted the PC. Always useful to do that ASAP after a kernel/driver upgrade. :)

No /proc/config, but there was a /boot/config matching the kernel version, which had the following three matches for CPUFREQ:

CONFIG_X86_PCC_CPUFREQ=y
CONFIG_X86_ACPI_CPUFREQ=y
CONFIG_X86_ACPI_CPUFREQ_CPB=y

TUXEDO-branded kernel, good point. The machine is actually a CLEVO, and the OS is Linux Mint 21.1. It's the same one as last spring, when you upgraded the memory detection in CoreFreq to support Alder Lake.

For background: TUXEDO is a CLEVO-based Linux laptop vendor. My previous system was a TUXEDO and I had an excellent experience with them, but this time I ended up with a base CLEVO model, because TUXEDO didn't offer the specs I wanted at the time when I needed a new laptop. They did refresh their offerings after a few months, so bad timing on my part, but sometimes waiting is not an option. :)

Anyway, essentially the hardware is the same as what TUXEDO uses, although the exact combination may differ, since CLEVO makes a lot of models. I've mainly used the TUXEDO apt repository to get two things:

But when the repo is enabled, Mint's Update Manager does pull in their kernels, too.

6.2.0-10007-tuxedo did work for me (note different build number; didn't try 10027). That's why I thought something had changed.

Indeed, looking at your screenshots, in 6.2.0 the return type of cpufreq_unregister_driver is int, whereas in 6.5.0-10005-tuxedo it's void, and this is what is breaking the build.

I'll try with a different kernel and report back. Thanks for the help!

cyring commented 8 months ago

Indeed, looking at your screenshots, in 6.2.0 the return type of cpufreq_unregister_driver is int, whereas in 6.5.0-10005-tuxedo it's void, and this is what is breaking the build.

Yes but there's a conditional build based on the following:

#if (LINUX_VERSION_CODE < KERNEL_VERSION(6, 3, 0)) && (!defined(CONFIG_CACHY))

But your 6.5.0-10005-tuxedo is wrongly going through the case lower than 6.3

It's worth to check if you have CONFIG_CACHY set or not in the current /boot/config ?

Also it happens that the kernel version written in filename is not the same as the computed version integer within LINUX_VERSION_CODE

Technologicat commented 8 months ago

No match for CONFIG_CACHY, so I'd assume it's not set.

Ok, sounds like something wrong with the kernel metadata, then. I'll try with another 6.5 kernel as soon as I get the chance.

Technologicat commented 8 months ago

Update - I haven't had the time to install and test with an alternative kernel, sorry.

But the latest CoreFreq (pulled just now) compiles fine and works on kernel 6.5.0-10008-tuxedo. Did you change something? :)

Anyway, it's working again, so I think we can close this.

cyring commented 8 months ago

Update - I haven't had the time to install and test with an alternative kernel, sorry.

But the latest CoreFreq (pulled just now) compiles fine and works on kernel 6.5.0-10008-tuxedo. Did you change something? :)

Anyway, it's working again, so I think we can close this.

Great news but nothing has changed to solve your issue.

Going back to my comment:

But your 6.5.0-10005-tuxedo is wrongly going through the case lower than 6.3

I presume one of your distribution updates has fixed that kernel source code inconsistency.

Regards

Technologicat commented 8 months ago

That's curious. Well, if the distributors fixed the kernel source package, that's the proper solution anyway - no need to make changes to CoreFreq for this.

Thanks for the support!