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

[minipcthinker]

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 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 ~1200 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 CPU loaded 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 are, 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.
• 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.
• Intentional Acoustic Tuning: Minisforum may have prioritized low noise levels over component longevity. However, even setting the fan to 100% in the BIOS fails to override the idle speed.
• EC Firmware Logic Gap: The EC might be programmed to trigger the secondary fan based on power supply load rather than RAM/SSD sensors.
• BIOS/EC Communication Bug: This is the most likely scenario. There appears to be a breakdown where the EC ignores manual fan values set in the BIOS.

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.
2. Disable Secure Boot.
3. In theory we should navigate to Hardware Monitor and set Auxiliary Fan to Manual but seems to work with any mode and the EC is never writing any value after the default value set after boot.

The Control Command (Linux)

• Executed

  sudo modprobe ec_sys write_support=1

  to enable 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 max speed).
• On my device <xx> is 48 (0x30 hex -> 48 decimal). I moved the value here to avoid accidental copy-pasting.

Note: These changes are volatile. If you reboot or enter Sleep, the EC will reset.

3. Detailed Investigation Timeline

Phase 1: Identifying the Delta

• Observation: During LLM sessions, the system was silent but RAM reached 70°C after 5 minutes.
• Finding: CPU/GPU was cool, but RAM was hitting 70°C. The secondary fan was locked at static 12xx RPM.

Phase 2: Testing "Safe" Workarounds

• Attempt: Reduced power limit from 54W to 45W. Result: Failure (only delayed heat-soaking).
• Attempt: "Busy Wait" script to artificially load CPU. Result: Worked but increased overall heat and wasted power.
• Attempt: Pausing Ollama at 65°C. Result: High efficiency (>85%) but constant thermal stress (+/- 5 degree cycles).

Phase 3: The Register Hunt

• Discovery: Register 0x30 responded directly to fan speed requests.
• Validation: By writing

  0x0e

  to

  0x64

  , the fan ramps from 1400 RPM to max speed. This keeps RAM <55°C even at highest load with only reaching a PWM cycle of around 30%.

4. Observations & Summary

• Gaming vs. AI: In games, GPU/CPU load triggers fans naturally; in AI/LLM workloads, the secondary zone is neglected.
• Critical Scenarios: Manual fix is essential for high intensive RAM tasks or heavy I/O where CPU is idle.
• Link: Python PID controller implementation for the auxiliary fan.

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

 

[ignsvn]

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 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 ~1200 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 CPU loaded 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 are, 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.
• 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.
• Intentional Acoustic Tuning: Minisforum may have prioritized low noise levels over component longevity. However, even setting the fan to 100% in the BIOS fails to override the idle speed.
• EC Firmware Logic Gap: The EC might be programmed to trigger the secondary fan based on power supply load rather than RAM/SSD sensors.
• BIOS/EC Communication Bug: This is the most likely scenario. There appears to be a breakdown where the EC ignores manual fan values set in the BIOS.

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.
2. Disable Secure Boot.
3. In theory we should navigate to Hardware Monitor and set Auxiliary Fan to Manual but seems to work with any mode and the EC is never writing any value after the default value set after boot.

The Control Command (Linux)

• Executed

  sudo modprobe ec_sys write_support=1

  to enable 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 max speed).
• On my device <xx> is 48 (0x30 hex -> 48 decimal). I moved the value here to avoid accidental copy-pasting.

Note: These changes are volatile. If you reboot or enter Sleep, the EC will reset.

3. Detailed Investigation Timeline

Phase 1: Identifying the Delta

• Observation: During LLM sessions, the system was silent but RAM reached 70°C after 5 minutes.
• Finding: CPU/GPU was cool, but RAM was hitting 70°C. The secondary fan was locked at static 12xx RPM.

Phase 2: Testing "Safe" Workarounds

• Attempt: Reduced power limit from 54W to 45W. Result: Failure (only delayed heat-soaking).
• Attempt: "Busy Wait" script to artificially load CPU. Result: Worked but increased overall heat and wasted power.
• Attempt: Pausing Ollama at 65°C. Result: High efficiency (>85%) but constant thermal stress (+/- 5 degree cycles).

Phase 3: The Register Hunt

• Discovery: Register 0x30 responded directly to fan speed requests.
• Validation: By writing

  0x0e

  to

  0x64

  , the fan ramps from 1400 RPM to max speed. This keeps RAM <55°C even at highest load with only reaching a PWM cycle of around 30%.

4. Observations & Summary

• Gaming vs. AI: In games, GPU/CPU load triggers fans naturally; in AI/LLM workloads, the secondary zone is neglected.
• Critical Scenarios: Manual fix is essential for high intensive RAM tasks or heavy I/O where CPU is idle.
• Link: Python PID controller implementation for the auxiliary fan.

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

Thanks for the hardwork, this is going to be useful for many.

You also mentioned "...These changes are volatile. If you reboot or enter Sleep, the EC will reset.", so it would probably better if you add it into a bash script that runs on startup like:

@reboot /usr/bin/python3 /home/user/myscript.py &

(Don't quote me on that bash script above, I'm not a bash expert & it's just an example taken from the internet)

 

[minipcthinker]

Yes, you are right, something like that is needed.
The solution that worked for me was to create a new user for this, allow it to use sudo dd (without password) and create a service to run the script.

In this way the user has its own rights and sandbox, can only sudo this specific dd command. It is started every boot and if crashes is restarted after 5 seconds again.