2406004_zh-CN

Yes

[IMX8MQ]GPU挂起且无法恢复

我们有一块基于IMX8MQ的定制开发板，它运行着一个基于Web的用户界面。

在我们的测试场景中，大约两到三个小时即可重现该问题。当问题发生时，会生成大量与 GPU 相关的错误日志，之后整个用户界面会冻结。其他内核级功能仍然可用。

我们已经实施了 GPU 恢复措施，但这些措施未能恢复 GPU 的正常运行。完全重启设备是唯一的解决办法。

操作系统：Android 11.0.0_2.0.0（Linux 5.10.9 内核）

请问您能否帮助我们提供以下两种方法之一：

1. 修复此问题

2. 恢复GPU

Re: [IMX8MQ]GPU hang and cannot be recovery

最实际的修复方法是放弃 Android 11.0.0_2.0.0 / Linux 5.10.9，并至少测试 Android 11.0.0_2.2.0，如果必须留在 Android 11 上，最好测试 11.0.0_2.6.0。NXP 的 Android 发布页面显示，11.0.0_2.0.0 使用的是 Linux 5.10.9，而后续的 Android 11 版本则使用了更新的 BSP：11.0.0_2.2.0 使用的是 Linux 5.10.35。11.0.0_2.4.0 使用 Linux 5.10.52，11.0.0_2.6.0 使用 Linux 5.10.72，适用于 i.MX 8M Quad EVK 镜像。我还发现 NXP 社区的跟踪记录显示，RD GPU 补丁修复了 Android 11.0.0_2.2.0 中类似的 Android 11 问题，并且这是一个“与 GPU 相关的主要补丁”，后来被应用到 Android 11/12 中。

对于恢复：一旦 Vivante/galcore GPU 完全死机，我不会依赖仅通过软件重置 GPU 来进行恢复。我发现的证据表明，galcore 可以尝试“GPU 挂起，自动恢复”并报告“恢复完成”，但相同的跟踪随后继续进入 AXI 总线错误 GPU 状态转储。另一份报告指出，reset_gpu 路径没有任何作用，因为“没有注册的重置控制”。实际上，如果 galcore 自动恢复失败，可靠的现场解决方法是受控系统重启，而不仅仅是重启 SurfaceFlinger/WebView 或 UI 进程。

建议的行动方案：

如果可能，请在 NXP i.MX8MQ EVK 或 NXP 演示镜像上重现该问题。
如果问题仅出现在定制主板上，请优先考虑板端口差异：DDR 时序/训练、GPU 电源轨行为、散热和设备树内存划分。NXP 针对类似的 i.MX8MQ 定制板 GPU 问题提供的指导是，使用 NXP 演示映像在参考板上重现问题；如果故障仅发生在定制板上，则重新运行 DDR 测试并使用更新的 LPDDR4 系数进行重建。

更新 BSP/GPU 驱动程序堆栈。
您的版本是 Android 11.0.0_2.0.0，Linux 版本为 5.10.9。NXP Android 11 的后续版本适用于 i.MX8MQ，包括 11.0.0_2.2.0、2.4.0 和 2.6.0。由于与 GPU 相关的 Android 11 修复程序专门与 11.0.0_2.2.0 版本相关联，因此在投入大量资源进行复杂的运行时恢复之前，请先在 11.0.0_2.2.0 或更高版本上测试您的工作负载。

检查DDR内存容量和GPU可寻址内存的位置。
多个 i.MX8M 系列 GPU 死机/错误与内存配置有关。NXP 的一个帖子说，正式版本中的 Vivante GPU 驱动程序不支持 4 GB 内存地址范围，将系统限制为 3 GB（mem=3072MiB）可以避免 AXI 总线错误故障。另一份说明指出，GPU 只能处理 0x10000000 到 0x80000000 区域内的物理内存，并建议将 CMA 内存分配到低内存中，以避免超出该范围的地址。作为一项快速实验，启动时减少内存，例如 mem=3072MiB，然后观察 2-3 小时的故障是否会消失。

查看 CMA / 连续 GPU 内存。
NXP 支持建议，对于类似的 i.MX8M GPU 崩溃情况，将 CMA 增加到总 DDR 的 25% 左右。Android 指南还提到使用 galcore.contiguousSize=xxx在内核命令行上设置GPU内存大小。如果您的 UI 大量使用 WebView/WebGL/视频/画布，则几个小时内 CMA 耗尽或碎片化可能是造成这种情况的原因。

尝试调整GPU驱动程序启动参数。
用于调试，请测试：

galcore.powerManagement=0 可禁用 GPU 电源管理单元

galcore.baseAddress=0x40000000 galcore.physSize=0 可禁用 GPU 平面映射

使用 galcore.contiguousSize=xxx 来调整连续 GPU 内存

除非这些测试能明显消除故障，否则应首先将其视为隔离测试，而不是最终的生产变更。

检查GPU电源轨和运行模式。
i.MX8MQ 数据手册列出的 VDD_GPU 标称工作电压范围为 0.81–1.05V，典型值为 0.9 V，GPU 最高频率为 800 MHz；超频模式下为 0.9–1.05 VV，典型值为 1.0 V，GPU 最大频率为 1 GHz。VDD_GPU 的绝对最大值为 1.1 V，注意过驱动。不要简单地将电压轨提高到 1.1 V 作为“解决方法”；相反，要确认实际的电压轨、纹波、UI/GPU 负载期间的电压下降、PMIC 时序，以及您的 GPU 频率/OPP 是否与配置的电压匹配。

使用重启作为生产环境恢复的备用方案。
您仍然可以尝试破坏性较小的恢复序列——停止 UI 应用程序/WebView，停止 SurfaceFlinger，如果 galcore 构建为模块，则卸载/重新加载 galcore——但记录的模块操作只是正常的 insmod / rmmod 处理，不能保证从硬件卡死状态中恢复。如果内核存活但 GPU 日志泛滥且 galcore 恢复失败，则从看门狗/健康监测触发受控重启。

最小分诊矩阵：

测试	预期解释
在 NXP 11.0.0_2.2.0+ 镜像上运行相同的测试	如果问题已解决，则根本原因可能已被后续的 GPU/BSP 补丁程序所解决。
启动时使用 3072MiB 内存	如果问题已解决，则怀疑是 4GB 内存/高物理地址/GPU 内存放置问题。
增加/迁移 CMA 到低内存	如果问题已解决，则怀疑是 GPU 连续内存分配/寻址问题。
添加 galcore.powerManagement=0	如果问题解决，则怀疑是 GPU 电源管理单元转换/时钟/电源轨交互问题。
在故障窗口期间测量 VDD_GPU	如果下垂/纹波相关，请修复 PMIC/轨道/OPP 配置。
在 EVK 上复现	如果 EVK 稳定，则重点关注定制板 DDR、电源、散热和设备树。