component_drivers组件和vpd组件同时适配LPe32002 FC卡告警的问题

交流互助区
1

1、LPe32002 FC卡在vpd中做过适配

2、这张卡现在又在component_drivers组件中做了适配

3、俩个组件都适配了降带宽、降速率、诊断故障和预故障告警

4、触发故障的数据源分别是PCIeNicCard.bmc.dev.PCIeDevice.Status和PCIeDevice.bmc.kepler.Systems.PCIeDevices.PCIeDevice

现象

set模拟VPD中的属性，告警能够Asserted，但是unset后无法Deasserted

set模拟component_drivers中的属性，告警能够Asserted，unset后能够Deasserted

问题

vpd中的告警unset后无法Deasserted，是什么原因？

在实际应用场景中告警触发时，这俩个告警有没有优先级？会不会有冲突？

2

答案内容由AI生成，仅供参考：
根据提供的上下文信息，对您提出的问题进行分析如下。

一、VPD 中告警 unset 后无法 Deasserted 的原因

最可能的原因是 该告警在事件定义中未配置恢复事件。
在 VPD 组件的静态配置中，每个告警事件都通过 LifeCycleId 属性或 DeassertFlag 标记来标识是否会产生恢复（Deassert）事件。如果对应配置中 DeassertFlag 为 0，则系统不会产生去断言事件，即使模拟恢复操作（unset），告警也无法自动清除。

上下文相关依据：

  • Document Chunk 1 明确指出：

    ## 十、没有Deassert事件
    2. 本身就没有恢复事件
    事件配置中的LifeCycleId属性用于表征是否会产生恢复事件
    DessertFlag为0代表无deassert事件

  • 同文档中的 案例4 也说明：

    模拟告警恢复后，查询历史事件记录查不到
    通过查询配置数据发现DeassertFlag为0，即不产生恢复事件

因此，如果 VPD 中该告警的 DeassertFlag（或 LifeCycleId）被设置为 不产生恢复事件，即使调用方执行了 unset 模拟，告警状态也不会自动变为 Deasserted。而 component_drivers 中对应的告警配置可能设置了正确的恢复事件标记，因此能够正常 Deassert。

二、实际场景中两个告警的优先级与冲突问题

上下文中的相关机制

  1. 事件唯一性确定方式

    通过ComponentName、EventKeyId、MessageArgs确定唯一事件（Document Chunk 6）
    系统无法重复Assert/Deassert同一事件（Document Chunk 6）

  2. 事件与组件的匹配

    根据ComponentName和SubjectType匹配部件，同类型部件ComponentName应当唯一（Document Chunk 6）

  3. 两种告警方式

    系统事件告警可分为 CSR配置告警（基于硬件触发）与 事件RPC告警（由软件产生），两者均可存在（Document Chunk 7）

  4. 配置来源
    VPD 组件提供静态配置（事件定义、描述），而 component_drivers 及其他组件可能通过 CSR 文件提供触发条件。两者可能同时存在并作用于同一硬件对象。

根据现象分析

  • 您分别模拟 两个不同数据源（PCIeNicCard.bmc.dev.PCIeDevice.Status 和 PCIeDevice.bmc.kepler.Systems.PCIeDevices.PCIeDevice）触发了告警。
  • 这两个路径对应不同的 Component 对象（对象树路径不同），因此即使告警类型相同（降带宽、降速率等），它们很可能属于不同的事件实例（不同 ComponentName 或不同 EventKeyId）。
  • 既然两个事件实例不同，系统允许它们各自独立 Assert/Deassert，不会产生冲突。
  • 若两个组件定义了完全相同的 ComponentName、EventKeyId 和 MessageArgs，则系统只会注册一次，重复的配置可能被忽略或导致注册失败，产生不可预期行为。

优先级方面

上下文中没有明确说明两个组件同时适配同一张卡告警时的优先级处理规则。根据现有信息：

  • 如果事件定义不同（如不同 Component），则两者并行存在，无优先级问题。
  • 如果事件定义相同，则后加载的配置可能覆盖先加载的，但具体规则未在资料中展开。
  • 建议通过查询 registered.txt 和 not_registered.txt（Document Chunk 1）确认实际注册的事件对象，以及检查操作日志中是否有屏蔽配置（案例5），从而判断哪个配置最终生效。

总结建议

问题 主要原因 / 现状
VPD 告警无法 Deassert 事件配置中 DeassertFlag 为 0（无恢复事件），需检查 VPD 仓库中对应的 CSR/SR 配置
两个组件告警的冲突 由于数据源指向不同 Component 对象，实际中很可能两套告警独立运行，互不冲突；若事件码和 Component 均相同，则仅一次注册生效，需保证唯一性

若需要进一步排查，建议：

  • 通过 busctl 或日志确认两个告警的实际 EventKeyId 和绑定的 ComponentName 是否相同。
  • 检查 VPD 中该告警的 DeassertFlag 字段值（可通过查询配置数据或 CSR 文件）。
  • 确认 component_drivers 中对应的告警配置是否显式设置了恢复事件。
3

麻烦查看下libmc4lua版本

4

1、component_drivers代码中触发绑定的属性来源是从pcie_device同步过来。所以测试模拟pcie_device的属性值这个是可行的。

2、通过busctl call rpc方法设置属性值为1，再设置属性值为0。告警可以产生消除。无问题（此方法用于模拟fdm调用设置）

3、通过setprop方式先把属性值设置成1，再把属性值设置成0。告警可以产生消除。无问题

4、先通过setprop方式先把属性值设置成1，不把属性值设置成0。直接unset。告警不消除。

unset的方法为什么无法消除告警需要看一下

5

unset的属性是什么配置，是否引用了Accessor

6

PCIeDevice bmc.kepler.Systems.PCIeDevices.PCIeDevice
BandwidthReduction/PredictiveFault/DiagnosticFault/LinkSpeedReduced