[Support Request] `corefreqk` unloads when `corefreqd` daemon starts on Zen 5 with `amd_pstate` (built with `ARCH_PMC=UMC`)

Hello @cyring, I am experiencing an issue on my AMD Zen 5 system where the `corefreqk` module unloads itself, but only at the exact moment the `corefreqd` daemon attempts to start. This appears to be related to the `amd_pstate` driver being active. I have built CoreFreq with the recommended `ARCH_PMC=UMC` flag, and have managed to isolate the exact sequence of events that triggers the failure. --- #### **1. System & Build Information** * **CPU**: AMD Ryzen (Zen 5 / Granite Ridge), 16 Threads * **OS**: Fedora (Kernel: `6.17.7-300.fc43.x86_64`) * **CoreFreq Version**: 2.0.8 (built from `master` branch) * **Build Command**: `make -j ARCH_PMC=UMC` (and also tested with my `akmod` package which passes this flag). * **CPU Frequency Driver**: `amd_pstate` --- #### **2. Sequence of Events & Diagnosis** I have discovered a precise cause-and-effect relationship: 1. **Manual Module Loading is Successful:** The module, compiled with `ARCH_PMC=UMC`, loads correctly on an idle system: ```bash $ sudo modprobe corefreqk $ lsmod | grep corefreq corefreqk 720896 0 ``` At this stage, the module loads and **remains loaded**. The `dmesg` log simply shows the successful processor identification, with no "Unload" message. 2. **Daemon Start Triggers the Unload:** The problem occurs the moment I try to start the `corefreqd` service: ```bash $ sudo systemctl start corefreqd.service ``` Immediately after running this command, the service fails, and `dmesg` shows the module unloading: ``` [ ... ] kernel: CoreFreq(12:-1:-1): Processor [ BF_44] Architecture [Zen5/Granite Ridge] CPU [16/16] [ ... ] kernel: CoreFreq: Unload ``` *(Note: The first line from processor identification might appear earlier when I run `modprobe`)* 3. **Result:** The `corefreqd` daemon fails with `exit-code 5`, and a subsequent `lsmod | grep corefreq` shows that the module is no longer loaded. This sequence reliably proves that the trigger for the module unload is the **initial communication attempt from the `corefreqd` daemon**, not the module loading process itself. --- #### **3. Context and Question** Researching other issues (like #378) suggests a potential conflict with the `amd_pstate` driver's access to SMU. It seems plausible that when `corefreqd` connects, the module performs an initialization routine that conflicts with `amd_pstate`. My question is: Given that I am using the correct `ARCH_PMC=UMC` build flag, what specific check or operation is performed by the `corefreqk` module upon the daemon's first connection that could be failing when `amd_pstate` is active? I would like to find a way for them to coexist, as `amd_pstate` is important for my setup. I am fully prepared to build a debug version (with `FEAT_DBG`) and provide detailed logs to help diagnose the root cause. Thank you for your guidance.