FIXED. Chat & Screens & Benchs: Various Intel Gen CPUs & X570 + Ryzen 3rd Gen

[olejon]

• make fails on Linux 4.15.0-52-generic, current latest kernel for Ubuntu 18.04 LTS 64-bit, with Vanilla GNOME (used as developer and main workstation + some server services)
• The package intel-microcode was also updated recently
• Straight forward unlocked SkyLake Workstation CPU: Intel Core i5-6600K
• Worked like a charm first time I installed CoreFreq
• Logically did not work after next kernel update, since CF kernel module was not compiled for it
• Compiled again and worked fine again
• BUT now, with Linux 4.15.0-52-generic, it fails with the error below
• Installed libelf-dev since make suggested to do so, and that warning goes away, but still build fails
• Has not bothered with adding it to dkms since make takes like 5 seconds on my system (seems like that was a good decision)
• Overclocked simply enabling Intel XMP in UEFI, which enables all cores to go to max TurboBoost ("sync all cores", 3.9 GHz under constant all cores max stress = temperature fine) + XMP automatically detects my XMP compatible 3200 MHz DDR4 RAM, and such sets correct values

$ make
...
make -j1 -C /lib/modules/4.15.0-52-generic/build M=/home/username/Downloads/CoreFreq modules
make[1]: Entering directory '/usr/src/linux-headers-4.15.0-52-generic'
  CC [M]  /home/username/Downloads/CoreFreq/corefreqk.o
/home/username/Downloads/CoreFreq/corefreqk.c: In function ‘SMBIOS_Collect’:
/home/username/Downloads/CoreFreq/corefreqk.c:9107:5: error: ‘DMI_PRODUCT_SKU’ undeclared (first use in this function); did you mean ‘DMI_PRODUCT_UUID’?
   { DMI_PRODUCT_SKU, Proc->SMB.Product.SKU },
     ^~~~~~~~~~~~~~~
     DMI_PRODUCT_UUID
/home/username/Downloads/CoreFreq/corefreqk.c:9107:5: note: each undeclared identifier is reported only once for each function it appears in
scripts/Makefile.build:337: recipe for target '/home/username/Downloads/CoreFreq/corefreqk.o' failed
make[2]: *** [/home/username/Downloads/CoreFreq/corefreqk.o] Error 1
Makefile:1552: recipe for target '_module_/home/username/Downloads/CoreFreq' failed
make[1]: *** [_module_/home/username/Downloads/CoreFreq] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.15.0-52-generic'
Makefile:70: recipe for target 'all' failed
make: *** [all] Error 2

I see you did varios SMBIOS 6 days ago. That is what failing it seems.

I haven't installed/purged or changed anything that should have anything to do with building from source code.

[cyring]

Will fix asap.
Some dmi might be available with latest kernel 5.x

[olejon]

Great :-)

[cyring]

Just checked (w/ Smartphone) the minimum Kernel version is 4.18.x for those missing definitions (DMI_PRODUCT_SKU,...)

I will refactor code using conditions to let previous versions build through.

Also thinking about writing myself parts of the DMI parsing to offer the remaining strings

[olejon]

I usually install the Ubuntu LTS Enablement Stacks once they are out (newer kernel and Xorg/Wayland/Mesa/etc for desktops and just newer kernel for servers).

Pretty sure the one's in the repo now is > 4.18. On my phone now.

https://wiki.ubuntu.com/Kernel/LTSEnablementStack

The 18.04.2 and newer point releases will ship with an updated kernel and X stack by default for the desktop. Server installations will default to the GA kernel and provide the enablement kernel as optional. The 18.04 HWE Stacks will follow a new Rolling Update Model as documented at the following location: https://wiki.ubuntu.com/Kernel/RollingLTSEnablementStack Installing the HWE stack is simple: DESKTOP sudo apt-get install --install-recommends linux-generic-hwe-18.04 xserver-xorg-hwe-18.04

ANYWAY most Ubuntu LTS users don't do this manually.

And my installation has been totally stable. The open shipped with amdgpu driver, which AMD maintains together with the community, is actually faster than installing their latest open one from their repo for exactly Ubuntu 18.04 so Ubuntu maybe optimize more or regression in later Mesa packages or other libs it updates, as it updates a ton of packages as well from the AMD repo, including Xorg stuff IIRC. The Pro driver is constantly beaten by the open one, also. Really don't need the Pro one anyway unless you do some specific stuff. I don't even need a dedicated GPU as I don't play games or use GPU-heavy software. Most of that does my Raspberry Pi's GPU in form of HW acceleration of my Terabytes of video stored on this exact workstation. Well the Android Emulator is one example, but the iGPU from Intel is waaaay good enough. Only difference I see is in glmark2 :P And of course vulkan-smoketest.

Basically bought it intrigued by reading about how open and good AMD GPUs have become on Linux (especially the first one meaning it'll only get better), with everything plug and play, making it open enough to ship with the kernel, and actually fully working with the community, which NVIDIA does not (just randomly sometimes, the open driver is a mess if you want to use that, gotta check that table with supporting this but not that for everything - the closed really good and faster still, but must be installed as a separate package, and Wayland compatibility well, dunno).

Basically supporting AMD :-)

And Intel since all their HW is dead stable out of the box on Linux, including iGPU, much easier basically than Windows, and they actively contribute to the kernel for people to make tools such as your own, and even have created an own super fast distro, not for your daily driver but if supported by your CPU fun to check out! It has its own package system, more and more packages, including full GNOME desktop, all vanilla packages compiled for max speed on Intel cipset MB and CPU. Rolling release IIRC,

[olejon]

BTW will install the above and check if I get to it before you do :) Don't worry, no rush for me.

Just gotta say CoreFreq, although praised in the article I found it in, was way above my expectations! You should try to get it into the Debian/Ubuntu repos (can use dkms to allow updates to latest tested stable version of your code - or fixed version is probably preferred by distro maintainers, updated when distro is, as long as you make a well tested deb package from latest code, as it is already feature rich as heck, and probably systemd service to get approval I suppose but that isn't that hard when FOSS...).

EDIT: Found CoreFreq here: https://medium.com/@datamove/over-clocking-under-linux-67d04cfb0974

[cyring]

Hello, for your tests, fix is committed.

[olejon]

Thanks for responding so fast and fixing. I will test soon, with the kernel mentioned in the issue.

[olejon]

Confirmed building as before and working on Linux 4.15.0-52-generic without installing the LTS Enablement Stacks.

• Ubuntu 18.04 LTS 64-bit with latest default desktop kernel and intel-microcode package

Thanks again!

I have a suggestion. Basically toggling NMI Watchdog on demand, because... NMI Watchdog is there for a reason, as far as I have read I do not want it off permanently on such an important workstation + server.

My solution:

I have created a script like this as /usr/local/bin/cf. I have added /usr/local/bin/cf to the whitelist using visudo so it does not require a password to run, so I can simply run sudo cf.

#!/bin/bash

### CF SCRIPT IS RUN

bash -c "echo 0 > /proc/sys/kernel/nmi_watchdog"

sleep 1

insmod /opt/corefreq/corefreqk.ko

sleep 1

/opt/corefreq/corefreqd &

sleep 2

su -l -c "/opt/corefreq/corefreq-cli" MYDESKTOPUSERNAME

### CTRL+C IS PRESSED TO STOP THE CLI

sleep 4

rmmod corefreqk.ko

sleep 1

bash -c "echo 1 > /proc/sys/kernel/nmi_watchdog"

The sleeps are necessary to give some time before starting and stopping. I have added a little extra because you never know. Sometimes it may fail to rmmod the module if only 2 seconds after quitting the cli, for instance. As you can see I copy the 3 necessary files to /opt/corefreq/ after make.

BTW: The reason for bash -c is that running echo X > Y does not work with sudo in these cases. Pages often suggest running sudo su first, but that is ugly, not for scripts made to avoid prompts, and just plain wrong. Those using sudo su should run sudo -s or sudo -i, depending on need. That is the right way, NEVER sudo su (some exceptions may exist, usually the first time doing something then never again).

Clue is NMI Watchdog toggle - on-demand - like:

When starting, first run:

bash -c "echo 0 > /proc/sys/kernel/nmi_watchdog"

When everything is stopped/unloaded, run as last command:

bash -c "echo 1 > /proc/sys/kernel/nmi_watchdog"

Kernel confirmes in dmesg and journalctl -b --no-pager that NMI Watchdog is enabled again with:

kernel: NMI watchdog: Enabled

Pretty sure you can deactivate/reactivate NMI Watchdog in corefreqd daemon on start/stop? At least it can be an option? People should at least know the consequences of NMI Watchdog off permanently, and that it can be toggled on-demand instead of kernel parameter.

Add it to README.md?