SER9 Pro (HX 370) — fan stuck at max speed after resume from suspend (S0i3)

kavboy

I own a Beelink SER9 Pro (Ryzen AI 9 HX 370, BIOS/EC T408), running Fedora Linux, and I’d like to report a confirmed and diagnosed bug: after resume from suspend (s2idle/S0i3), the fan gets stuck at high/maximum RPM and stops responding to CPU temperature, until the machine is fully rebooted.

Reproduction (A/B tested):

Fresh boot: fan is quiet at idle (32°C), ramps up under load, calms down as it cools — the fan curve works correctly.
After any suspend/resume cycle: fan runs at fixed high RPM — noticeably higher than a fresh boot under full CPU load — and does not react to temperature at all afterward.

What I ruled out:

BIOS fan curve settings are correct and applied properly on cold boot (Fan off <40°C, start 45°C, full 90°C). Switching CPU Smart Fan Mode to Manual or Full-on in BIOS does not help (Manual/Full-on only makes it worse; the bug persists regardless of mode).
This is not a Linux driver gap in the usual sense — there are no pwm/fan nodes in hwmon at all, no ACPI fan objects, and platform_profile is unavailable. Fan control is fully internal to the EC firmware with no exposed interface.

ACPI/DSDT investigation (2026-07-11):
I dumped and decompiled the full ACPI tables (acpidump → acpixtract → iasl -d, DSDT + 28 SSDTs) specifically looking for any fan-control ACPI object I could invoke manually (e.g., via acpi_call) to force the EC to reapply the fan curve after resume, as a workaround. Findings:

No standard ACPI fan-control objects (FIF/FPS/_FST) exist anywhere in the tables.
The THERMAL0 SSDT only exposes a ThermalZone (TZ01) used for CPU passive-cooling/throttling policy (TMP/PSL/_CRT), not physical fan speed control.
The only EC register exposed to ACPI (OperationRegion (ECRM, EmbeddedControl, Zero, 0xFF)) names a single byte at offset 0xCC (PBCN, appears power-button related) — the rest of the 256-byte EC address space is completely unnamed/unexposed to ACPI.
No _Qxx (EC Query) method in the DSDT references fan/PWM in any way.

Conclusion: there is no software-side hook (ACPI, kernel, or otherwise) available to work around this — fan control after resume is entirely governed by closed EC firmware logic that simply fails to reapply the configured fan curve on wake. This can only be fixed in an EC firmware update.

Ask: could you confirm whether this is a known issue being tracked for T408 (or a future EC revision), and whether there’s an ETA for a fix? Happy to provide further diagnostics (dmesg, ACPI dumps, etc.) if useful for your firmware team.

Beelink CS-June

kavboy

Hello there,

Could you please send us a picture of SN code(two lines) at the bottom of machine?

Then we will send you the lastest BIOS file to try to solve the problem.

Have a nice day~

kavboy

My SN:

Beelink CS-June

kavboy

Hello there,

Thanks for your reply~

I have sent you the lastest BIOS file, please check your PM.

Have a nice day~

kavboy

Update: reproduced on EC/BIOS T409 as well
I updated to the firmware from PM, this is T409 (build 2026-06-23). The bug reproduces identically:

Fresh boot: fan curve works correctly (quiet at idle, ramps with load, calms down on cooldown).
After suspend/resume (s2idle/S0i3): fan stuck at high RPM again, unresponsive to temperature, until a full reboot.

kavboy

I also diagnosed a related sleep issue: pressing Sleep doesn’t actually put the machine to sleep. The screen turns off and almost immediately back on, the system keeps running, and the fan spins up louder afterward even though CPU temperature hasn’t changed.

Diagnosis:

/sys/power/suspend_stats/last_hw_sleep stayed around 85ms per sleep attempt — essentially an instant wake, not a real sleep cycle.
Using pinctrl-amd dynamic debug (echo "file pinctrl-amd.c +p" > /sys/kernel/debug/dynamic_debug/control) and reading /sys/kernel/debug/gpio, I traced it to GPIO pin 3 on the AMDI0030:00 GPIO controller — it’s armed for S0i3 wake (via the firmware’s _AEI table) and self-triggers roughly every 1 second, immediately pulling the system out of s2idle.
A secondary, minor contributor: a phantom i8042 KBD port (no physical PS/2 keyboard exists on this hardware) was also armed for wakeup and occasionally fired via IRQ1/GPE10 — disabled separately via udev, though GPIO 3 was the dominant/consistent trigger across every test.

Workaround (works, OS-side only):

gpiolib_acpi.ignore_wake=AMDI0030:00@3

kernel command-line parameter that masks this pin from being armed as a wake source. After applying it, last_hw_sleep matches the requested sleep duration (tested with rtcwake -m mem -s 12 → 11.2s measured), confirming a genuine hardware sleep.

Ask: could this GPIO wake entry be reviewed on the firmware/DSDT side? Pin 3 on this controller doesn’t appear to correspond to any real wake input (power button, lid, WoL — none of those use it, as far as I can tell), and masking it from the OS loses no functionality while completely fixing suspend. If this could be corrected at the DSDT/EC level, users wouldn’t need the kernel workaround at all. It may also share a root cause with the fan-after-resume bug, if firmware state handling around wake/resume is broadly unreliable.

Beelink CS-June

kavboy

Hello there,

Add the GRUB kernel parameter to GRUB_CMDLINE_LINUX in /etc/default/grub:
gpiolib_acpi.ignore_wake=AMDI0030:00@3
Then run sudo grub2-mkconfig -o /boot/grub2/grub.cfg (for UEFI) or the corresponding path.
Simultaneously disable the virtual i8042 wake source:
Create a rule in /etc/udev/rules.d/ to block IRQ1/GPE10 triggers.
Temporary workaround for fan control:
Manually manage fan speeds in Linux using fancontrol (lm-sensors + pwmconfig).
Or switch to the T407 BIOS (versions prior to T408).

At the same time, we will also ask our R&D team to attempt to reproduce the problem and find a solution.

Have a nice day~

kavboy

I followed the advice from your reply and rolled back from T409 to T407, in addition to the OS-side sleep fixes I already had applied (kernel parameter gpiolib_acpi.ignore_wake, udev rule for the phantom i8042 device).

Sleep test: rtcwake -m mem -s 12 — genuine hardware sleep (s2idle) confirmed by the kernel log. After resume, fan speed stayed just as low — it no longer gets stuck at maximum.

However, I’m now seeing a other unexpected result: the fan doesn’t stop at all during sleep, and power draw in sleep mode is 8W. Meanwhile, idle (no load, not sleeping) was 12W!

Could you please look into this — sleep mode is effectively still useless, just for a different reason now.

Thanks for understanding!