新版本2603 component_drivers构建特别耗时、甚至卡死主机

Component Drivers SIG
1

使用了两种环境：

环境1：ubuntu 24.04 + Docker openubmc/ubuntu:24.04.2_26.03， 主机：华硕主板，CPU 12th Gen Intel(R) Core™ i7-12700K(20核)，内存：32GB。

环境2：WIN11 + WSL + ubuntu 24.04 + Docker openubmc/ubuntu:24.04.2_26.03，主机：CPU AMD Ryzen 5 6600U（6核双线程），内存：24GB。

git clone git@gitcode.com:openUBMC/component_drivers.git

cd component_drivers

VERBOSE=ON bingo build

一开始卡在：RUN: meson compile -C ….

image
image1470×244 41.5 KB

有时要很久，甚至怀疑死机了；原来远程SSH登录终端全没响应。

WSL + Docker gcc编译器还有自己内部报错：

image
image2244×343 259 KB

25.12-SP1就有这个迹象，不过貌似没这么严重。

不知道是不是哪里设置不对，造成这种现象。

2

答案内容由AI生成，仅供参考：
:white_check_mark: 总结

问题 原因 解决方案
构建卡顿、SSH 无响应 高并行度 + 高内存占用导致 OOM 降低 -j 参数，并分配更多内存
g++ internal compiler error: Killed cc1plus 被 OOM Killer 终止 使用更高内存环境或降低并发
WSL 下更易出错 WSL 资源隔离机制限制 配置 .wslconfig 或改用物理机
构建时间过长 依赖未缓存，触发源码编译 确保 Conan 二进制缓存可用

最终建议：在 高内存物理机或云主机 上，使用 低并行度（-j4~-j6） 构建 component_drivers，并确保 Conan 缓存完整。

如问题持续，建议将完整日志上传至 OpenUBMC 社区论坛，引用 topic/4308 等类似案例寻求进一步帮助。

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

新版本 component_drivers 构建耗时严重甚至卡死主机问题分析与解决建议

根据您提供的详细信息，您在构建 openUBMC 2603 版本的 component_drivers 组件时，遇到了编译过程极度耗时、系统无响应、甚至出现编译器崩溃（internal compiler error: Killed）的现象。此问题在 25.12-SP1 版本已有前兆，但在新版本中表现更为严重。

基于知识库中的实体、关系及文档内容，现对问题进行综合分析并提供可行的解决方案。

:pushpin: 问题核心定位

1. 根本原因：资源消耗过高导致编译失败或系统卡顿

从日志中可以看出，构建过程卡在：

[1/520] Compiling C++ object gen/libdevice_tree.so.p/src_device_tree_interface_OpticalModule.cpp.o

并最终触发：

aarch64-target-linux-gnu-g++: internal compiler error: Killed (program cc1plus)

此错误的直接原因是：cc1plus（GCC C++ 编译器前端）被操作系统杀死（Out of Memory, OOM）。

尽管您的主机配置较高（如 32GB 内存），但在以下情况下仍可能触发 OOM：

  • bingo build 默认使用高并行度编译（-j12），启动大量并行进程。
  • component_drivers 是“南向部件驱动集”，包含大量硬件驱动模块，尤其是光模块、GPU、I2C 等，代码量大、依赖复杂。
  • 交叉编译工具链（aarch64-target-linux-gnu-g++）本身内存占用高，每个并行编译任务可能占用 1~2GB 内存。
  • 多个 -j12 任务同时运行时，总内存需求远超物理内存，触发 Linux OOM Killer。

:white_check_mark: 文档 DC-1 中明确提到：

“南向设备树引入一大串驱动编译，component_driver编译极其消耗资源和时间，建议把社区的component_driver全部下载下来；建议搞个资源大的云主机编译”

:magnifying_glass_tilted_left: 详细成因分析

因素 说明
1. 高并发构建（-j12） meson compile -C ... -j12 表示最多启动 12 个并行编译任务。在资源密集型项目中极易导致内存溢出。
2. 生成代码量大（gen/ 目录） component_drivers 使用代码生成机制（如 gen/libdevice_tree.so.p/...），自动生成大量 C++ 接口代码，显著增加编译负担。
3. WSL 环境限制 WSL1/WSL2 对内存和资源调度有天然限制，尤其 WSL2 的默认内存配额通常为 50% 主机内存，且 I/O 性能较差。
4. Docker 内部资源未优化 即使使用 Docker，容器内的编译任务仍受限于主机资源分配，若未限制或优化，容易“吃光”系统资源。
5. 新版本引入更多驱动模块 2603 相较 25.12 可能增加了更多设备驱动，导致整体构建负载上升。

:white_check_mark: 推荐解决方案

:white_check_mark: 方案 1：降低并行编译任务数（-j 参数）

修改构建命令，限制并行度：

# 使用 -j4 或 -j6，降低内存压力
VERBOSE=ON bingo build -- -j4

:light_bulb: -- 后的参数会传递给底层构建系统（meson/ninja）。-j4 表示最多 4 个并行编译任务。

适用场景：内存有限（如 24GB）或 WSL 环境。

:white_check_mark: 方案 2：为容器或 WSL 分配更多内存

对于 WSL：

编辑 C:\Users\<用户>\.wslconfig 文件，增加内存限制：

[wsl2]
memory=24GB    # 最大使用 24GB 内存
processors=8   # 分配最多 8 个核心
swap=4GB
localhostForwarding=true

之后重启 WSL：

wsl --shutdown

对于 Docker：

运行容器时显式限制资源：

docker run -it \
  --memory="24g" \
  --cpus="8" \
  --privileged=true \
  --network host \
  --name build_env \
  -v $(pwd):/workspace \
  openubmc/ubuntu:24.04.2_26.03

:white_check_mark: 方案 3：使用高性能云主机或物理设备编译

如知识库中用户 zhenghaowei 所建议：

“建议搞个资源大的云主机编译”

推荐配置：

  • CPU：16 核以上（如 Intel i9 / AMD Ryzen 9 / 服务器级 CPU）
  • 内存：64GB 或以上
  • SSD：NVMe 固态硬盘，提升 I/O 性能

此类环境可从容应对高并行度构建，避免 OOM。

:white_check_mark: 方案 4：单独构建组件（避免整包构建）

不要直接在 manifest 中执行 bingo build，而是进入 component_drivers 目录单独构建，避免其他组件干扰。

cd component_drivers
bingo build --stage=dev -- -j6

这样可以：

  • 精准控制构建过程
  • 快速验证修复
  • 降低整体负载

:white_check_mark: 方案 5：检查并预下载 Conan 缓存（避免重复编译）

确保所有依赖已从远程缓存下载，避免“源码编译”导致超时。

# 查看远程仓库
conan remote list

# 提前下载依赖（可选）
conan install . --build=missing --remote=openubmc_dev

:warning: 若 Conan 缓存中无二进制包，会触发 Source Code Compilation，极大增加构建时间（见 Build Timeout 与 Source Code Compilation 关系）。

:white_check_mark: 方案 6：使用 VERBOSE=ON + 日志分析定位瓶颈

您已启用 VERBOSE=ON，建议结合以下方式排查：

  • 查看 task.log 中具体失败步骤。
  • 检查 /root/.conan2/p/... 路径下的编译日志。
  • 使用 htop 或 docker stats 实时监控 CPU 和内存使用情况。

:hammer_and_wrench: 其他建议

建议 说明
避免在 GUI 桌面环境编译 编译时关闭浏览器等内存大户，防止系统卡死。
使用 screen 或 tmux 防止 SSH 断开导致构建中断。
升级 bingo 工具版本 新版 bingo 对权限、缓存、错误处理有优化。
关注社区讨论 类似问题见于 topic/2124 和 Topic 2073，可参考解决方案。

:link: 参考资料与社区链接

:white_check_mark: 总结

问题 原因 解决方案
构建卡顿、SSH 无响应 高并行度 + 高内存占用导致 OOM 降低 -j 参数，并分配更多内存
g++ internal compiler error: Killed cc1plus 被 OOM Killer 终止 使用更高内存环境或降低并发
WSL 下更易出错 WSL 资源隔离机制限制 配置 .wslconfig 或改用物理机
构建时间过长 依赖未缓存，触发源码编译 确保 Conan 二进制缓存可用

最终建议：在 高内存物理机或云主机 上，使用 低并行度（-j4~-j6） 构建 component_drivers，并确保 Conan 缓存完整。

如问题持续，建议将完整日志上传至 OpenUBMC 社区论坛，引用 topic/4308 等类似案例寻求进一步帮助。

3

test

5

大佬，问下最终怎么解决的啊？我这边bingo build – -j4 执行没效果，还是调用了所有核心编译

image
image1059×274 7.33 KB

换了种方式，实践下来有效，可以参考下
进入容器目录cd /root/.conan2/profiles，修改profile.ini profile.luajit.ini文件，添加tools.build:jobs=8 配置项
image

image
image620×146 4.4 KB

image
image1073×336 9.37 KB

6

也可以通过修改项目根目录下的conanfile.py文件来配置核心数

image
image575×519 46 KB

1 个赞
7

看了机器人的提示，我记得尝试-j4成功过，不知道为啥后来又不行了（曼德拉效应？）

后来我发现，主要还是存储空间的问题，磁盘空间太少、甚至用光了就是卡。然后我每次编译之前都清理一下：

rm -r /root/.conan2/p/compo*
rm -r /root/.conan2/p/devmo*
rm -r /root/.conan2/p/vpd*
rm -r /root/.conan2/p/b/compo*
rm -r /root/.conan2/p/b/devmo*
rm -r /root/.conan2/p/b/vpd*

1 个赞