How I Got a 56% Temperature Drop using udev Rule — No ACPI

• UPDATE This procedure works on LMDE7 “Gigi”, and the upgrade worked flawlessly, and left all the udev rules intact. The temperature is still down. At this point, this tutorial will apply to Gigi, so give it a try — and let me know. Also, after reading the many thermal issues on a range of PCs, Lenovo, Asus, etc, this fix would most likely be applicable to any system with buggy or incomplete ACPI tables in the BIOS.*

Background After deploying two MoreFine S500+ Mini-PCs in late 2024, with Windows 11 Pro installed, I realized the fan was going all the time and the casing was hot to touch. I installed FanControl, a free Windows program, and set the thresholds and the temperature curve, and locked the CPU frequency to 3.00GHz. The other unit is completely different story: I installed Debian 12, and thermal issues appeared — Debian froze within minutes. Then Linux Mint was better but not by much. Then I tried Linux Mint Debian Edition 6 “Faye”, which lasted the longest, but ultimately crashed after 95°C. Rather than keep distro-hopping to find something that doesn’t cook the PC, I decided to fix it once and for all, even though I had no idea what I was getting myself into. I ran Debian web servers for decades before retiring, so I decided to take up the challenge with LMDE6, mainly due to the sheer volume of rich documentation/support for Linux Mint and Debian. I tried changing the settings in BIOS ACPI by disabling both ACPI Auto Configuration and Suspend to RAM S3. The system lasted much longer, but the fan was constantly running and it froze after an hour. I searched on every site until I discovered that the AMD Cezanne architecture and ACPI implementation had known issues on this hardware. MoreFine’s engineers assured me they have a large base of Debian users and I have the current BIOS, as documented further into this article. ACPI: I use the term “ACPI disabled”, that’s just my shorthand for “ACPI S3 suspend to RAM and and other power management features disabled in BIOS. If one were to completely disable ACPI the computer wouldn’t most boot.For me, BIOS and UEFI/BIOS are used interchangeably. What I actually disabled were specific ACPI features that triggered system freezes on the hardware. Infrastructure: LMDE6 with btrfs, grub-btrfs, inotify-tools, and Timeshift snapshots turned out to be the best thing I could do to help troubleshooting. The ability to roll back to pre-freeze snapshots from the GRUB menu helped me a lot. My partition layout is documented here for reference. This guide documents my complete solution. While written for the MoreFine S500+, I can’t see why it wouldn’t work on other systems plagued with ACPI-related issues on AMD Ryzen mobile processors with this unpatched BIOS version. System Specification Components: Hardware: MoreFine S500+ Mini-PC CPU: AMD Ryzen 9 5900HX (8-core/16-thread, base 3.3 GHz, boost 4.6 GHz) Distribution: Linux Mint Debian Edition 6 (LMDE6) “Faye” Kernel: 6.1.0–40-amd64 UEFI/BIOS: American Megatrends v1.10_P4C3M43_MoreFine_VC3 (2023–09–13) Filesystem: btrfs-root Boot Manager: GRUB with grub-btrfs giving a list of bootable snapshots Issue: CPU fan spinning excessively while only doing light workloads (browsing, typing) Root Cause: ACPI S3 and power management features had to be disabled in UEFI/BIOS to stop the system freezes, likely related to known AMD Cezanne/Renoir ACPI issues documented in 2020–2023. Constraint: Can’t rely oncpupower, CPU governors, or standard ACPI-based power management tools without it freezing. Important Context: I am using kernel 6.1. Newer kernels (6.8+, 6.12+) may have solved these ACPI issues. I recommend you test with updated kernels before trying this workaround. Purpose This guide serves as: Deployment standard for MoreFine S500+ units Learning tool for understanding thermal management with limited ACPI functionality Troubleshooting reference for similar AMD Ryzen mobile systems with ACPI-related issues Technical documentation of problem-solving methodology Quick Deployment Checklist For rapid deployment across MoreFine S500+ units: [ ] Verify UEFI/BIOS version (should be v1.10_P4C3M43_MoreFine_VC3 or similar) [ ] Update to latest BIOS if available (may resolve ACPI issues entirely) [ ] Test with latest kernel first (6.12+) before disabling ACPI features [ ] If freezing persists, disable ACPI S3 suspend in UEFI/BIOS [ ] Check baseline temperatures (should be 38–50°C idle) [ ] Create udev rule: sudo nano /etc/udev/rules.d/99-disable-cpu-boost.rules [ ] Reload udev rules: sudo udevadm control — reload-rules [ ] Verify boost disabled: cat /sys/devices/system/cpu/cpufreq/boost

returns 0 [ ] Test: Open 20+ browser tabs, confirm fan stays quiet [ ] Reboot and re-verify boost remains disabled [ ] Install psensor: sudo apt install psensor [ ] Add temperature alias to ~/.bashrc (optional) [ ] Document device serial number and deployment date Once you understand the process, you should be able to implement this in 15 minutes. Step 1: Check Current Temperatures First, verify your baseline temperatures: Quick temperature check cat /sys/class/hwmon/hwmon/name Expected output: nvme, amdgpu, k10temp cat /sys/class/hwmon/hwmon/temp_input Expected output shows temperatures in millidegrees (divide by 1000) Install Basic Monitoring Tools sudo apt install lm-sensors Run sensor detection (say NO to AMDGPU-related I2C adapters to avoid potential ACPI conflicts): sudo sensors-detect Note: If sensors-detect finds no sensors, that’s ok for newer AMD systems. The kernel drivers already provide temperature data directly through the hwmon interface. Step 2: Test CPU Boost Disable Check current boost status: cat /sys/devices/system/cpu/cpufreq/boost Output: 1 means boost is enabled, 0 means disabled. Temporarily disable boost: echo 0 | sudo tee /sys/devices/system/cpu/cpufreq/boost Monitor the results: Watch temperatures in real-time (Ctrl+C to exit) watch -n 2 ‘for i in /sys/class/hwmon/hwmon/; do echo “$(cat ${i}name): $(cat ${i}temp*_input 2>/dev/null | awk ‘\’’{print $1/1000 “°C”}’\’’)”; done’ Test: Open multiple browser tabs and continue normal usage. The fan should remain quiet or stop entirely. Step 3: Make CPU Boost Disable Permanent Once confirmed the fan stays quiet, make the change permanent using a udev rule. Create udev rule: sudo nano /etc/udev/rules.d/99-disable-cpu-boost.rules Paste this line: SUBSYSTEM==”cpu”, ACTION==”add”, RUN+=”/bin/sh -c ‘echo 0 > /sys/devices/system/cpu/cpufreq/boost’” Save and exit (Ctrl+X, Y, Enter), assuming you use nano Reload udev rules: sudo udevadm control — reload-rules Verify it’s working: cat /sys/devices/system/cpu/cpufreq/boost Should show: 0 Test persistence: sudo reboot After reboot, immediately check: cat /sys/devices/system/cpu/cpufreq/boost Should still show: 0 Step 4: Install GUI Temperature Monitor Install Psensor for real-time graphical monitoring: sudo apt install psensor Launch Psensor: psensor Configure Psensor: Preferences → Check “Display sensor in the label” Preferences → Check “Launch on session startup” Set temperature alert thresholds if desired (85°C for warning, 95°C for critical) Psensor will display: CPU temperature (k10temp) GPU temperature (amdgpu) NVMe SSD temperature Optional: CPU usage and memory usage Step 5: Add Temperature Monitoring Alias (Optional) I added an alias to ~/.bashrc for quick temperature checks: sudo nano ~/.bashrc Add this line at the end:

alias temp=’watch -n 2 ‘\’’for i in /sys/class/hwmon/hwmon/; do echo “$(cat ${i}name): $(cat ${i}temp_input 2>/dev/null | awk ‘\’\’\’\’’{print $1/1000 “°C”}’\’’\’\’’\’’)” ; done’\’’’ Save and reload: source ~/.bashrc Now you can type temps to monitor temperatures. (Ctrl+c to break) Expected Results Before (Boost Enabled): CPU frequency: Spikes to 4.0–4.6 GHz during browsing Temperatures: 55–70°C during light use Fan: Frequently spinning up, audible noise After (Boost Disabled): CPU frequency: Capped at ~3.3 GHz base frequency Temperatures: 38–50°C during light use Fan: Stays off or barely audible during browsing/typing Performance: Still plenty fast for everyday tasks — 16 threads at 3.3 GHz is more than sufficient for browsing, office work, coding, and light multitasking. Temporarily Re-enable Boost (If Needed) For demanding workloads like video encoding, gaming, or compiling: Enable boost temporarily echo 1 | sudo tee /sys/devices/system/cpu/cpufreq/boost Verify cat /sys/devices/system/cpu/cpufreq/boost After reboot, boost will be automatically disabled again by the udev rule. Permanently Re-enable Boost To remove the restriction completely: Remove the udev rule sudo rm /etc/udev/rules.d/99-disable-cpu-boost.rules Reload udev sudo udevadm control — reload-rules Reboot sudo reboot Why This Works (Technical Details) The Problem: Modern CPUs aggressively boost frequency for even minor workloads. The Ryzen 9 5900HX boosts from 3.3 GHz base to 4.6+ GHz for single-threaded tasks, generating significant heat for very little performance gain while browsing the web. The Solution: Disabling CPU boost (cpufreq/boost) prevents frequency scaling above base clock. This is a frequency cap that the CPU’s internal frequency controller respects. Why It Works with Limited ACPI: Minimal ACPI interaction: The boost disable uses a sysfs write that interacts primarily with the kernel cpufreq subsystem and CPU microcode No dynamic power state transitions: CPU stays active, just at lower frequency Simple frequency limit: The CPU’s internal P-state controller respects the boost disable flag Works with basic cpufreq: Requires only fundamental CPU frequency infrastructure, not full ACPI power management Why cpupower Failed: cpupower attempts to change CPU governors and power states using ACPI methods. On this hardware with ACPI S3 and power management features disabled, these transitions triggered system freezes. The exact ACPI methods causing the issue were not identified, but they’re invoked during governor changes. Technical Note on ACPI: The term “ACPI disabled” used in this document is shorthand for “ACPI S3 suspend and certain power management features disabled.” The system still uses ACPI for: Basic device enumeration (PCI, USB, etc.) Interrupt routing Thermal zone definitions CPU core enumeration What’s disabled are the specific ACPI methods that trigger system freezes on this hardware — related to P-state transitions, C-state management, or specific _PSS/_CPC ACPI methods. Why Use Udev Instead of GRUB Boot Parameters GRUB Configuration I decided to keep the GRUB configuration (/etc/default/grub) at default: GRUB_CMDLINE_LINUX_DEFAULT=”quiet” This clean, minimal configuration is optimal for this setup. Why I Considered and Rejected GRUB Parameters I tested several GRUB boot parameters:

❌ amd_pstate=passive or amd_pstate=active Why it failed: The amd_pstate driver may work better with newer kernels (6.3+) On kernel 6.1 with limited ACPI, this driver couldn’t reliably manage frequencies May have been attempting ACPI method calls that triggered freezes The older acpi-cpufreq driver proved more stable with disabled ACPI features Note: Users on kernel 6.6+ should test amd_pstate=guided as this may resolve issues entirely.

❌ cpufreq.default_governor=powersave Why it failed: Governor transitions invoke ACPI methods to change P-states These transitions triggered the same freezing behavior as cpupower Not reliable when ACPI power management features are disabled

❌ processor.max_cstate=1 or C-state limitations Why rejected: C-states (CPU sleep states) require ACPI support With ACPI S3 disabled, C-state parameters may conflict or be ignored Not applicable to the specific freezing issue encountered

Why the Udev Rule Approach Proved Superior ✅ Works through kernel sysfs interface Direct interaction with cpufreq subsystem Minimal ACPI dependency for basic frequency capping Simple file write to /sys/devices/system/cpu/cpufreq/boost

✅ Triggers after hardware initialization

Udev rules execute after CPU subsystem is fully initialized Ensures the boost control interface is available Proper timing without early-boot complications

✅ Clean separation of concerns UEFI/BIOS: Handles fundamental hardware initialization GRUB: Boots normally without conflicting parameters Kernel: Loads with standard drivers Udev: Applies the boost disable after boot completes

✅ Safe and Easily Reversed Worst case: Rule doesn’t apply, system still boots normally Easy to verify: Check /sys/devices/system/cpu/cpufreq/boost value Easily removed: Delete one file and reload udev rules No risk of boot loops

✅ Single-purpose and transparent Does one thing: disables CPU boost Easy to understand and troubleshoot No hidden side effects Optimal Configuration Stack ┌─────────────────────────────────────┐ │ BIOS: ACPI S3/PM features disabled │ ← Hardware level │ (Due to freeze issues) │ └─────────────────────────────────────┘

┌─────────────────────────────────────┐ │ This layered approach ensures: │ │ GRUB: Clean default config │ ← Bootloader level │ GRUB_CMDLINE_LINUX_DEFAULT=”quiet” │ └─────────────────────────────────────┘ ↓ ┌─────────────────────────────────────┐ │ Kernel: Standard drivers, no │ ← OS level │ special parameters │ └─────────────────────────────────────┘ ↓ ┌─────────────────────────────────────┐ │ Udev: Disables CPU boost via sysfs │ ← Userspace level │ after hardware ready │ └─────────────────────────────────────┘

Every component operates within its own domain No conflicting instructions between layers Maximum compatibility with limited ACPI functionality Easy troubleshooting (verify each layer independently) If ACPI Were Fully Functional Only if ACPI power management worked properly would these GRUB parameters be useful: GRUB_CMDLINE_LINUX_DEFAULT=”quiet amd_pstate=guided” Or: GRUB_CMDLINE_LINUX_DEFAULT=”quiet cpufreq.default_governor=powersave” These would enable proper CPU frequency scaling and power management through ACPI. But on this hardware with the current kernel, these parameters either caused freezes or were ineffective.

My Key Takeaway The reason I chose the udev rule approach is because it did not depend on ACPI methods: Identified that specific ACPI features trigger system freezes Ruled out ACPI-dependent solutions (cpupower, governors, most GRUB parameters) Found the kernel interface requiring minimal ACPI: cpufreq/boost Implemented via udev to ensure proper timing and persistence

Troubleshooting Boost re-enables after reboot Check if the udev rule exists and has correct permissions:

ls -l /etc/udev/rules.d/99-disable-cpu-boost.rules cat /etc/udev/rules.d/99-disable-cpu-boost.rules Verify udev rules are loaded: sudo udevadm control — reload-rules sudo udevadm trigger Fan still runs with boost disabled Check if temperatures are actually high (>60°C) Review UEFI/BIOS fan curve settings (set to “Quiet” or “Silent” mode) Check for dust buildup in vents — regular cleaning is essential Consider reapplying thermal paste if temperatures remain high Ensure adequate ventilation — I removed rubber feet and elevated the unit for better airflow System feels slow This is expected — you’re limited to base frequency (3.3 GHz) For demanding tasks, temporarily re-enable boost Consider whether the task actually needs extra performance 16 threads at 3.3 GHz is still quite capable for most workloads Psensor shows no sensors Use the command-line monitoring alias instead, or check: ls /sys/class/hwmon/hwmon/temp_input cpupower still causes freezes after this fix This is expected and normal. The udev solution specifically avoids cpupower because: cpupower triggers ACPI methods that cause freezes on this hardware UEFI/BIOS has ACPI S3 and power management features disabled Do NOT re-enable these ACPI features, and do NOT use cpupower

Should I try newer kernels? Yes, absolutely. This solution was developed on kernel 6.1. The AMD Cezanne ACPI issues were addressed in various kernel updates. As stated in the update at the beginning of this tutorial, I have now tested this thoroughly on Linux lmde6 6.12.48+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.48–1 (2025–09–20) x86_64 GNU/Linux Kernel 6.3+: Improved amd_pstate driver Kernel 6.6+: Better ACPI handling for Ryzen mobile Kernel 6.12+: Further AMD platform improvements Before implementing this workaround, test with the latest available kernel. You may find that: ACPI can be fully enabled without freezes Standard power management tools work properly This entire guide becomes unnecessary Test procedure for newer kernels: Install newer kernel from backports or manually Re-enable ACPI features in BIOS Test for freezes with normal usage If stable, use standard power management instead of this workaround Verifying ACPI Tables To verify if the ACPI tables are complete, you can dump the ACPI Tables, then extract and analyze them, then decompile each file into human-readable form, as they are written in Microsoft Assembler Language (ALS). However, such investigation is beyond the scope of this document. We now have so many documented cases of Ryzen 5000 series (and some 3000 series) that are known to have problems with: Missing or incomplete CPPC (Collaborative Processor Performance Control) tables Broken _CPC (Continuous Performance Control) ACPI objects Missing _PSS (Performance Supported States) definitions This is known to cause: Poor CPU frequency scaling Thermal management issues Fans not responding properly to temperature CPU stuck at high frequencies even when idle Overheating under light loads Analysis of my ACPI Tables: Zero _CPC objects — searched all files, completely absent Zero _PSS objects — no P-state tables exist Zero _CST objects — no C-state definitions Stub processor objects only — P000-P00F exist but have NO power management methods

This Proves: The thermal issues aren’t a Linux bug or configuration error — they’re caused by incomplete ACPI tables in the BIOS. The MoreFine BIOS tells Linux “here are 16 CPU threads” but gives zero information about how to control their frequency, voltage, or power states.

The workaround succeeds because it bypasses ACPI entirely and writes directly to CPU hardware registers. It’s not a workaround — it’s a functional method to the control frequency on this system.

Known Compatible Hardware This solution was tested and confirmed working over a week:

Device CPU BIOS Version OS Status MoreFine S500+ AMD Ryzen 9 5900HX v1.10_P4C3M43_MoreFine_VC3 LMDE6 (kernel 6.1) ✅ Note for other systems: This solution may work on other AMD Ryzen mobile systems (Cezanne/Renoir architecture) experiencing similar ACPI-related freezing issues. However, always test with newer kernels first, as the root cause may have already been resolved.

Understanding the Problem-Solving Approach

1. Identifying the Problem Observed: Fan noise during light workloads Initial hypothesis: Thermal issue Investigation: Temperatures were actually acceptable (38–50°C) Root cause: Unnecessary CPU boost causing thermal spikes

2. Recognizing the Constraints Critical issue: ACPI S3 and power management features disabled due to freezing Implication: Cannot use most standard Linux power management tools Eliminated tools: cpupower, CPU governors, GRUB power parameters

3. Looking for Solutions Question: What can control CPU behavior with limited ACPI? Answer: Direct sysfs interfaces with minimal ACPI dependency

Discovery: /sys/devices/system/cpu/cpufreq/boost works reliably 4. Implementation Strategy Task: Make change persistent across reboots Tested approaches: systemd service (runs too early) rc.local (deprecated, timing issues) cron u/reboot (unreliable timing) udev rule (successful — triggers at correct time)

5. Validation Immediate test: Monitor fan behavior after change Thermal verification: Monitor temperatures under load Persistence test: Verify settings survive reboot Performance check: Ensure system remains responsive

6. Documentation Goal: Enable consistent deployment across multiple units Content: Not just commands, but rationale and context Structure: Problem → Analysis → Solution → Verification You can apply this problem-solving framework to similar hardware/software conflicts. However, always test with updated firmware and software first — many issues may have already been resolved in newer kernels and BIOS versions.

Common Questions and Answers Q: Will this damage my CPU by preventing boost? A: No. You’re capping frequency at the CPU’s rated base clock (3.3 GHz). The CPU is designed to run continuously at this frequency. Boost is optional, designed for brief performance spikes.

Q: Can I use this on battery power? A: The MoreFine S500+ is a desktop mini-PC. For laptops with similar issues, this should extend battery life by preventing unnecessary power consumption from boost.

Q: Will this affect video editing or I/O intensive tasks? A: Yes, you’ll see reduced single-threaded performance (10–25% slower). For such tasks, temporarily re-enable boost with: echo 1 | sudo tee /sys/devices/system/cpu/cpufreq/boost Q: Why not just set a lower fan curve in BIOS? A: Fan curves respond to temperature. Even with aggressive “quiet” fan curves, CPU boost generates heat spikes that trigger fan activation. Preventing boost prevents the heat spike entirely.

Q: Can I automate re-enabling boost for specific applications? A: Yes, advanced users can create scripts that enable boost when launching performance-intensive applications and disable it on exit. This is beyond the scope of this guide.

Q: Does this affect all CPU cores? A: Yes, boost disable affects all cores system-wide. All 8 cores (16 threads) operate at base frequency.

Q: What if I update my UEFI/BIOS? A: BIOS updates may: Fix the underlying ACPI issues (allowing you to re-enable ACPI features) Reset BIOS settings (requiring you to re-disable problematic features) Change boost behavior After updating BIOS: Test with ACPI fully enabled first If freezing persists, disable ACPI features again Verify the udev rule still works

Q: Should I try this before testing newer kernels? A: NO! The recommended approach is: Update to the latest stable kernel (6.12+ if possible) Iam on Debian 6.12.48–1 (2025–09–20) x86_64 GNU/Linux Update BIOS to latest version Test with ACPI fully enabled Only if problems persist, implement this workaround Performance Impact Summary Temperature Improvements Before (Boost Enabled): Peak temperatures: 95°C (thermal throttling) Idle: 55–70°C Fan: Constantly audible, often at maximum speed After (Boost Disabled): Peak temperatures: 65°C (no throttling) Idle: 39–42°C Fan: Silent during normal use Temperature reduction: 53°C (56% improvement at peak) Performance Trade-offs Single-threaded performance: -10% to -25% depending on workload Multi-threaded performance: Minimal impact (all cores still run at 3.3 GHz) Typical use cases (web browsing, office work, coding): No noticeable performance difference Heavy workloads: Temporarily re-enable boost as needed

References and Additional Reading AMD Ryzen Mobile Issues Known ACPI issues in Cezanne (Ryzen 5000 mobile) and Renoir (Ryzen 4000 mobile) architectures, documented from 2020–2023. Symptoms include system freezes during power state changes, random reboots, and USB disconnections. Many issues were addressed in kernel 6.3+. Linux Power Management Documentation Kernel CPUfreq documentation: https://www.kernel.org/doc/Documentation/admin-guide/pm/cpufreq.rst CPU frequency scaling: https://wiki.archlinux.org/title/CPU_frequency_scaling Udev rules: https://wiki.archlinux.org/title/Udev

Related Tools lm-sensors: Hardware monitoring (https://github.com/lm-sensors/lm-sensors) psensor: Temperature monitoring GUI (https://github.com/chinf/psensor/)

Summary ✅ Workaround solution that minimizes ACPI interaction ✅ Permanent fix via udev rule ✅ Quiet operation during everyday tasks ✅ Cool temperatures maintained ✅ No performance loss for normal workloads ✅ Easily reversed if needed ⚠️ Test with newer kernels first — this may not be necessary on newer kernels 6.12+ ⚠️ Update BIOS — newer firmware may resolve ACPI issues entirely

Future Testing I have now tested on the latest LMDE7 “Gigi” based on Debian 13, and can confirm: The newer kernel has NOT resolved ACPI issues ACPI features can NOT be re-enabled without freezing Standard power management tools work properly This workaround becomes obsolete

Feel free to correct me, make suggestions or improvements. It worked for me, and now I can help many other. It is so hard to know how many devices have been affected, but this solution is reproducable and affective.

I’m particularly interested in: Verification of ACPI table completeness using acpidump/iasl Testing results with newer kernels 6.12+ Experiences with newer BIOS versions Test results with LMDE7 (Gigi) Beta Similar issues with other AMD Ryzen mobile hardware. Thanks for staying until the end. I know it’s a long read, but it may save you having to buy a new gaming PC.