Framework Desktop AMD: EC auto fan curve does not start fan1 after OS handoff #85

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

1. Boot the system normally.
2. Do not run a userspace fan-control daemon.
3. 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.