Bug description
On a Framework Desktop (AMD Ryzen AI Max 300 Series), the APU fan (fan1 under the cros_ec hwmon driver) spins during UEFI/POST but, without userspace fan control, stops immediately once Linux takes over. The EC continues to report a nonzero fan1_target, while fan1_input remains 0 RPM indefinitely. fan1_fault does not assert.
The fan, cabling, and EC PWM path appear healthy: sudo framework-tool --fansetduty 100 immediately drove the fan to approximately 1690 RPM. This points to the EC automatic fan-curve/OS-handoff behavior rather than a hardware failure.
Environment
- Hardware: Framework Desktop (AMD Ryzen AI Max 300 Series), mainboard revision
MassProduction
- UEFI BIOS:
03.06 (2026-07-13)
- EC firmware:
dogwood-3.0.6-bb3566e (2026-07-07)
- OS: Ubuntu 26.04
- Kernel:
7.0.0-30-generic
- framework-tool:
0.6.1
Reproduction / observed behavior
- Boot the system normally.
- Do not run a userspace fan-control daemon.
- Observe
cros_ec hwmon values after the OS takes control.
Observed during the failure:
fan1_input: 0 RPM
fan1_target: 926 RPM
fan1_fault: 0
The fan had operated normally during firmware POST before the OS handoff.
Expected behavior
The EC should enforce its automatic fan curve after Linux takes control. A nonzero fan1_target should correspond to a running fan, and a sustained commanded-but-stalled fan should report a fault.
Current mitigation
fw-fanctrl is enabled as a userspace workaround and is intentionally left running for thermal safety. With it active, current readings show fan1_input=734 RPM and fan1_target=926 RPM, so I have not stopped it merely to reproduce the stall again.
Related report
This resembles the earlier Framework Laptop 13 AMD community report: CPU Fan not spinning up until I reboot. This report adds a Framework Desktop / Ryzen AI Max 300 data point.
Bug description
On a Framework Desktop (AMD Ryzen AI Max 300 Series), the APU fan (
fan1under thecros_echwmon driver) spins during UEFI/POST but, without userspace fan control, stops immediately once Linux takes over. The EC continues to report a nonzerofan1_target, whilefan1_inputremains 0 RPM indefinitely.fan1_faultdoes not assert.The fan, cabling, and EC PWM path appear healthy:
sudo framework-tool --fansetduty 100immediately drove the fan to approximately 1690 RPM. This points to the EC automatic fan-curve/OS-handoff behavior rather than a hardware failure.Environment
MassProduction03.06(2026-07-13)dogwood-3.0.6-bb3566e(2026-07-07)7.0.0-30-generic0.6.1Reproduction / observed behavior
cros_echwmon values after the OS takes control.Observed during the failure:
The fan had operated normally during firmware POST before the OS handoff.
Expected behavior
The EC should enforce its automatic fan curve after Linux takes control. A nonzero
fan1_targetshould correspond to a running fan, and a sustained commanded-but-stalled fan should report a fault.Current mitigation
fw-fanctrlis enabled as a userspace workaround and is intentionally left running for thermal safety. With it active, current readings showfan1_input=734 RPMandfan1_target=926 RPM, so I have not stopped it merely to reproduce the stall again.Related report
This resembles the earlier Framework Laptop 13 AMD community report: CPU Fan not spinning up until I reboot. This report adds a Framework Desktop / Ryzen AI Max 300 data point.