升级到openUBMC后，CPU侧无法检测到对应的BMC的存在

交流互助区
1

通过将iBMC直接升级到openUBMC25.09后，CPU侧提示找不到BMC芯片。BIOS中也打印错误日志

问题：

1、BMC侧用来实现和CPU侧ipmi相关驱动模块通信的是啥模块？观察到BMC中有3个驱动都打印了USE LPC!

2、这种问题除了可能和硬件上的LPC接口有关，还有可能和哪块相关？UBMC中的某个组件？

【RAS】通过rastool注入cpu uce告警之后，日志有打印，但实际无uce告警产生
openUBMC25.09 web界面上更新openUBMC25.09版本启动后回退到iBMC版本
V2升级openUBMC后，固件无法升级
挂载在hisport上的设备如何读取
2

BMC侧：

图片
图片692×246 83.9 KB

BIOS侧：

图片
图片692×369 74.5 KB

3

CPU侧：

图片
图片692×127 62 KB

图片
图片692×178 87.5 KB

4

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

升级至 openUBMC 后 CPU 侧无法检测到 BMC 的问题分析

根据您提供的信息，从 iBMC 直接升级到 openUBMC 25.09 后，CPU 侧无法启动且提示找不到 BMC 芯片，同时 BIOS 打印了相关错误日志。以下结合知识库内容对您的两个问题进行详细分析和解答。

:magnifying_glass_tilted_left: 问题现象总结

  • 升级前：iBMC 固件正常运行，CPU 正常启动。
  • 升级后：openUBMC 25.09 启动正常（BMC 串口有输出），但 CPU 侧无任何打印输出，BIOS 报错“找不到 BMC 芯片”。
  • 可能原因：BMC 与 CPU 主板之间的通信链路异常，尤其是用于 IPMI 通信的 LPC 接口或相关驱动模块。
  • 验证结果：回退到 iBMC 版本即可恢复正常，指向 openUBMC 固件适配或配置问题。

:white_check_mark: 问题 1：BMC 侧实现与 CPU 侧 IPMI 驱动通信的模块是什么？为何看到多个驱动打印 “USE LPC”？

1. 主要实现模块：mctp + ipmi_core + QEMU 虚拟设备模拟（生产环境为物理 LPC）

在 openUBMC 架构中，BMC 与 CPU 主板之间通过 LPC（Low Pin Count）总线接口进行 IPMI 通信。该通信链路的关键驱动和模块包括：

模块 作用
ipmi_core 是 IPMI 协议栈的核心组件，负责接收并分发 IPMI 命令，处理来自主机（BIOS）的请求。它依赖底层传输协议获取命令（如通过 LPC 上的 KCS/BT 接口）。
mctp / mctpd Management Component Transport Protocol (MCTP) 是现代 BMC 架构中用于跨平台传输 IPMI 消息的协议。在 openUBMC 中，mctpd 守护进程支持通过 LPC/BT 上的 MCTP 实现与 CPU 的通信。
LPC 子系统驱动 在 Linux 内核层或 QEMU 模拟中，LPC 总线被用来连接主机 CPU 和 BMC。该驱动负责建立 KCS（Keyboard Controller Style）或 BT（Block Transfer）通道，传输 IPMI 命令。

您在日志中看到多个模块打印 “USE LPC!”，是因为：

  • 多个组件都需要使用 LPC 总线资源（如 ipmi_core、sensor interface、system event log 等）。
  • 在开发或启动阶段，每个使用 IPMI 通道的模块都会尝试初始化其通信机制，因此都会检测并声明对 LPC 的依赖。
  • 并不表示有冲突，但若多个模块争抢资源或配置不当，可能导致 主通道未正确建立。

:play_button: 关键结论：

  • 真正承担 CPU-BMC IPMI 通信职责的是 ipmi_core 组件，它是所有 IPMI 请求的入口。
  • 所有模块打印 “USE LPC” 表示它们都启用了基于 LPC 的 IPMI 接口（通常是 KCS/BT）。
  • 如果 ipmi_core 初始化失败或未注册服务，则即使 BMC 自身运行正常，CPU 也无法通过 LPC 进行 IPMI 通信。

:pushpin: 提示：您可以通过 busctl 或 mdbctl 工具在 openUBMC 系统中检查 ipmi_core 是否运行正常：

busctl list \| grep ipmi_core

:white_check_mark: 问题 2：除了硬件上的 LPC 接口，还有哪些软件/组件可能导致该问题？

该问题不仅可能与物理 LPC 管脚连接、上下拉电阻、电平匹配 等硬件问题有关，还极有可能由 openUBMC 软件栈中的特定组件或配置缺失 导致。

以下是可能导致“CPU 找不到 BMC”的其他关键因素：

:small_blue_diamond: 1. CSR 文件未正确配置或平台识别失败

CSR（Control and Status Register）文件是 openUBMC 用于描述硬件特性的核心配置文件。

  • 问题根源：当从 iBMC 升级到 openUBMC 时，如果未适配目标板的 CSR 配置（特别是 LPC 映射、PCIe 路由、PlatformId/BoardId），会导致 BMC 虽然启动，但无法正确初始化主板通信通道。

  • 具体案例：文档中提到：

    “BMC启动后无法ping通默认IP，串口登录提示密码错误，原因是模组载板 PlatformId 或 BoardId 不符合预期，导致关键配置文件未加载。”

    类似情况也可能导致 LPC/KCS 接口未启用或驱动未加载。

:white_check_mark: 建议检查：

  • 是否存在适用于 S920X20 或 Hi1711+KP920 模组 的 CSR 配置？
  • CSR 文件中是否明确定义了 LPC_CONTROLLER_ENABLE = true？
  • 查看启动日志是否有 [CSR] loading platform config failed 类似警告。

:small_blue_diamond: 2. BIOS 与 BMC 之间通信依赖的 GPIO 控制信号配置错误

知识库中已有线索直接指向这一点：

“咨询了公司的硬件同事，说是存放BIOS的Flash那边有个选择信号（SEL_GPIO0），说是由BMC这边控制…难道openUBMC默认就控制这个选择信号到BMC侧？导致CPU侧无法启动”

  • openUBMC 中的 devmon 或 general_hardware 组件会接管 GPIO 控制。
  • 若 openUBMC 将 SEL_GPIO0 错误地配置为指向 BMC 自身 Flash，则 CPU 将无法访问其 BIOS，进而表现如“无输出”、“找不到 BMC”。

:white_check_mark: 解决建议：

  • 检查 devmon 配置或设备树（Device Tree）中对 SEL_GPIO0 的定义。
  • 确保 GPIO 设置与原始 iBMC 一致。

:small_blue_diamond: 3. 缺少 BIOS上报PCIe地址信息给BMC 的兼容性支持

  • openUBMC 依赖 BIOS 在开机阶段通过 IPMI 命令 ReadFileFromBmc 获取 silkconfig.json 等配置文件。
  • 若 BIOS 使用的是旧版逻辑，而 openUBMC 未保留兼容接口，可能导致 BIOS 认为 BMC 不可用或响应异常，从而拒绝继续启动。

相关接口：

  • ReadFileFromBmc: BIOS 向 BMC 请求文件的 IPMI 命令
  • bios_read_file_from_bmc: openUBMC 提供的处理函数

:white_check_mark: 建议确认：

  • openUBMC 25.09 是否完整实现了 ReadFileFromBmc 命令？
  • 是否启用了 向后兼容的旧 IPMI 命令支持？

:small_blue_diamond: 4. 未正确启用 LPC/KCS/MTCP 传输层

  • openUBMC 使用 QEMU 模拟时依赖 LPC 和 BT 接口模拟 MCTP 通信。
  • 在真实硬件上，必须确保内核或启动脚本中启用了 LPC 接口及 KCS/BT 支持。

参考文档：《openUBMC Qemu特性设计说明书.md》中提到：

  • LPC 总线用于仿真主机与 BMC 之间的 IPMI 命令传输。

若该功能在目标平台被禁用或未编译进镜像，将导致通信中断。

:small_blue_diamond: 5. 固件签名与权限问题导致部分服务未启动

文档中指出：

“可能原因是BIOS/CPLD固件的签名不是开发者自己的…openUBMC 只能升级自己签名的固件。”

  • 即使 BMC 启动了基本 shell，但若因签名验证失败导致 ipmi_core、mctpd 等关键服务被阻止加载，也会表现为“伪启动”。
  • 可通过串口查看 systemd 或初始化脚本日志，确认这些服务是否运行。

:white_check_mark: 总结与建议解决方案

问题 原因 建议排查措施
CPU 侧无法识别 BMC 多数并非硬件故障，而是 openUBMC 固件未适配当前板型 或 关键通信组件未正确配置。 :white_check_mark: 回退 iBMC 验证硬件完好性
:white_check_mark: 可能组件问题 ipmi_core, CSR, devmon, mctpd, GPIO配置 :white_check_mark: 检查 CSR 平台配置是否匹配目标板
:white_check_mark: 软件兼容性问题 缺少对旧 BIOS 或 IPMI 命令的支持 :white_check_mark: 验证 ReadFileFromBmc 是否正常工作
:white_check_mark: 启动机制问题 SEL_GPIO0 被错误控制 :white_check_mark: 检查 GPIO 设置是否与 iBMC 一致

:white_check_mark: 排查步骤建议：

  1. 串口查看 BMC 启动日志：

    • 是否有 LPC: device found、KCS: ready 等信息？
    • ipmi_core 和 mctpd 是否成功启动？

  2. 使用 busctl 或 mdbctl 检查服务状态：

    busctl list \| grep ipmi_core
mdbctl list \| grep mctp

  3. **验证 CSR 配置是否正确加载平台配置。

  4. 比对 CSR 配置文件：

    • 查看是否包含 LPC/KCS/MCTP 使能项；
    • 确认 PlatformId 和 BoardId 是否正确。

  5. 联系 openUBMC 社区：

    • 在 forum.openubmc.cn 发帖，参考类似问题 topic/4371。
    • 提供完整的启动日志、平台信息（Hi1711+KP920）、CSR 版本。

:white_check_mark: 最终建议：

:red_exclamation_mark: 直接从 iBMC 升级到 openUBMC 25.09 存在较大风险，尤其当目标平台为非标准参考设计。

推荐做法是：

  • 先适配 CSR 和硬件配置文件
  • 在 QEMU 环境中验证通信机制
  • 逐步替换固件，而非一键升级

openUBMC 官方也强调：“对于客户自己的载板，openUBMC 支持公共特性，针对载板和模组需要做适配。”

如需进一步协助，建议提供以下信息：

  • 平台完整的 CSR 配置片段
  • BMC 串口启动日志（重点关注 ipmi_core 加载部分）
  • 是否自定义了 GPIO 或 PlatformId

祝您顺利解决问题！

相关链接：

  1. iBMC升级到openUBMC 25.09后，CPU侧无法启动
  2. 基础通用问题FAQ
  3. 偶现openubmc变成ibmc。。
  4. 【教学培训篇】读写eeprom
  5. RAID卡常见问题指南 | 文档中心 | openUBMC
5

初步怀疑是bt驱动加载异常，出问题的是什么机型呢？

6

我们这边使用的是 Hi1711 BMC模组 + KP920模组，

另外我看25.09的社区版本里面在构建固件包的过程中是把bt_drv.ko的加载给干掉了的， 这是啥情况？是之前出现过什么问题被替代了吗？ 那BMC侧用哪个驱动来和CPU侧进行通信呀？ btc_drv.ko这个吗？

7

驱动加载应该是没问题的，大概率是固件配套问题。检查一下bmc、csr、bios、基础板扩展板cpld、还有mcu版本

8

你好，这边刚接触这个不久，BIOS版本我知道，是6.18T 的版本，bmc版本是openUBMC25.09；

其它你提到的csr、基础板扩展板cpld、mcu版本这个有啥方法能查询到或者是看到吗？

9

bmc执行ipmcget -d v 命令

image
image503×316 33.7 KB

10

图片
图片911×490 13.9 KB

我在BMC模组上查到的是这样的，没有看到Product Info这些，这块是不是sr文件没适配好？

说明：这里的25.10.00.01是我在25.09.00.01上改 了下版本号，做了升级（就是仅仅改了版本号，测试下从社区版本升级到社区版本，看看能不能行）

11

查看了下BMC侧的CSR相关的东西，如下截图所示，扩展板的csr的加载存在问题？

busctl --user tree bmc.kepler.hwdiscovery
└─/bmc
└─/bmc/kepler
├─/bmc/kepler/Connector
│ ├─/bmc/kepler/Connector/Connector_EXU_1_01
│ └─/bmc/kepler/Connector/Connector_Sensor_01
├─/bmc/kepler/ObjectGroup
│ ├─/bmc/kepler/ObjectGroup/00
│ ├─/bmc/kepler/ObjectGroup/01
│ └─/bmc/kepler/ObjectGroup/0102
└─/bmc/kepler/hwdiscovery
└─/bmc/kepler/hwdiscovery/MicroComponent

mdbctl lsprop Connector_EXU_1_01

bmc.kepler.Connector
AuxId=“”
Bom=“14100513”
Buses=[“I2c_1”,“I2c_2”,“I2c_3”,“I2c_4”,“I2c_5”,“I2c_6”,“I2c_7”,“I2c_8”,“I2c_11”,“Jtag_1”,“JtagOverLocalBus_1”,“Hisport_0”,“Hisport_1”,“Hisport_2”,“Hisport_3”,“Hisport_4”,“Hisport_5”,“Hisport_6”,“Hisport_7”,“Hisport_8”,“Hisport_9”,“Hisport_10”,“Hisport_11”,“Hisport_12”,“Hisport_13”,“Hisport_14”,“Hisport_15”,“Hisport_16”,“Hisport_17”,“Hisport_18”,“Hisport_19”,“Hisport_20”,“Hisport_21”]
ChassisId=“1”
GroupId=4
GroupPosition=“0101”
Id=“”
IdentifyMode=3 // 下级组件识别模式为天池标准类型组件
LoadStatus=1 // 加载状态 1表示失败
ManagerId=“1”
Presence=1
SilkText=“J6023”
Slot=1
SystemId=1
Type=“ExpandBoard”
bmc.kepler.Object.Properties
ClassName=“Connector”
ObjectIdentifier=[0,“1”,“”,“01”]
ObjectName=“Connector_EXU_1_01”
TraceSamplingRate=0
Private
CSRVersion=“”
Chip=“Eeprom_3_1_01”
Container=“”
IdChipAddr=0
Position=1

mdbctl lsprop Connector_Sensor_01

bmc.kepler.Connector
AuxId=“0”
Bom=“14100513”
Buses=
ChassisId=“1”
GroupId=3
GroupPosition=“0102”
Id=“Sensor”
IdentifyMode=2
LoadStatus=0
ManagerId=“1”
Presence=1
SilkText=“”
Slot=20
SystemId=1
Type=“”
bmc.kepler.Object.Properties
ClassName=“Connector”
ObjectIdentifier=[0,“1”,“”,“01”]
ObjectName=“Connector_Sensor_01”
TraceSamplingRate=0
Private
CSRVersion=“”
Chip=“”
Container=“”
IdChipAddr=0
Position=2

12

另外在日志里看到，hwdiscovery这里加载csr部分好像有点问题，看上去和eeprom这块有点关系

1970-01-01 00:00:26.746083 hwdiscovery NOTICE: parser_work.lua(76): position: 00, process sr data successfully, uptime: 27 s, cost: 430ms

1970-01-01 00:00:26.818027 hwdiscovery NOTICE: sdr.lua(74): position: 01, get objects, count: 52

1970-01-01 00:00:26.866060 hwdiscovery NOTICE: component.lua(264): position: 00, setup resource tree successfully, uptime: 27 s

1970-01-01 00:00:26.877775 soctrl NOTICE: object_manage.lua(284): start to add objects, path: /bmc/kepler/ObjectGroup/00, life cycle id: 1, count: 1

1970-01-01 00:00:26.887095 hwdiscovery NOTICE: parser_work.lua(76): position: 01, process sr data successfully, uptime: 27 s, cost: 90ms

1970-01-01 00:00:26.911621 soctrl NOTICE: object_manage.lua(304): add objects callback, path: /bmc/kepler/ObjectGroup/00, life cycle id: 1, count: 1, took 40ms

1970-01-01 00:00:26.913456 soctrl NOTICE: object_manage.lua(315): add objects completely, path: /bmc/kepler/ObjectGroup/00, life cycle id: 1, took 0ms

1970-01-01 00:00:26.949448 hwdiscovery NOTICE: object_manage.lua(284): start to add objects, path: /bmc/kepler/ObjectGroup/01, life cycle id: 1, count: 2

1970-01-01 00:00:27.010879 hwdiscovery NOTICE: object_manage.lua(304): add objects callback, path: /bmc/kepler/ObjectGroup/01, life cycle id: 1, count: 2, took 70ms

1970-01-01 00:00:27.011894 hwdiscovery NOTICE: object_manage.lua(315): add objects completely, path: /bmc/kepler/ObjectGroup/01, life cycle id: 1, took 0ms

1970-01-01 00:00:27.029548 hwdiscovery NOTICE: component.lua(264): position: 01, setup resource tree successfully, uptime: 28 s

1970-01-01 00:00:27.033202 hwdiscovery NOTICE: hwcomponent.lua(309): [self-discovery] name: Connector_Sensor_01, position: 0102, current: 1, previous: 0,uptime: 28 s

1970-01-01 00:00:27.080186 hwdiscovery NOTICE: init.lua(162): position: 0102, get csr data from /opt/bmc/sr/14100513_Sensor_0.sr, format version: 3.00, data version: 3.00

1970-01-01 00:00:27.083662 hwdiscovery NOTICE: hwcomponent.lua(205): position: 0102, load sr data successfully, uptime: 28 s, cost: 10ms

1970-01-01 00:00:27.086034 hwdiscovery NOTICE: hwcomponent.lua(226): position: 0102, start to process sr data, source: /opt/bmc/sr/14100513_Sensor_0.sr, format version: 3.00, data version: 3.00, uptime: 28 s

1970-01-01 00:00:27.093414 hwdiscovery NOTICE: hwcomponent.lua(309): [self-discovery] name: Connector_EXU_1_01, position: 0101, current: 1, previous: 0,uptime: 28 s

1970-01-01 00:00:27.154880 hwdiscovery NOTICE: sdr.lua(74): position: 0102, get objects, count: 33

1970-01-01 00:00:27.166687 hwproxy NOTICE: object_manage.lua(284): start to add objects, path: /bmc/kepler/ObjectGroup/01, life cycle id: 1, count: 43

1970-01-01 00:00:27.193454 [:00000014] framework: LAUNCH snlua hwproxy/service/work Hisport

1970-01-01 00:00:27.205386 [:00000015] framework: LAUNCH snlua hwproxy/service/work Gpio_31

1970-01-01 00:00:27.213004 hwdiscovery NOTICE: parser_work.lua(76): position: 0102, process sr data successfully, uptime: 28 s, cost: 100ms

1970-01-01 00:00:27.226053 [:00000016] framework: LAUNCH snlua hwproxy/service/work Gpio_56

1970-01-01 00:00:27.280151 [:00000017] framework: LAUNCH snlua hwproxy/service/work Gpio_74

1970-01-01 00:00:27.302352 [:00000018] framework: LAUNCH snlua hwproxy/service/work I2c_1

1970-01-01 00:00:27.322695 [:00000019] framework: LAUNCH snlua hwproxy/service/work I2c_2

1970-01-01 00:00:27.374864 [:0000001a] framework: LAUNCH snlua hwproxy/service/work I2c_3

1970-01-01 00:00:27.378852 hwdiscovery NOTICE: component.lua(264): position: 0102, setup resource tree successfully, uptime: 28 s

1970-01-01 00:00:27.425637 [:0000001b] framework: LAUNCH snlua hwproxy/service/work I2c_4

1970-01-01 00:00:27.486661 [:0000001c] framework: LAUNCH snlua hwproxy/service/work I2c_5

1970-01-01 00:00:27.560208 [:0000001d] framework: LAUNCH snlua hwproxy/service/work I2c_7

1970-01-01 00:00:27.621199 [:0000001e] framework: LAUNCH snlua hwproxy/service/work I2c_8

1970-01-01 00:00:27.671938 [:0000001f] framework: LAUNCH snlua hwproxy/service/work I2c_11

1970-01-01 00:00:27.708113 [:00000020] framework: LAUNCH snlua hwproxy/service/work Jtag_1

1970-01-01 00:00:27.798028 [:00000022] framework: LAUNCH snlua hwproxy/service/work JtagOverLocalBus_1

1970-01-01 00:00:28.114526 key_mgmt NOTICE: kmc_kit.lua(28): Domain count : 12; mk count: 22

1970-01-01 00:00:28.127456 key_mgmt NOTICE: key_mgmt_app.lua(167): Return to main coroutine.

1970-01-01 00:00:28.128452 key_mgmt NOTICE: micro_component.lua(164): Startup status has changed, Starting ==> InitCompleted, uptime:29s, cost 3760ms

1970-01-01 00:00:28.190976 [:00000023] framework: LAUNCH snlua hwproxy/service/work I2c_6

1970-01-01 00:00:28.266154 hwproxy NOTICE: monitor.lua(164): start work monitor register, bus_name : Gpio_31

1970-01-01 00:00:28.271236 hwproxy NOTICE: monitor.lua(164): start work monitor register, bus_name : Hisport

1970-01-01 00:00:28.273485 hwproxy NOTICE: monitor.lua(164): start work monitor register, bus_name : Gpio_74

1970-01-01 00:00:28.276484 hwproxy NOTICE: monitor.lua(164): start work monitor register, bus_name : Gpio_56

1970-01-01 00:00:28.279113 hwproxy NOTICE: monitor.lua(164): start work monitor register, bus_name : I2c_2

1970-01-01 00:00:28.283087 hwproxy NOTICE: monitor.lua(164): start work monitor register, bus_name : I2c_1

1970-01-01 00:00:28.285307 hwproxy NOTICE: monitor.lua(164): start work monitor register, bus_name : I2c_3

1970-01-01 00:00:28.287591 hwproxy NOTICE: monitor.lua(164): start work monitor register, bus_name : I2c_5

1970-01-01 00:00:28.289895 hwproxy NOTICE: monitor.lua(164): start work monitor register, bus_name : I2c_4

1970-01-01 00:00:28.292647 hwproxy NOTICE: monitor.lua(164): start work monitor register, bus_name : I2c_7

1970-01-01 00:00:28.295427 hwproxy NOTICE: monitor.lua(164): start work monitor register, bus_name : Jtag_1

1970-01-01 00:00:28.299708 hwproxy NOTICE: monitor.lua(164): start work monitor register, bus_name : I2c_8

1970-01-01 00:00:28.311458 hwproxy NOTICE: monitor.lua(164): start work monitor register, bus_name : JtagOverLocalBus_1

1970-01-01 00:00:28.316536 hwproxy NOTICE: monitor.lua(164): start work monitor register, bus_name : I2c_11

1970-01-01 00:00:28.323305 hwproxy NOTICE: monitor.lua(164): start work monitor register, bus_name : I2c_6

1970-01-01 00:00:28.541757 maca WARNING: objmgr.lua(392): [maca]service: bmc.kepler.file_transfer, path: /bmc/kepler/file_transfer/MicroComponent, properties fetched without class name: nil or object name: nil

1970-01-01 00:00:28.568582 maca WARNING: objmgr.lua(392): [maca]service: bmc.kepler.file_transfer, path: /bmc/kepler/Managers/1/FileTransfer, properties fetched without class name: nil or object name: nil

1970-01-01 00:00:28.658150 hwproxy NOTICE: object_manage.lua(304): add objects callback, path: /bmc/kepler/ObjectGroup/01, life cycle id: 1, count: 43, took 1490ms

1970-01-01 00:00:28.670705 hwproxy NOTICE: dispatch.lua(221): position: 01, start to process chips in pre_type: Bus, topo_data[I2c_2], chip nums: 2

1970-01-01 00:00:28.671638 hwproxy NOTICE: dispatch.lua(101): position: 01, chip: Eeprom_3_1_01, start creat predevice bus handle, pre_device: I2c_2,is main app: true, not scans: true, not buses: false

1970-01-01 00:00:28.673467 hwproxy NOTICE: dispatch.lua(221): position: 01, start to process chips in pre_type: Bus, topo_data[Gpio_31], chip nums: 1

1970-01-01 00:00:28.674385 hwproxy NOTICE: dispatch.lua(101): position: 01, chip: Chip_Gpio_31_01, start creat predevice bus handle, pre_device: Gpio_31,is main app: true, not scans: true, not buses: false

1970-01-01 00:00:28.675802 hwproxy NOTICE: dispatch.lua(221): position: 01, start to process chips in pre_type: Bus, topo_data[Gpio_56], chip nums: 1

1970-01-01 00:00:28.676745 hwproxy NOTICE: dispatch.lua(101): position: 01, chip: Chip_Gpio_56_01, start creat predevice bus handle, pre_device: Gpio_56,is main app: true, not scans: true, not buses: false

1970-01-01 00:00:28.678390 hwproxy NOTICE: dispatch.lua(221): position: 01, start to process chips in pre_type: Bus, topo_data[Gpio_74], chip nums: 1

1970-01-01 00:00:28.679339 hwproxy NOTICE: dispatch.lua(101): position: 01, chip: Chip_Gpio_74_01, start creat predevice bus handle, pre_device: Gpio_74,is main app: true, not scans: true, not buses: false

1970-01-01 00:00:28.687512 hwproxy NOTICE: object_manage.lua(315): add objects completely, path: /bmc/kepler/ObjectGroup/01, life cycle id: 1, took 30ms

1970-01-01 00:00:28.750482 hwproxy NOTICE: dispatch.lua(221): position: 01, start to process chips in pre_type: Bus, topo_data[Gpio_31], chip nums: 1

1970-01-01 00:00:28.751591 hwproxy NOTICE: dispatch.lua(101): position: 01, chip: Chip_Gpio_31_01, start creat predevice bus handle, pre_device: Gpio_31,is main app: false, not scans: true, not buses: false

1970-01-01 00:00:28.756405 hwproxy NOTICE: dispatch.lua(221): position: 01, start to process chips in pre_type: Bus, topo_data[I2c_2], chip nums: 2

1970-01-01 00:00:28.757610 hwproxy NOTICE: dispatch.lua(101): position: 01, chip: Eeprom_3_1_01, start creat predevice bus handle, pre_device: I2c_2,is main app: false, not scans: true, not buses: false

1970-01-01 00:00:28.759135 hwproxy NOTICE: dispatch.lua(221): position: 01, start to process chips in pre_type: Bus, topo_data[Gpio_56], chip nums: 1

1970-01-01 00:00:28.760477 hwproxy NOTICE: dispatch.lua(221): position: 01, start to process chips in pre_type: Bus, topo_data[Gpio_74], chip nums: 1

1970-01-01 00:00:28.761641 hwproxy NOTICE: dispatch.lua(101): position: 01, chip: Chip_Gpio_74_01, start creat predevice bus handle, pre_device: Gpio_74,is main app: false, not scans: true, not buses: false

1970-01-01 00:00:28.761928 hwproxy NOTICE: dispatch.lua(101): position: 01, chip: Chip_Gpio_56_01, start creat predevice bus handle, pre_device: Gpio_56,is main app: false, not scans: true, not buses: false

1970-01-01 00:00:29.616285 maca NOTICE: base.lua(468): monitor component file_transfer added, service: bmc.kepler.file_transfer

1970-01-01 00:00:29.663259 maca NOTICE: base.lua(468): monitor component persistence added, service: bmc.kepler.persistence

1970-01-01 00:00:29.709017 maca NOTICE: base.lua(468): monitor component key_mgmt added, service: bmc.kepler.key_mgmt

1970-01-01 00:00:29.755743 maca NOTICE: base.lua(468): monitor component hwproxy added, service: bmc.kepler.hwproxy

1970-01-01 00:00:29.805693 maca NOTICE: base.lua(468): monitor component hwdiscovery added, service: bmc.kepler.hwdiscovery

1970-01-01 00:00:29.854097 maca NOTICE: base.lua(468): monitor component soctrl added, service: bmc.kepler.soctrl

1970-01-01 00:00:30.208266 hwdiscovery ERROR: hwcomponent.lua(185): position: 0101, get component sr failed, error: read eeprom header failed, err: Device access failed, BMC.Error.Unknow: ./opt/bmc/libmc/lualib/mc/context.lua:196: ./opt/bmc/libmc/lualib/sd_bus/object.lua:314: ./opt/bmc/apps/hwproxy/lualib/hwproxy_objects/app_bus.lua:104: …bmc/apps/hwproxy/lualib/hwproxy_objects/work_objects.lua:117: chip: Eeprom_3_1_01, bus: I2c_2, read failed: i2c.lua:117: response error, i2c read fail, ret: 5, input:{“len”:32,“has_error”:false,“name”:“Eeprom_3_1_01”,“is_trace”:false,“rw_type”:1,“type”:1,“offsetWidth”:2,“requestor”:“bmc.kepler.hwdiscovery”,“addr”:174,“mask”:4294967295,“addrWidth”:1,“offset”:0}, status: 1, count: 1

1970-01-01 00:00:31.267871 hwdiscovery ERROR: hwcomponent.lua(185): position: 0101, get component sr failed, error: read eeprom header failed, err: Device access failed, BMC.Error.Unknow: ./opt/bmc/libmc/lualib/mc/context.lua:196: ./opt/bmc/libmc/lualib/sd_bus/object.lua:314: ./opt/bmc/apps/hwproxy/lualib/hwproxy_objects/app_bus.lua:104: …bmc/apps/hwproxy/lualib/hwproxy_objects/work_objects.lua:117: chip: Eeprom_3_1_01, bus: I2c_2, read failed: i2c.lua:117: response error, i2c read fail, ret: 5, input:{“len”:32,“has_error”:false,“is_trace”:false,“name”:“Eeprom_3_1_01”,“rw_type”:1,“type”:1,“offsetWidth”:2,“requestor”:“bmc.kepler.hwdiscovery”,“addr”:174,“mask”:4294967295,“addrWidth”:1,“offset”:0}, status: 1, count: 2

14

这个问题应该不是原问题根因，如果要从这个方向探索，则需要发了ipmcget -d v命令后，收集一份一键收集的日志

18

这个一键收集到的日志，请问要怎么发出来呀

19

你好，这个日志要怎么发出来呀

21

image
image612×204 23.8 KB

这个可以上传

22

dump_info.txt (4.0 MB)

好的，已经上传！ 原始后缀是.tag.gz文件，帮忙瞧瞧是有啥问题

23

image
image487×526 44.1 KB

看日志，硬件资产清单一个都没上树，请分析下这块组件是否有问题

24

方便请教下这块是和啥组件相关吗? vpd？ general_hardware？

25

compute，network_adapter，storage