Android黑屏根因：Rockchip VPU的DMA-BUF泄漏

1. 黑屏卡死现场还原工位机不是“挂了”是被 DMA-BUF 慢慢勒紧了脖子那天下午三点十七分产线测试工位的 Android 工控机突然黑屏。不是重启不是崩溃日志满天飞而是屏幕彻底冻结、触控无响应、ADB 连接超时——但串口 console 里还能看到 kernel 日志在缓慢滚动dmesg输出里甚至夹杂着几行rockchip-vpu: vpu_enc: encode done的正常记录。这很反常。我们第一反应是 App 崩溃导致 ANR 或 SurfaceFlinger 卡死立刻adb shell dumpsys activity、dumpsys window、dumpsys gfxinfo全跑一遍结果 ActivityManager 显示所有进程都在 RUNNING 状态SurfaceFlinger 的 LayerList 也完整连adb shell screencap都能成功生成一张 PNG——只是这张图永远停留在黑屏前的最后一帧。更诡异的是top -n 1显示 CPU 占用率不到 5%内存剩余充足df -h磁盘空间还有 32GB。它没“死”它只是被某种看不见的东西锁住了呼吸。我们当时把排查路径全押在上层查了 App 的主线程 Looper 是否阻塞抓了systrace看 SurfaceFlinger 和 HWC 的帧提交链路甚至重刷了整套系统镜像。三天后问题复现而这次我顺手adb shell cat /proc/meminfo | grep -i dma发现DMA_UNMAPPED字段数值从初始的 12MB 涨到了 89MB且持续缓慢爬升。这个数字像一根针扎破了所有上层排查的泡沫。它指向一个被绝大多数 Android 开发者忽略的底层区域DMA-BUF。这不是 App 写得烂的问题也不是系统服务卡住的问题而是硬件加速器Rockchip VPU和用户态工具scrcpy之间在共享内存缓冲区的生命周期管理上悄悄打了个死结。这个结不松开系统就永远处于一种“半窒息”状态——表面平静内里缺氧。提示当你遇到 Android 设备黑屏但串口仍有日志、ADB 时断时续、screencap能执行却无法刷新画面时请立即检查/proc/meminfo中与 DMA 相关的字段而不是一头扎进logcat或dumpsys。这是区分“软件逻辑死锁”和“硬件资源泄漏”的第一道分水岭。2. scrcpy 与 Rockchip VPU 的握手协议为什么它们会“忘记”释放一块内存scrcpy 的核心价值在于零安装、低延迟、纯命令行控制 Android 设备。它不依赖 ADB forward而是通过adb shell screenrecord或更高效的adb shell /system/bin/screenrecord获取原始 H.264 流再由本地 FFmpeg 或 libav 解码渲染。但在 Rockchip 平台尤其是 RK3399/RK3566/RK3588 系列官方驱动对screenrecord的支持存在一个关键限制它默认使用软件编码器libstagefright性能差、发热高、延迟大。于是工程师们普遍改用 scrcpy 的-s参数强制启用硬件编码器即调用 Rockchip 提供的vpu_enc模块。这一步看似合理实则埋下了隐患的引信。关键点在于数据流转路径。当 scrcpy 启动并指定-s时它会通过libusb或adb向设备发送一条shell命令/system/bin/screenrecord --output-formath264 --size1280x720 --bit-rate2000000 /data/local/tmp/scrcpy.mp4。注意这里--output-formath264并非直接调用 FFmpeg而是触发 Rockchip VPU 的硬件编码流水线。VPU 编码器在启动时会向内核申请一组 DMA-BUFDirect Memory Access Buffer这些缓冲区物理地址连续可被 GPU、VPU、ISP 等硬件模块直接访问无需 CPU 拷贝。整个过程由rockchip-vpu驱动完成其内部通过dma_buf_export()创建 buffer并通过dma_buf_attach()将其绑定到 VPU 的 IOMMU 上。scrcpy 本身并不直接操作这些 buffer它只负责读取/data/local/tmp/scrcpy.mp4这个文件句柄——而这个文件句柄背后正是 VPU 编码器输出的 DMA-BUF 的 file descriptor。问题出在“释放”环节。标准screenrecord在录制结束时会调用close()关闭 fd并触发内核中dma_buf_release()的回调最终调用rockchip_vpu_enc_release_buffer()归还物理内存。但 scrcpy 的交互模式是“流式读取”它用adb shell启动screenrecord后并不等待其退出而是持续adb shell cat /data/local/tmp/scrcpy.mp4将数据流实时拉回本地。一旦网络抖动、本地解码器卡顿或用户 CtrlC 中断 scrcpyscreenrecord进程可能被SIGTERM强制杀死。此时screenrecord的 cleanup 函数来不及执行close()DMA-BUF 的引用计数refcount未能归零内核无法触发release回调。这块 buffer 就成了“孤儿 DMA-BUF”——它仍被 VPU 的 IOMMU 地址空间映射着物理内存无法回收/proc/meminfo中的DMA_UNMAPPED数值便开始累积。注意Rockchip VPU 驱动的dma_buf_release实现中有一个隐含前提screenrecord进程必须优雅退出。而 scrcpy 的流式拉取模型天然破坏了这一前提。这不是 bug而是两种设计哲学的冲突——scrcpy 追求极致的交互性Rockchip 驱动追求严格的资源生命周期管理。3. 根因定位三步法从 dmesg 到 iommu_group 的逐层穿透要确认 DMA-BUF 泄漏不能只看meminfo。必须建立一条从用户态行为到内核资源分配的完整证据链。我的排查流程分为三个递进层次每一步都提供可复现的命令和判断依据。3.1 第一层确认泄漏存在与趋势在设备复现黑屏前先开启监控# 在设备端后台运行每5秒记录一次关键指标 while true; do echo $(date) /data/local/tmp/dma_log.txt cat /proc/meminfo | grep -E (DMA|MemFree|Buffers) /data/local/tmp/dma_log.txt cat /sys/kernel/debug/dma_buf/buffer_count 2/dev/null /data/local/tmp/dma_log.txt sleep 5 done /sys/kernel/debug/dma_buf/buffer_count是内核暴露的 DMA-BUF 总数统计接口需CONFIG_DEBUG_FSy。如果该数值随 scrcpy 运行时间线性增长且DMA_UNMAPPED同步上升基本可锁定为 DMA-BUF 泄漏。此时dmesg | tail -50往往会出现rockchip-vpu: vpu_enc: failed to release buffer或iommu: pgtable invalid类似警告这是内核在尝试释放时发现 buffer 仍被占用的痕迹。3.2 第二层定位泄漏源进程与 buffer 详情当buffer_count超过 200Rockchip 平台典型阈值执行# 列出所有 DMA-BUF 及其持有者 ls -l /sys/kernel/debug/dma_buf/ | grep -v total # 输出类似lrwxrwxrwx 1 root root 0 Jan 1 00:00 00000000a1b2c3d4 - ../../../devices/platform/ff9a0000.vpu/dma-buf/00000000a1b2c3d4取其中一个 buffer ID如00000000a1b2c3d4查看其详细信息cat /sys/kernel/debug/dma_buf/00000000a1b2c3d4/name # 输出rockchip-vpu-enc-output cat /sys/kernel/debug/dma_buf/00000000a1b2c3d4/size # 输出2097152 (2MB) cat /sys/kernel/debug/dma_buf/00000000a1b2c3d4/attachments # 输出ff9a0000.vpu:0 (关键指向 VPU 设备)最关键的attachments字段明确显示该 buffer 被ff9a0000.vpuRockchip VPU 的设备节点所 attach。这证明泄漏源确实在 VPU 驱动侧而非 GPU 或 ISP。3.3 第三层关联到具体用户态进程仅知道是 VPU 不够要找到谁启动了它。利用pidof和ps结合lsof需预装# 查找所有打开 /dev/video* 或 /dev/vpu* 的进程 ls -l /proc/*/fd/ 2/dev/null | grep -E (video|vpu) | awk {print $9,$11} | sort -u # 输出类似/proc/1234/fd/15 - /dev/vpu_enc # 然后查 pid 1234 对应的进程 ps -p 1234 -o pid,ppid,comm,args # 极大概率显示1234 1233 screenrecord --output-formath264 ...至此证据链闭环scrcpy 启动的screenrecord进程 → 打开 VPU 设备 → 分配 DMA-BUF → 进程异常终止 → buffer 未释放 →DMA_UNMAPPED持续增长 → 物理内存耗尽 → 系统调度失灵 → 黑屏卡死。经验不要迷信ps aux | grep screenrecord。screenrecord在 Rockchip 平台常以sh -c screenrecord ...方式启动父进程可能是adbd。务必用lsof或/proc/*/fd/直接扫描文件描述符这是唯一可靠的方式。4. 临时规避与永久修复两条路径的实操细节与代价权衡确认根因后方案分两类快速上线的临时规避Hotfix和需要固件/驱动升级的永久修复Permanent Fix。二者适用场景不同选择取决于产线交付压力与研发资源。4.1 临时规避强制进程优雅退出 buffer 清理脚本这是最现实的选择。核心思路是不让screenrecord被粗暴 kill而是模拟其正常退出流程。我们修改了 scrcpy 的启动脚本在CtrlC时发送SIGUSR1信号给screenrecord进程Rockchipscreenrecord支持该信号触发 cleanup# 修改 scrcpy 启动命令为自定义 wrapper #!/bin/bash # scrcpy-wrapper.sh SCREENRECORD_PID cleanup() { if [ -n $SCREENRECORD_PID ]; then adb shell kill -USR1 $SCREENRECORD_PID 2/dev/null # 等待 2 秒让其执行 cleanup sleep 2 fi exit 0 } trap cleanup SIGINT SIGTERM # 启动 screenrecord 并捕获 PID adb shell screenrecord --output-formath264 --size1280x720 --bit-rate2000000 /data/local/tmp/scrcpy.mp4 echo \$! /tmp/sr_pid.txt SCREENRECORD_PID$(adb shell cat /tmp/sr_pid.txt 2/dev/null) # 启动 scrcpy 拉流 scrcpy -s $1 --record /tmp/scrcpy.mp4同时部署一个守护脚本定期检查并清理残留 buffer# /system/bin/clean-dma-buf.sh #!/system/bin/sh if [ $(cat /sys/kernel/debug/dma_buf/buffer_count 2/dev/null) -gt 150 ]; then # 强制触发 VPU 驱动的 cleanup hook需 Rockchip 驱动支持 echo 1 /sys/module/rockchip_vpu/parameters/force_cleanup # 或重启 VPU 模块风险较高仅用于紧急恢复 # rmmod rockchip_vpu modprobe rockchip_vpu fi此方案上线后黑屏故障率下降 98%但代价是每次 scrcpy 退出有 2 秒延迟且需定制化脚本维护。4.2 永久修复驱动层 refcount 保护与 timeout 机制根本解决必须在 Rockchip VPU 驱动中。我们向 Rockchip 提交了补丁核心修改两点增加 DMA-BUF refcount 的原子保护在rockchip_vpu_enc_submit()中对每个新分配的 buffer调用dma_buf_get()增加引用计数在rockchip_vpu_enc_stop()中确保dma_buf_put()被调用即使进程异常退出。驱动内部维护一个struct list_head记录所有 active buffervpu_enc_release()时遍历该链表强制put。引入 buffer 生命周期 timeout为每个 DMA-BUF 添加jiffies时间戳。在rockchip_vpu_enc_poll()中若检测到某 buffer 的jiffies - last_used 30*HZ30秒且 refcount 1则主动调用dma_buf_put()并打印 warning log。这相当于给“孤儿 buffer”设定了自动回收的保质期。该补丁已集成进 Rockchip Linux SDK v2.3.0但要求客户升级内核模块。对于旧设备我们提供了insmod替换驱动的离线包经 72 小时压力测试DMA_UNMAPPED稳定在 8~12MB 区间完全消除泄漏。实测心得临时规避方案在产线验证时曾因SIGUSR1信号未被screenrecord正确处理而失效。后来发现是 Android 10 的screenrecord二进制版本差异——RK3399 平台需使用screenrecordv1.2而 RK3588 需 v1.5。务必根据 SoC 型号匹配screenrecord版本否则kill -USR1无效。5. Rockchip 平台 DMA-BUF 的特殊性为什么其他芯片不会这么“脆”同样是硬件编码器高通QCom、联发科MTK平台极少出现此类 DMA-BUF 泄漏导致的黑屏。这并非 Rockchip 驱动质量差而是其 DMA-BUF 实现架构的“极简主义”特性所致。理解这一点才能避免未来踩同类坑。5.1 内存管理模型的根本差异高通 Adreno VPU采用 ION 内存管理器。ION 为每个 buffer 分配独立的ion_handle并通过ion_map_dma建立 IOMMU 映射。关键在于ION 的ion_free()接口是“强释放”——即使用户态 fd 未 close只要ion_handle被 destroyIOMMU 映射立即解除物理内存可回收。screenrecord进程 crash 后内核会自动清理其持有的ion_handle。Rockchip VPU绕过 ION直接使用dma_bufAPI。其rockchip_vpu_enc_alloc_buffer()返回的struct dma_buf *其release回调函数rockchip_vpu_enc_release_buffer()严格依赖dma_buf_put()的调用。而dma_buf_put()的触发条件是struct dma_buf *的 refcount 归零这又依赖于用户态close(fd)。Rockchip 驱动没有实现类似 ION 的“兜底释放”机制。5.2 硬件设计带来的约束Rockchip VPU 的 DMA 引擎设计为“单次配置、长期运行”。其寄存器组如VPU_ENC_CTRL,VPU_ENC_BUF_ADDR在初始化后极少重写。这意味着一旦 buffer 被映射到 VPU 的 IOMMU除非显式调用rockchip_vpu_enc_stop()否则 VPU 硬件会一直持有该映射。而stop()函数内部才调用dma_buf_put()。这种设计提升了编码吞吐量减少寄存器重配置开销但也放大了资源泄漏的风险——一个未 stop 的 encoder就是一个永不释放的 buffer 锁。5.3 对开发者的启示不要假设“标准 API 标准行为”dma_buf_export()是 Linux 内核的标准 API但不同厂商驱动对其release回调的实现逻辑千差万别。Rockchip 的实现是“用户态责任型”你必须保证close()高通是“内核兜底型”内核帮你善后。作为 Android 系统工程师面对硬件加速器绝不能只看man 2 open必须深入阅读对应 SoC 的 VPU 驱动源码重点关注xxx_alloc_buffer()和xxx_release_buffer()的实现细节。我在 RK3566 平台上曾误用 MTK 的mmp_dump工具分析 buffer结果发现其dump接口返回的 buffer size 总是 0——因为 Rockchip 驱动压根没实现dma_buf_ops-mmap只实现了export和attach。这就是“标准 API 下的非标实现”。教训在 Rockchip 平台做任何涉及 DMA-BUF 的开发如自定义 camera HAL、AI 推理加速第一步不是写代码而是grep -r dma_buf drivers/media/platform/rockchip/vpu/把rockchip_vpu_enc.c里所有dma_buf_*调用的上下文逻辑吃透。否则你的“高性能”代码可能就是下一个黑屏的源头。6. 从工位机到车载中控DMA-BUF 泄漏的泛化风险与防御体系这次工位机黑屏表面是个孤立事件实则是嵌入式 Android 系统在硬件加速普及时代的一个缩影。随着 Rockchip、Allwinner、Amlogic 等国产 SoC 在智能座舱、工业平板、教育终端的大规模应用DMA-BUF 泄漏正从偶发故障演变为系统性风险。我们必须构建一套跨层级的防御体系而非头痛医头。6.1 编译期防御为 DMA-BUF 操作添加静态检查在 Android Build System 中我们为rockchip_vpu模块启用了CONFIG_DMA_API_DEBUGy并在Android.mk中加入LOCAL_CFLAGS -DDMA_DEBUG_CHECKS \ -DROCKCHIP_VPU_DEBUG_BUFFER_LIFECYCLE这会在dma_buf_export()和dma_buf_put()处插入pr_info()日志并在rockchip_vpu_enc_submit()中记录 buffer 的分配栈dump_stack()。上线后dmesg中出现大量rockchip-vpu: alloc buffer 0x12345678, caller: rockchip_vpu_enc_submit0x123/0x456让我们能精准定位到哪一行代码分配了 buffer以及它是否被正确 put。6.2 运行时防御轻量级 buffer 监控 Agent我们开发了一个 12KB 的dma-monitor守护进程常驻内存每 30 秒读取/sys/kernel/debug/dma_buf/buffer_count和/proc/meminfo。若buffer_count 100且DMA_UNMAPPED 50MB则触发adb shell dumpsys meminfo | grep -A 10 rockchip并将结果上报至运维平台。更关键的是它能ioctl到 VPU 驱动查询当前 active buffer 列表并计算每个 buffer 的存活时间。一旦发现超时 buffer立即调用rockchip_vpu_force_cleanup()驱动新增接口。该 Agent 已集成进产线 OTA 包成为设备健康度的“血压计”。6.3 架构层防御推行“DMA-BUF 使用契约”我们制定了三条硬性规范写入所有硬件加速模块的 Code Review Checklist必须配对原则每个dma_buf_export()必须有且仅有一个对应的dma_buf_put()且位于同一函数作用域或明确的 cleanup 函数中。超时兜底原则所有 DMA-BUF 分配必须设置ktime_t deadline并在主循环中检查ktime_after(ktime_get(), deadline)超时则强制put。错误传播原则dma_buf_attach()失败时必须立即dma_buf_put()已分配的 buffer禁止“半途而废”。这三条原则已在新项目中 100% 落地。最近一个基于 RK3588 的车载中控项目连续 30 天压力测试DMA_UNMAPPED最高值为 11.2MB系统稳定性提升 400%。最后分享一个细节我们在rockchip_vpu_enc_release_buffer()中增加了WARN_ON(!list_empty(vpu_ctx-active_buffers))。上线后该WARN_ON触发了 7 次全部指向同一个第三方 camera HAL 的 bug——它在stop_streaming()时未清空active_buffers链表。这证明防御体系的价值不仅在于防自己更在于揪出别人的“定时炸弹”。