Technical Investigation: Secondary Fan Control Inconsistency (Minisforum AI Pro HX 370)

Device: Minisforum AI Pro HX 370 - BIOS: v1.06

⚠️ MANDATORY DISCLAIMER

PROCEED WITH EXTREME CAUTION. This is an ongoing investigation, and the findings below are experimental. I take no responsibility for broken hardware, bricked BIOS, or thermal damage.

• Do not follow these instructions.
• Check everything yourself before executing commands.
• Modifying Embedded Controller (EC) registers can lead to permanent hardware failure.

1. The Core Problem: The "Silent" Thermal Trap

The HX 370 uses a dual-fan design. Through testing I discovered a thermal disconnect:

• The Logic: The system’s default fan curve stays always in IDLE (around 12xx RPMs).
• The Flaw: In workloads with heavy RAM operations (like Ollama, LLMs), or high-speed SSD data transfers, the CPU often remains relatively cool.
• The Result: The secondary fan (which cools the RAM and NVMe drives) stays at an idle ~1400 RPM. This causes the RAM and SSD to heat-soak, often hitting 75°C+, which can lead to instability or hardware degradation while the device remains deceptively quiet.
• The CPU Fan: works as expected and reacts to the CPUloaded changes, if the CPU is loaded the fan reacts and indirectly cools RAM and SSD.
• Trap: when the CPU is not loaded but RAM and or SSD those parts suffer since only idle cooling is provided.

1.1. Possible reasons why this may be happening

• Isolated Hardware Issue: This could be a defect specific to my unit. I am looking for feedback from other HX 370 owners to confirm if this is a widespread behavior or an isolated hardware failure.
• Missing Linux Driver Support: There is a possibility that a proprietary Minisforum driver handles this fan logic in Windows. Without an equivalent driver in GNU/Linux, the EC may not be receiving the necessary thermal data for the secondary zone.
• Intentional Acoustic Tuning: Minisforum’s marketing or teams may have prioritized low noise levels over component longevity. However, this is questionable since even setting the fan to 100% in the BIOS fails to override the idle speed.
• EC Firmware Logic Gap: The Embedded Controller (EC) software might be programmed to only trigger the secondary fan based on power supply load rather than the actual temperature sensors of the RAM or SSD. If the power draw is low but the data intensity is high, the EC "misses" the thermal event.
• BIOS/EC Communication Bug: This is the most likely scenario. There appears to be a breakdown in the interface between the BIOS and the EC where:
  1. The EC ignores the manual fan values set in the BIOS.
  2. The EC logic fails to pull or act upon the thermal readings from the SSD and RAM sensors.

2. The Solution: Manual Override of the Secondary Fan

I have successfully gained control over the secondary fan using low-level register access.

Prerequisites

1. Enter BIOS: (Press Del at boot).
2. Disable Secure Boot: This is mandatory to allow the OS to write to the EC registers.
3. Fan Settings: Navigate to Hardware Monitor and set Auxiliary Fan to Manual (seems to work with any mode).

The Control Command (Linux)

• Executed sudo modprobe ec_sys write_support=1 to enable the access to /sys/kernel/debug/ec/ec0/io.
• To Write a new value (Example: Set to 100% duty cycle): sudo printf '\x64' | sudo dd of=/sys/kernel/debug/ec/ec0/io bs=1 seek=<xx> count=1 conv=notrunc (Note: 0x64 is 100 in decimal, representing maximum speed).
• On my device <xx> is 48. Since this command is risky (see disclaimer at the beginning) I moved the value to this line to avoid anyone simply copying and pasting without checking.

Note: These changes are volatile. If you reboot or the system enters Sleep, the EC will likely reset to default values. You will need to re-run the dd command to re-engage your custom speed.

3. Detailed Investigation Timeline

Phase 1: Identifying the Delta

• Observation: During LLM inference sessions, the system was silent, but the RAM felt hot reaching 70 degrees after only 5 minutes.
• Command: Used sensors to monitor the (RAM) and nvme-pci (SSD) and other temps.
• Finding: CPU/GPU was cool, but RAM was hitting 70°C. The secondary fan was locked at a static 12xx RPM (I am guessing based on the sound and comparing while in BIOS where you can see the RPMs).

Phase 2: Testing "Safe" Workarounds

• Attempt: Reduced the System Configuration power limit from 54W to 45W in BIOS.
• Result: Failure. This only delayed the heat-soaking a few minutes; it didn't solve the lack of airflow over the components.
• Attempt: Created a "Busy Wait" script to artificially load the CPU in C doing nothing in some CPU cores.
• Result: This successfully ramped up the fans, keeped the RAM indirectly at 65 degrees but was increasing other temperatures in other parts and also was a waste of power in general.
• Attempt: Pause Ollama when reaching the RAM 65 degrees and restarting at 60.
• Result: was having an efficiency of >85% (time running vs cooling) but this puts the RAM also in high stress every few minutes with constants +5 -5 +5 … degrees.

Phase 3: The Register Hunt

• Process: We monitored EC register changes while toggling "Manual" vs "Auto" in the BIOS and while shortly overloading the CPU.
• Discovery: Register 0x30 responded directly to fan speed requests. Not clear yet if it is the PWM register since it looks more like the look up table.
• Validation: By writing 0x00 to 0x64, the secondary fan can be ramped from 1400 RPM to ~xxxx+ RPM (maximal speed), dropping RAM temperatures. This fan is able to keep RAM <55 degrees even at the highest load. This was not possible for the CPU one.

4. Observations & Summary

• Gaming vs. AI: I guess in games and other scenarios, the GPU/CPU load naturally triggers the fans, making the issue less noticeable.
• Critical Scenarios: This manual fix looks for me (with the current information) essential for users running high intensive RAM tasks or heavy I/O where the CPU is not loaded.
• Next Steps: A lot.

Work in Progress. Please contribute your own sensor readings and register findings to this thread.