调速问题
更新时间: 2026/02/09
在Gitcode上查看源码

问题1: 怎么看是否在调速

查看app.log日志:basic cooling initializing表示启动服务,basic cooling starting服务启动中,basic cooling started服务启动完成 send device config to pid, cmd: 42 0 0 2 40 0 1 1 1 0 0 20 2 2 2 0 0 20 3 3 3 0 0 20 4 4 4 0 0 20 129 1 129 0 0 20 130 2 130 0 0 20 表示当前发给pid算法参与调速的器件有,风扇1 2 3 4,泵1,2(128+泵id) Send target tempconfig to pid, cmd 下发目标调速曲线 send envtemp config to pid 下发环温调速曲线

问题2:当前是哪个器件的调速占主导

日志分析: 环境上/var/log/cooling_control.log可以查看当前pid计算出的正常温度转速中目标调速和环温调速中最高的是哪条 或者一键收集日志:dump_info\LogDump\cooling_control.log DevID:0x101, Type:0, ReqId:7, T:37, TarT:45, TarPWM:52, EnvTNum:1, EnvReqId:6, EnvT:29, EnvPWM:94, PIDPWM:94, MaxAllowTemp:60, TarSensorName:Outlet Temp, EnvSensorName:Inlet Temp, FrontSpeed:0, RearSpeed:11264

  • DevID:0x101 表示风扇为id为0x01, Slot为0x01
  • Type:0 0表示器件为风扇 1表示器件为泵
  • TarPWM 表示Requirement为7的温度点,MonitoringTempValue为37,目标温度值计算出来的占空比为52(占空比最大值当前都为255,所以转速比为52/255*100%)
  • EnvTNum:1, 表示当前曲线调速有1条在参与转速计算
  • EnvT:29, 表示当前生效的曲线调速的温度29
  • EnvPWM:94 表示当前环温曲线调速计算的占空比
  • PIDPWM:192 是综合目标调速和环温调速的最大值,也是期望值

注:可查询当前转速最高的调速温度点,指向的是CoolingRequirement的SensorName属性 mdbctl call AirCoolingConfig_1 bmc.kepler.Systems.FanSnapshot GetActivatedPolicyFactors 0 "获取获取已激活的风扇转速最高的调速策略因子 ValidFalg用于表示内部是否有获取到正确的数据,若为false则无下述信息,否则 若不存在异常调速,则ActivatedType=0,Pwm=xxx,ControlFactor=调速因子名称,否则ActivatedTypes=1,Pwm=xx,Factor=调速因子名称,例如返回CPU1 Core Rem对应"

问题3:有哪些调速

  • 目标温度值调速。可查看cooling_control.log
  • 环温曲线调速。可查看cooling_control.log
  • 温度点温度异常调速。查看app.log日志,例: Add exception speed, key:(AbnormalRequirement:0x1e), policy(4:80 3:80 ) 调速策略中CoolingRequirement对象,RequirementId为0x1e的,MonitoringStatus为非0,即异常,触发了异常调速,风扇3和4添加了一个异常转速80%。此时环境上应当有温度相关告警(告警配置错误或者异常调速这儿配置错误会导致有异常调速无告警或者无异常调速有告警)
  • 风扇状态异常调速(不在位、转子转速偏差超过25%异常) Add exception speed, key:(AbnormalFan:...) 此时环境应当有风扇严重告警 Delete exception speed 删除一条异常调速
  • MPC调速,查看/redfish/v1/Chassis/1/Thermal 下ModelPredictiveControlEnabled为true表示开启了MPC调速
  • 每个转速的下发会取所有转速中的最大值下发
  • 复杂机型最终转速下发可能会有转速修正,例如某机型,所有风扇板的转速差不超过20%,转速低的板上的风扇转速会被拉高(防止转速回流)

问题4:多风扇板场景

以某机型为例子,有4块风扇板参与调速,所以验证调速需要4块风扇板在位调速功能才正常 日志分析:

  • 风扇分发:obj identify result: 3,2,4,1,5,8,31,35,33,2,34,37,36,7,8,6,10,9,13,12,14,11,15, 当前收到的风扇id,某机型预期为1-15,31-38,共23个风扇
  • 风扇板个数:cur num: %s, fan board num: %s,期望风扇板个数和当前收到的预期都为4
  • 强制启动调速:Fan object timeout detection starting, expect fan board num: %s, cur fan board num: %s 当超时仍未收到预期的风扇板个数,或者①中风扇id存在一致的,不符合预期。会强制启动basic cooling主线程服务,以注册所有功能(包括定制化与配置导入导出,ipmi注册,创建调速主线程)

问题5:风扇告警

日志分析: scan_fan_status: Scan fan31 rear speed error, real 51%(11776), expect 100% +- 25%; expected_pwm 255 表示31号风扇后转子实际转子转速51%;最大转速规格为11776/0.51=23000;expect 100是期望转速属性ExpectedPWM为100%;expected_pwm 255表示实际占空比属性HardwarePWM为255;风扇转速不在[23000 * 0.75,23000]内产生告警 fan%s %s error_hardpwm 转子转速告警时采集到的HardwarePWM值 fan%s %s error_speed 转子转速告警时采集到的转子转速值,对应资源树的RearSpeed或者FrontSpeed

问题6:风扇类型识别

风扇类型识别逻辑:FanType_A,FanType_B,Fan_1都配置在一块风扇板上,风扇类型识别只会判断配置在一块板上的FanType。识别开始时下发给IdentifySpeedLevel=35%的转速比,此时HardwarePWM应当是MaxSupportedPWM * IdentifySpeedLevel,然后采集5次转速,舍去最大值和最小值,取剩余3次的转速计算平均值,看平均值是落在哪个FanType的IdentifyRangeLow和IdentifyRangeHigh之间,则风扇类型识别成功

问题7:出厂定制化verify校验失败

  • 所有定制化项都失败 定制化服务未注册,查看日志,看注册的日志是否打印
  • 自定义CPU核温和出风口定制化项失败 查看是否配置了对应的CoolingArea,如果缺失,代码中认为该定制化项是存在调速场景,但是调速策略配置不全。export该项为空,校验会失败

问题8:全风扇满转

当前调速逻辑:BMC刚起来阶段所有风扇下发100%转速->PID接管调速 可能以下场景:

  • 无调速策略生效,但是风扇板有电
  • 调速组件异常,pid无法接管调速,以初始化转速服务接管调速(全风扇100%)
  • 器件高温导致的满转 -> 先看环境是否有高温告警,再查看cooling_control.log文件的调速信息
  • 器件温度获取异常导致满转,看环境是否有告警,再看app.log日志中是否有添加异常调速的日志,见问题3异常调速部分

异常调速流程图