Skip to content

v6.4.0

Latest

Choose a tag to compare

@petersulyok petersulyok released this 02 Sep 19:42

Added

  • New PCI fan controller (seventh controller type) that drives one or more IPMI zones from the HWMON temperature of PCI devices that have no fan controller of their own, e.g. a 10 Gbit network card. The cards are discovered through the udev database and named with exactly one of three parameters: pci_address= (a list of PCI slot addresses, e.g. 0000:05:00.0, all of the same model), pci_id= (one vendor:device ID, e.g. 1d6a:07b1, matching every card of that model), or pci_driver= (one driver name, e.g. atlantic, matching every card the driver serves - a new card of the same kind joins the section at the next restart with no configuration change). A device is one HWMON device rather than one card, so a card exposing several HWMON devices counts as several devices, and temp_calc= (minimum/average/maximum, default: maximum) aggregates across them. temp_sensor= selects which sensor of a HWMON device to read (default: 1, i.e. temp1_input); an Aquantia AQC107 reports the PHY temperature in temp1_input and the MAC temperature in temp2_input. The section is [PCI] / [PCI:1] / ... and supports all the shared parameters of the other temperature-driven controllers. One section covers one kind of PCI device, because it has a single temperature window and a single temp_sensor=. The controller shows up in smfc-client and the HTTP exporter like the other fan controllers. A sample configuration is included as config/samples/smfc-sample11.conf: a CPU controller in IPMI zone 0 plus an Aquantia 10 Gbit network card in IPMI zone 1, selected by its driver and read from its MAC sensor.

Changed

  • Every fan controller has its own chapter in the README now. Chapter 1.2 gained a sub-chapter per fan controller (CPU, HD, NVME, GPU, NPU, PCI, CONST), each a table naming the target devices, the temperature source, the parameter that identifies the devices, the remaining controller-specific parameters, whether the controller works in the docker images and what it needs from the host, and the traps worth knowing before enabling it. The parameters shared by every temperature-driven controller are listed once above the sub-chapters instead of being repeated.
  • Documented that platform_name=auto cannot detect an X14/H14 board whose BMC reports no product name. Auto-detection matches the X14/H14 prefix of the BMC product name, so a board answering ipmitool bmc info with Product Name : Unknown falls back to the generic platform and is then driven with commands these boards do not use - smfc reports that it took control while the BMC keeps running its own curve. The fix is to set platform_name=generic_x14 by hand. README chapter 5 now says so in the X14/H14 notes and in the auto row of the platform table, and the platform_name= comment of smfc.conf and of every sample configuration carries the same warning.