Added
- New
NPUfan controller (sixth controller type) that drives one or more IPMI zones from the temperature of Ascend NPUs, e.g. the Atlas 300I Duo, read withnpu-smi. A device is an NPU card (npu-smi -i <id>); for a multi-chip card the hottest chip is used, andtemp_calc=(minimum/average/maximum) aggregates across cards. The section is[NPU]/[NPU:1]/ ... withnpu_device_ids=(the card IDs reported bynpu-smi info -m, which may not start from 0),npu_smi_path=(a bare command name resolved viaPATHor a full path), andnpu_smi_timeout=(seconds, guards against a hungnpu-smicall). All the shared parameters of the other temperature-driven controllers (ipmi_zone=,temp_calc=,sensitivity=,polling=,steps=,min_temp/max_temp/min_level/max_levelorcontrol_function=,smoothing=,error_tolerance=) are supported. The controller shows up insmfc-clientand the HTTP exporter like the other fan controllers. A sample configuration is included asconfig/samples/smfc-sample10.conf: an NPU-only setup with two Ascend cards in IPMI zone 1. Contributed by @akalagov in PR #121. - H14 motherboards are supported.
platform_name=generic_x14covers both X14 and H14 boards now. Supermicro's 14th generation ships two different BMC firmware types and the board name does not tell you which one you have, sosmfcdetects it at startup and reports what it found. On boards with the second type, taking the fans over affects every zone on the board rather than only the configured ones - so list all of them inipmi_zone=, or the ones you leave out stay at whatever level they had. See README chapter 5. - New
smfc_fan_control_heldmetric on the HTTP exporter, and the matchingcontrol_heldandcontrol_detailfields in/snapshot. It reports whethersmfcis in control of the fans, which means the same thing on every board: FULL fan mode where that is the controlled state, and the per-zone manual latch on X14/H14.smfc_bmc_infocarries a newenforces_full_modelabel naming which of the two applies. The sample Grafana dashboard shows it as theFan controlpanel.smfc-clientcolours its fan mode line by this state instead of measuring the fan mode against FULL, and prints the reason when control is lost. - doc/X14H14_MANUAL_FANCONTROL.md: a reference for both firmware types - which one your board runs, how to drive the fans by hand, and the fan and zone layout of the documented boards.
- New
[Ipmi] ipmitool_timeout=parameter (seconds, default:10) that bounds a singleipmitoolexecution. A wedged/dev/ipmi0makesipmitoolblock forever, which would park the control loop with nothing regulating the fans behind it. A timed-out call is treated as any other IPMI failure: the control loop logs it and retries on the next poll, and the fan mode watchdog re-acquires control. Use0to wait indefinitely, which is howsmfcbehaved before this parameter existed.
Changed
smfcstops at startup if a configuredipmi_zone=does not exist on an X14/H14 board. It reads the zone count from the board and names the wrong zone in the error, instead of failing on a raw IPMI error code.smfc-clientreports the actual fan-control state on X14/H14 instead of measuring the fan mode against FULL. It showsmanual controlwhen a zone is latched, or the base fan mode when the BMC's own curve is driving the zones, and warns only when a latch is left held whilesmfcis not running.
Fixed
- Fan control works on X14/H14 motherboards. It did not before: the commands
smfcsent were wrong, so the fan level never reached the board and the BMC kept running the fans on its own curve whilesmfcreported it had taken over. Tested on real hardware with the help of @koenbossers, @daduijker and @johanvdk1 in discussion #106. Alongside making it work, three safeguards now hold on these boards:- The fans are handed back to the BMC on every exit path -
exit_level=-1included, and even when the exit level cannot be written - so they are never left frozen with nothing regulating them. Here the exit level is only a transition: the BMC's own curve takes over about a second later, and it does not include disk temperatures (README chapter 1.6). - A zone the BMC has forced to 100% after a fan failure is detected:
smfclogs which zone is affected, and withenforce_fan_mode=0it stops with exit code 11 like any other loss of fan control. min_level=0can no longer stop the fans: whilesmfcdrives them the BMC's thermal protection is suspended, so levels below 5% are raised to 5%.
- The fans are handed back to the BMC on every exit path -
- An unreachable BMC is not counted as fan mode drift any more.
smfccannot tell whether the fans drifted when the BMC does not answer, so it no longer treats that as observed drift: it does not increment thesmfc_fan_mode_enforced_totalmetric and does not stop the service whenenforce_fan_mode=0. It keeps running and retries every loop, logging an error each cycle - so a temporary BMC outage (e.g. a ~90 second BMC reset, during which the BMC itself usually holds the fans at 100%) is ridden out rather than fatal, and control is re-acquired on the first loop after the BMC returns.