基于2509的openubmc
适配一张GPU卡，通过如下方式配置UCE\CE\FE事件：
PCIeCardCEHardFailure事件关联数据为PCIeDevice_1.CorrectableError
PCIeCardUncorrectableErr事件关联的数据为PCIeDevice_1.UncorrectableError
PCIeCardFatalErr事件关联的数据为PCIeDevice_1.FatalError
CorrectableError/UncorrectableError/FatalError数据由ImplPCIeDevicesPCIeDevicesSetPcieErrorStatus设置。
我看华为适配的GPU卡并不是这么配置的，而是如下：
PCIeCardCEHardFailure事件关联数据为PCIeDevice_1.PredictiveFault
答案内容由AI生成，仅供参考：
结论：
您当前的配置在RPC服务注册层面是正确的，但在事件定义的数据源选择上存在优化空间。
推荐做法：
PredictiveFaultDiagnosticFault + UCEByBIOS 的组合逻辑/<= → <=/）event_def.json 版本号以确保生效该配置策略已在华为GPU/NPU卡适配中广泛验证，具备更高的稳定性与准确性，建议遵循此模式进行适配开发。
在基于openUBMC 25.09版本的系统中，正确配置GPU卡的PCIe相关故障事件（可纠正错误CE、不可纠正错误UCE、严重故障FE）是实现硬件可靠性监控的关键。本指南将结合官方实践和实际开发经验，分析用户提供的配置方案是否合理，并给出推荐的最佳实践。
根据openUBMC的设计规范与华为实际适配案例，PCIe设备的各类错误事件应通过以下方式关联：
推荐配置方式（华为适配模式）| 事件类型 | 事件名称 | 正确数据源 | 说明 |
|---|---|---|---|
| 可纠正错误 (CE) | PCIeCard.PCIeCardCEHardFailure |
PCIeDevice_1.PredictiveFault |
使用预测性故障标志位作为CE事件触发条件 |
| 不可纠正错误 (UCE) | PCIeCard.PCIeCardUncorrectableErr |
PCIeDevice_1.UCEByBIOS 或组合逻辑 |
来自BIOS上报的UCE状态或诊断故障组合 |
| 严重故障 (FE) | PCIeCard.PCIeCardFatalErr |
PCIeDevice_1.DiagnosticFault |
用于标识严重硬件故障 |
核心差异：您的原始配置直接使用
CorrectableError、UncorrectableError等底层寄存器值作为事件输入，而华为推荐方案更注重系统级抽象与故障聚合逻辑，提升告警准确性。
1. 配置 PCIeCardCEHardFailure 事件"Event_PCIECardCE": {
"EventKeyId": "PCIeCard.PCIeCardCEHardFailure",
"Condition": 1,
"Reading": "<=/PCIeDevice_1.PredictiveFault",
"OperatorId": 5,
"Enabled": true,
"AdditionalInfo": "2",
"DescArg2": "#/Component_PCIeCard.Name",
"Component": "#/Component_PCIeCard"
}
说明：
PredictiveFault 作为输入，表示设备已检测到潜在可恢复错误。CorrectableError 计数器，避免频繁抖动上报。 2. 配置 PCIeCardUncorrectableErr 事件"Event_PCIECardUser": {
"EventKeyId": "PCIeCard.PCIeCardUncorrectableErr",
"Condition": 1,
"Reading": "<=/PCIeDevice_1.DiagnosticFault; <=/PCIeDevice_1.UCEByBIOS | expr(($1 + $2) == 0 ? 0 : 1)",
"OperatorId": 5,
"Enabled": true,
"AdditionalInfo": "2",
"DescArg2": "#/Component_PCIeCard.Name",
"DescArg4": "NA",
"Component": "#/Component_PCIeCard"
}
说明：
DiagnosticFault 或 UCEByBIOS 任一为1时，触发UCE事件。 3. 配置 PCIeCardFatalErr 事件"Event_PCIeCardFE": {
"EventKeyId": "PCIeCard.PCIeCardFatalErr",
"Condition": 1,
"Reading": "<=/PCIeDevice_1.DiagnosticFault",
"OperatorId": 5,
"Enabled": "<=/Entity_GPUCard.PowerState |> expr($1 == 1 ? true : false)",
"AdditionalInfo": "2",
"DescArg2": "#/Component_PCIeCard.Name",
"DescArg4": "NA",
"Component": "#/Component_PCIeCard",
"LedFaultCode": "q$"
}
说明：
DiagnosticFault 作为触发源，表示设备存在严重故障。PowerState 控制事件启用状态，仅在设备上电时生效，防止误报。您代码中对RPC方法的注册是完全正确且符合规范的。以下是关键接口说明：
function pcie_device_app:register_rpc()
local SYSTEM_ID_DEFAULT<const> = 1
self:CreatePCIeDevices(SYSTEM_ID_DEFAULT)
-- ✅ 设置PCIe错误状态（CorrectableError/UncorrectableError/FatalError）
self:ImplPCIeDevicesPCIeDevicesSetPcieErrorStatus(function(obj, ctx, ...)
return self.device_service:method_set_error_status(ctx, ...)
end)
-- ✅ 设置BIOS上报的UCE标识
self:ImplPCIeDevicesPCIeDevicesSetUCEByBIOS(function(obj, ctx, ...)
return self.device_service:method_set_uce_by_bios(ctx, ...)
end)
-- ✅ 设置链路降速标识
self:ImplPCIeDevicesPCIeDevicesSetLinkSpeedReduced(function(obj, ctx, ...)
return self.device_service:method_set_link_speed_reduced(ctx, ...)
end)
-- ✅ 设置严重故障标识
self:ImplPCIeDevicesPCIeDevicesSetDiagnosticFault(function (obj, ctx, ...)
return self.device_service:method_set_diagnostic_fault(ctx, ...)
end)
-- ✅ 设置预故障标识
self:ImplPCIeDevicesPCIeDevicesSetPredictiveFault(function (obj, ctx, ...)
return self.device_service:method_set_predictive_fault(ctx, ...)
end)
end
总结：上述注册逻辑正确，底层驱动可通过这些接口动态更新设备状态。
| 问题项 | 您的原始配置 | 推荐修改 |
|---|---|---|
| CE事件源 | CorrectableError |
改为 PredictiveFault |
| UCE事件源 | UncorrectableError |
改为 DiagnosticFault + UCEByBIOS 组合 |
| 表达式语法 | /<= → 应为 <=/ |
修正路径语法 |
| 是否需要更新event_def.json版本号？ | 必须更新，否则事件不生效 |
参考文档：OpenUBMC事件开发指南 |
使用抽象层状态字段PredictiveFault、DiagnosticFault、UCEByBIOS。 启用组合条件判断(DiagnosticFault || UCEByBIOS) ? 1 : 0 动态启用控制Enabled 字段结合电源状态控制事件有效性："Enabled": "<=/Entity_GPUCard.PowerState |> expr($1 == 1 ? true : false)"
event_def.json 后必须升级版本号（version字段），否则新事件不会被加载。 验证工具使用devmon 工具验证资源配置是否生效：devmon dump bmc.kepler.Systems.PCIeDevices.PCIeCard
GET /redfish/v1/Systems/1/PCIeDevices/NPUCard_1
结论：
您当前的配置在RPC服务注册层面是正确的，但在事件定义的数据源选择上存在优化空间。
推荐做法：
PredictiveFaultDiagnosticFault + UCEByBIOS 的组合逻辑/<= → <=/）event_def.json 版本号以确保生效该配置策略已在华为GPU/NPU卡适配中广泛验证，具备更高的稳定性与准确性，建议遵循此模式进行适配开发。
您好，挂载在bmc.kepler.Systems.PCIeDevices.PCIeDevice.RAS下的属性一般是SDK用来管理PCIe卡错误的属性。
触发告警用的属性一般定义在bmc.kepler.Systems.PCIeDevices.PCIeDevice下，错误一般由带内host的ipmi指令发出，发给sdk后调用rpc向pcie_device组件设置。
这些rpc方法挂载在/bmc/kepler/Systems/1/PCIeDevices下，如SetUCEByBIOS、SetPredictiveFault、SetBandwidthReduction、SetLinkSpeedReduced，pcie_device的代码中可以看到相关调用，最后会设置到具体PCIeDevice对象的属性上。
告警一般是监听这些在bmc.kepler.Systems.PCIeDevices.PCIeDevice
下的属性的，如UCEByBIOS、PredictiveFault、BandwidthReduction、LinkSpeedReduced。
bmc.kepler.Systems.PCIeDevices.PCIeDevice.RAS下的属性也是由带内host的ipmi指令发出，发给sdk后调用rpc向pcie_device组件设置的
如果这里属性的描述是正确的话，这几个属性很适合用来触发RAS事件吧。
.RAS下的属性一般做sdk记录持久化数据用，一般用来记录错误状态而不是直接设置告警，比较新一些的实现会直接用sdk去设置.RAS下的值而不是使用方法间接设置。这些属性的设置和管理和SDK管理PCIe错误相关，不是和带内的告警指令直接相关。
现在为什么需要用.RAS下的属性来配置告警呢？有什么实际需求吗？
我们适配一张新的GPU卡，要实现这个卡的三种RAS告警事件CE/UCE/FE。
按之前的方法配有什么问题吗？
之前的没有FE的例子
另一方面也只是想确认一下这样配可不可行，如果不可行的话想知道下原因，因为从这个属性描述和实现上看似乎是可行的。并不是说之前的方法有问题
模仿已有的配置即可
没有呀，没有FE的例子呀。
这个问题我上下个sig沟通一下吧
FE告警对应的就是FatalError，对应方法SetFaultByBios，对应属性FaultByBios
