AMDGPU fan control broken on Fsync 6.11.2-201?

General
1

LACT doesn’t apply my customized fan curve on Fsync 6.11.2-201, leading to hotter than usual temps due to the fan not using my specified settings - e.g. staying at 0 RPM at 57°C despite having configured to run at 30% at 50°C. When I tried to make curve changes it gave me an error with something along the lines of could not read pp_od_clk_voltage.

Rolled back to a deployment running Fsync 6.10.8-201 and the saved fan curve is applied, and further changes made to it are also applied.

Affected packages in this upgrade (downgrade) transaction, for further info. I don't think anything other than the kernel packages are relevant though 
rpm-ostree db diff --changelogs
ostree diff commit from: rollback deployment (4d9f2378cc8067a7fbddb33aad7d477ee14db1f4df853c6f9bb512592bad41c3)
ostree diff commit to:   booted deployment (1a6108df9d3ffadf33d78feeb0d819be5cd00a380926076af0d1ed793a3e9dff)
Downgraded:
  codium 1.94.1.24283-el8.x86_64 -> 1.94.0.24281-el8.x86_64
  containers-common 5:0.60.4-1.fc40.noarch -> 5:0.60.2-2.fc40.noarch
  containers-common-extra 5:0.60.4-1.fc40.noarch -> 5:0.60.2-2.fc40.noarch
  hwdata 0.388-1.fc40.noarch -> 0.387-1.fc40.noarch
  javascriptcoregtk4.1 2.46.1-1.fc40.x86_64 -> 2.44.3-2.fc40.x86_64
  javascriptcoregtk6.0 2.46.1-1.fc40.x86_64 -> 2.44.3-2.fc40.x86_64
  kernel 6.11.2-201.fsync.fc40.x86_64 -> 6.10.8-201.fsync.fc40.x86_64
  kernel-core 6.11.2-201.fsync.fc40.x86_64 -> 6.10.8-201.fsync.fc40.x86_64
  kernel-devel 6.11.2-201.fsync.fc40.x86_64 -> 6.10.8-201.fsync.fc40.x86_64
  kernel-headers 6.11.2-201.fsync.fc40.x86_64 -> 6.10.8-201.fsync.fc40.x86_64
  kernel-modules 6.11.2-201.fsync.fc40.x86_64 -> 6.10.8-201.fsync.fc40.x86_64
  kernel-modules-core 6.11.2-201.fsync.fc40.x86_64 -> 6.10.8-201.fsync.fc40.x86_64
  kernel-modules-extra 6.11.2-201.fsync.fc40.x86_64 -> 6.10.8-201.fsync.fc40.x86_64
  mesa-dri-drivers 1:24.1.7-1.fc40.x86_64 -> 1:24.1.6-1.fc40.x86_64
  mesa-filesystem 1:24.1.7-1.fc40.x86_64 -> 1:24.1.6-1.fc40.x86_64
  mesa-libEGL 1:24.1.7-1.fc40.x86_64 -> 1:24.1.6-1.fc40.x86_64
  mesa-libGL 1:24.1.7-1.fc40.x86_64 -> 1:24.1.6-1.fc40.x86_64
  mesa-libgbm 1:24.1.7-1.fc40.x86_64 -> 1:24.1.6-1.fc40.x86_64
  mesa-libglapi 1:24.1.7-1.fc40.x86_64 -> 1:24.1.6-1.fc40.x86_64
  mesa-libxatracker 1:24.1.7-1.fc40.x86_64 -> 1:24.1.6-1.fc40.x86_64
  mesa-va-drivers 1:24.1.7-1.fc40.x86_64 -> 1:24.1.6-1.fc40.x86_64
  mesa-vulkan-drivers 1:24.1.7-1.fc40.x86_64 -> 1:24.1.6-1.fc40.x86_64
  mtools 4.0.45-1.fc40.x86_64 -> 4.0.44-1.fc40.x86_64
  python-pip-wheel 23.3.2-2.fc40.noarch -> 23.3.2-1.fc40.noarch
  python3-boto3 1.35.29-1.fc40.noarch -> 1.35.25-1.fc40.noarch
  python3-botocore 1.35.29-1.fc40.noarch -> 1.35.25-1.fc40.noarch
  qt6pas 6.2.8-30601.fc40.x86_64 -> 6.2.8-30401.fc40.x86_64
  rav1e-libs 0.7.1-4.fc40.x86_64 -> 0.7.1-2.fc40.x86_64
  selinux-policy 40.28-1.fc40.noarch -> 40.27-1.fc40.noarch
  selinux-policy-targeted 40.28-1.fc40.noarch -> 40.27-1.fc40.noarch
  unbound-anchor 1.21.1-3.fc40.x86_64 -> 1.20.0-1.fc40.x86_64
  unbound-libs 1.21.1-3.fc40.x86_64 -> 1.20.0-1.fc40.x86_64
  virtualbox-guest-additions 7.1.2-1.fc40.x86_64 -> 7.1.0-3.fc40.x86_64
  webkit2gtk4.1 2.46.1-1.fc40.x86_64 -> 2.44.3-2.fc40.x86_64
  webkitgtk6.0 2.46.1-1.fc40.x86_64 -> 2.44.3-2.fc40.x86_64
  xxhash-libs 0.8.2-4.fc40.x86_64 -> 0.8.2-2.fc40.x86_64

Just wanted to confirm if others are experiencing this too or give a heads’ up to others. Fsync 6.11.2-201 first finished building midnight UTC yesterday.

GPU model is AMD Navi 23 [Radeon RX 6600/6600 XT/6600M].

LACT version is 0.5.6-release (commit fa0eb30) on both kernel versions. The only (seemingly) relevant change is the kernel version.

2

Adding the LACT error message:

Screenshot from 2024-10-12 22-59-14

If anyone can lead me to the appropriate page where I can ask/notify the kernel team that’d be appreciated.

3

AMD told us to stop allowing overclocking OOTB and that kernel release is the first one to do it. If you rerun the install command for LACT It will apply the needed kernel argument to turn it back on.

4

Ah, I wasn’t aware of that! Dove into the just commands and located the relevant karg line, applied it to my system and everything works again now. Thanks for informing, Kyle!

5

That kernel hasn’t hit stable yet, so we will make an announcement when that happens.