PC Fans Running at Full Speed or Ignoring Fan Curves: PWM/DC Mode, Headers, Sensors, BIOS, and Control Software

Start by identifying the physical fan, its connector path, and the condition that triggers the behavior. A CPU-cooler fan, radiator fan, case fan, pump, and fan connected through a separate controller may all be controlled by different hardware. Record whether the fan is always fast from power-on, becomes fast only after Windows loads, changes with CPU or GPU load, or ignores only one specific profile.

Do not treat “loud fan” and “fan-control failure” as the same observation. A firmware curve can legitimately request high speed from a selected temperature source, while a fan on the wrong control mode or a controller-owned channel may ignore the setting you are editing. If high fan speed accompanies abnormal CPU temperature, use the CPU-temperature troubleshooting workflow in parallel rather than assuming the curve itself is the root cause.

Follow the fan cable to the exact motherboard header or external controller. Motherboard labels such as CPU_FAN, CPU_OPT, CHA_FAN, SYS_FAN, AIO_PUMP, and pump-capable system headers can have different defaults and capabilities on different boards. A fan connected to a powered hub may receive power from the hub while one motherboard header supplies only the shared control signal.

Do not assume a setting for one header controls every connected fan. If a splitter or hub is involved, verify which channel provides the tachometer/RPM feedback and which device actually owns the PWM or voltage-control signal. Manufacturer documentation for the exact splitter, hub, controller, and motherboard takes priority over generic wiring assumptions.

An RPM reading is tachometer feedback; it is not the same thing as the control signal. A fan can report RPM while being commanded incorrectly, and a multi-fan splitter can intentionally return only one fan’s tach signal to avoid multiple RPM signals sharing the same input. Conversely, a missing RPM value does not by itself prove that every fan on that channel has stopped.

Use the firmware or controller interface to change only the intended channel and observe whether the physical fan responds. If the displayed RPM changes in a way that matches the physical fan, that establishes a useful mapping between the software channel and the hardware. Do not use a single RPM number as a universal pass/fail threshold because supported speed ranges differ by exact fan model.

Four-pin PC fans commonly expose a dedicated PWM control input, while three-pin fans can be speed-controlled only when the connected header supports voltage/DC regulation. Noctua documents that its three-pin fans can be used on four-pin motherboard headers, but controllability can require changing the board from PWM to Voltage/DC/Analog mode; it also notes that a four-pin PWM fan on a three-pin header may run at full speed unless that header supports voltage-based regulation.

Many current motherboards support PWM/DC auto-detection, but that is still a board-specific capability. ASUS documents current boards whose onboard fan headers auto-detect PWM or DC fans, while GIGABYTE documents Smart Fan 6 headers supporting both modes. Check the exact board manual before changing the mode. Do not apply arbitrary voltage values, PWM duty percentages, minimum-speed numbers, or header-current assumptions from another product.

A correct-looking curve can still behave unexpectedly if it is following a different temperature source from the one you are watching. Current motherboard firmware can expose multiple thermal sensors and per-header source selection. GIGABYTE Smart Fan 6, for example, documents configurable fan curves and temperature-input selection, while ASUS documents boards whose supported headers can reference multiple thermal sensors.

Confirm the selected source for the exact fan channel, then compare that source with the physical fan response. A case fan following CPU temperature can ramp rapidly during short CPU bursts even when GPU or motherboard temperatures remain steady. Do not invent a universally “best” sensor or curve: the appropriate source depends on what the fan is cooling, what the board/controller exposes, and the exact system layout.

If fan behavior changes only after the operating system loads, determine whether vendor software or a dedicated controller takes ownership. ASUS documents AI Cooling/Fan Xpert behavior that can override manual controls on supported motherboard-connected headers. Corsair documents iCUE fan profiles for supported Corsair controllers and separately notes that motherboard-connected fans are not controlled through iCUE.

This distinction explains why editing a BIOS curve may appear to do nothing once a software controller applies a different profile. Test one control layer at a time: document the firmware behavior before the software loads, then check the controller or vendor software profile and selected sensor. Do not run several competing fan-control utilities as a generic troubleshooting method; first establish which layer actually owns the channel.

If several fans share one control path, temporarily reducing the chain to the simplest documented configuration can help distinguish a fan problem from a hub, splitter, or controller problem. Keep all electrical limits product-specific. Noctua, for example, publishes exact current limits for its own NA-FC1 controller and separately warns that the upstream power source can impose a lower limit; those numbers do not become universal motherboard-header limits.

Do not probe live fan headers, repin connectors, bypass protections, or combine fan loads based on a generic current assumption. Use the motherboard and controller specifications for the exact channel. If a hub requires SATA or another auxiliary power connection, verify only the documented user-serviceable connection with the system powered down.

If the problem began after changing firmware fan settings, installing a control utility, importing a profile, or moving a fan to another header, return only those user-applied changes to the documented default or automatic mode. Then verify the same physical fan again. This helps distinguish a configuration problem from a fan or controller that cannot respond correctly.

Do not use firmware resets, software removal, or controller resets indiscriminately when they would erase unrelated settings or profiles. Use the exact vendor procedure and preserve settings that matter. If the fan responds correctly at a documented default but not under the custom curve, the next branch is the curve/source/control-owner configuration rather than immediate hardware replacement.

Use this order: 1) identify the physical fan; 2) trace its exact header/controller path; 3) map RPM feedback to the channel; 4) verify the fan type and PWM/DC mode; 5) verify the firmware curve and selected sensor; 6) isolate splitters or hubs where practical; 7) determine whether operating-system software or a dedicated controller overrides firmware; 8) return user changes to a documented baseline; 9) replace or service hardware only when the same fan, header, hub, or controller failure remains repeatable after those checks.

Stop and power down if there is burning smell, visibly damaged wiring, a stalled fan that is required for safe cooling, liquid exposure, or another unsafe condition. Otherwise, preserve one change at a time. A fan running at full speed is not proof that the fan itself is faulty; the useful diagnosis comes from showing whether the fan can respond on a known-good documented control path and whether the original header/controller can control a known-good fan.