dpu卡正常下电触发Critical_INT传感器bus fatal error告警

交流互助区
1

// 此模板仅供参考，如果不适用可以修改

问题描述

dpu卡正常下电，触发Critical_INT传感器告警

重现步骤

  1. dpu卡做下电/复位动作，触发Critical_INT传感器告警，如下：

    img_v3_02137_cec271c1-c975-41d1-8b94-7ded4cfbcedg
    img_v3_02137_cec271c1-c975-41d1-8b94-7ded4cfbcedg1229×463 76.4 KB

  2. Critical_INT及其事件定义如下：
    “DiscreteSensor_Critical_INT_Status”: {
    “OwnerId”: 33,
    “OwnerLun”: 0,
    “EntityId”: 11,
    “EntityInstance”: 101,
    “Initialization”: 99,
    “Capabilities”: 64,
    “SensorType”: 19,
    “ReadingType”: 111,
    “SensorName”: “Critical_INT”,
    “DiscreteType”: 1,
    “Unit”: 192,
    “BaseUnit”: 0,
    “ModifierUnit”: 0,
    “RecordSharing”: 1,
    “Reading”: 0,
    “SensorNumber”: 255,
    “AssertMask”: 3456,
    “DeassertMask”: 3072,
    “DiscreteMask”: 3456
    },
    “DiscreteEvent_Critical_INT_FE”: {
    “Property”: “<=/PCIeRASCollector.FatalError”,
    “ListenType”: 1,
    “EventData1”: 170,
    “EventData2”: “<=/PCIeRASCollector.DevBus”,
    “EventData3”: “<=/PCIeRASCollector.DevDevice;<=/PCIeRASCollector.DevFunction |> expr($1 * 8 + $2)”,
    “EventDir”: “<=/PCIeRASCollector.FatalError”,
    “Conversion”: 0,
    “SensorObject”: “#/DiscreteSensor_Critical_INT_Status”
    },

  3. 根据以上：PCIe 设备下电时，PCIe Link 断开 → AER (Advanced Error Reporting) 检测到链路丢失 → 上报为 Fatal Error → PCIeRASCollector.FatalError 被置 1 → 匹配 到DiscreteEvent_Critical_INT_FE → Assert Critical_INT 传感器。

    这是正常的 PCIe 行为——PCIe 设备突然从总线消失，总线侧会认为是一个 Fatal Error。

  4. 看起来是PCIe RAS 检测机制与dpu卡正常下电流程之间的冲突

问题

dpu正常下电产生fatal error告警，是否合理？

2

答案内容由AI生成，仅供参考：

结论与建议

  • 从硬件机制角度看：DPU正常下电导致PCIe Link断开并上报FatalError是符合PCIe规范的自然行为，但这不是系统故障，而是预期操作。
  • 从告警合理性角度看：将正常下电触发的FatalError直接转换为Critical_INT传感器告警是不合理的，因为这属于误报，会干扰运维人员的判断。
  • 推荐解决方案：参考已存在的做法（如电压告警案例），在DiscreteEvent_Critical_INT_FE的事件定义中增加对电源状态（如Entity_GPUCard.PowerState）的判断，仅在设备处于上电状态时响应FatalError，从而屏蔽正常下电时的误告警。类似方式已在其他场景被验证有效。

由于上下文中未提供“DPU卡正常下电应不触发FatalError告警”的明确声明，以上建议基于已有类似问题的处理逻辑给出。若需更权威的结论，建议咨询相关设计文档或社区。

点击此处查看详细分析解答

根据提供的知识库上下文信息，无法直接判断“DPU正常下电触发Critical_INT传感器bus fatal error告警”是否绝对合理。但上下文提供了以下相关线索：

  1. FatalError属性的定义：在bmc.kepler.Systems.FDMDomain.PCIeRASCollector和bmc.kepler.Systems.PCIeDevices.PCIeDevice.RAS中，FatalError被定义为只读U8类型，取值0（未发生）或1（发生），用于指示PCIe设备发生了致命错误（参见文档块1、5）。该属性通常由系统检测到严重PCIe链路故障时设置。

  2. 正常下电与FatalError的关系：用户描述的正常下电导致PCIe Link断开，被AER检测并上报为FatalError，这在PCIe硬件机制上是正常的物理行为——PCIe设备从总线上消失，总线侧会认为链路异常。但系统设计上，正常下电属于预期操作，通常不应视为“致命错误”，否则会导致误告警。

  3. 已有类似问题的处理方案：在上下文文档块6中，针对GPU卡下电时电压告警误触发的问题，解决方案是在事件定义中增加对Entity_GPUCard.PowerState的判断，只在上电状态下检测告警，从而避免下电时误报。原文示例：

    “Event_VoltUpper”: {
    “Reading”: “<=/NPUCard_1.FaultState;<=/Entity_GPUCard.PowerState |> expr(...)”,
    ...
}

    这说明在openUBMC中，可以通过在事件或传感器触发条件中增加电源状态判断来规避正常下电引发的误告警。

  4. 事件配置建议：在文档块2的讨论中，有开发人员指出.RAS下的属性一般做SDK记录持久化数据用，一般用来记录错误状态而不是直接设置告警，并建议如果需要用.RAS属性触发告警，应明确实际需求。这说明直接使用PCIeRASCollector.FatalError触发告警可能并非系统设计初衷。

结论与建议

  • 从硬件机制角度看：DPU正常下电导致PCIe Link断开并上报FatalError是符合PCIe规范的自然行为，但这不是系统故障，而是预期操作。
  • 从告警合理性角度看：将正常下电触发的FatalError直接转换为Critical_INT传感器告警是不合理的，因为这属于误报，会干扰运维人员的判断。
  • 推荐解决方案：参考已存在的做法（如电压告警案例），在DiscreteEvent_Critical_INT_FE的事件定义中增加对电源状态（如Entity_GPUCard.PowerState）的判断，仅在设备处于上电状态时响应FatalError，从而屏蔽正常下电时的误告警。类似方式已在其他场景被验证有效。

由于上下文中未提供“DPU卡正常下电应不触发FatalError告警”的明确声明，以上建议基于已有类似问题的处理逻辑给出。若需更权威的结论，建议咨询相关设计文档或社区。

3

下电动作与暴力拔卡行为相似，上报FE故障符合预期，如果需要不触发告警，建议和卡侧和bios对齐，有没有下电不上报告警的驱动或者方案，或者直接不配置这个告警。

4

所以除非客户强制要求，实际还是建议下电需要上报FE故障的？