2406004_en-US

[#1]

[IMX8MQ]GPU hang and cannot be recovery

We have a custom board based on the IMX8MQ which runs a web-based UI. 

In our test scenario, the issue can be reproduced in roughly two to three hours. When the problem occurs, a flood of GPU‑related error logs are generated, after which the entire UI freezes. Other kernel‑level functions remain usable.

We have implemented GPU recovery measures, yet they fail to restore normal GPU operation. A full device reboot is the only workaround.

OS: Android 11.0.0_2.0.0 (Linux 5.10.9 kernel)

Can you please help us in providing a way to either:

1. Fix this issue

2. Recover the GPU

Re: [IMX8MQ]GPU hang and cannot be recovery

The most practical fix path is to move off Android 11.0.0_2.0.0 / Linux 5.10.9 and test at least Android 11.0.0_2.2.0, preferably 11.0.0_2.6.0 if you must stay on Android 11. NXP’s Android release page shows 11.0.0_2.0.0 uses Linux 5.10.9, while later Android 11 drops use newer BSPs: 11.0.0_2.2.0 uses Linux 5.10.35, 11.0.0_2.4.0 uses Linux 5.10.52, and 11.0.0_2.6.0 uses Linux 5.10.72 for i.MX 8M Quad EVK images . I also found an NXP community trace stating that an RD GPU patch fixed a similar Android 11 issue in Android 11.0.0_2.2.0, and that it was a “major patch associated with GPU” later carried into Android 11/12 .

For recovery: I would not rely on a software-only GPU reset once the Vivante/galcore GPU is hard-hung. The evidence I found shows galcore can attempt “GPU hang, automatic recovery” and report “recovery done,” but the same trace then continues into an AXI BUS ERROR GPU state dump . Another report notes that the reset_gpu path did nothing because there was “no registered reset control” . In practice, if galcore automatic recovery fails, the robust field workaround is a controlled system reboot, not only restarting SurfaceFlinger/WebView or the UI process.

Recommended action plan:

• Reproduce on NXP i.MX8MQ EVK or NXP demo image if possible.
  If the issue appears only on the custom board, prioritize board-port differences: DDR timing/training, GPU power rail behavior, thermal, and device-tree memory carveouts. NXP guidance for similar i.MX8MQ custom-board GPU problems is to reproduce on the reference board with NXP demo images; if the failure is custom-board-only, rerun DDR tests and rebuild with updated LPDDR4 coefficients .

• Update BSP / GPU driver stack.
  Your release is Android 11.0.0_2.0.0 with Linux 5.10.9. Later NXP Android 11 releases exist for i.MX8MQ, including 11.0.0_2.2.0, 2.4.0, and 2.6.0 . Because a GPU-related Android 11 fix is specifically associated with 11.0.0_2.2.0 , first test your workload on 11.0.0_2.2.0 or newer before investing in elaborate runtime recovery.

• Check DDR size and GPU-addressable memory placement.
  Several i.MX8M-family GPU hangs/errors are tied to memory configuration. One NXP thread says the Vivante GPU driver in a GA release did not support the 4 GB memory address range and that limiting the system to 3 GB with mem=3072MiB avoided the AXI BUS ERROR failure . Another note states the GPU can only handle physical memory in the 0x10000000 to 0x80000000 area and suggests assigning CMA memory into low memory to avoid addresses above that range . As a quick experiment, boot with reduced memory, for example mem=3072MiB , and see whether the 2–3 hour failure disappears.

• Review CMA / contiguous GPU memory.
  NXP support recommends increasing CMA to about 25% of total DDR for similar i.MX8M GPU crash scenarios . The Android guidance also mentions using galcore.contiguousSize=xxx on the kernel command line to set GPU memory size . If your UI uses WebView/WebGL/video/canvas heavily, CMA exhaustion or fragmentation over a few hours is a plausible cause.

• Try GPU driver boot-parameter mitigations.
  For debug, test:

• galcore.powerManagement=0 to disable GPU power management

• galcore.baseAddress=0x40000000 galcore.physSize=0 to disable GPU flat mapping

• galcore.contiguousSize=xxx to tune contiguous GPU memory

These should be treated as isolation tests first, not final production changes, unless they clearly eliminate the failure.

• Verify GPU power rail and operating mode.
  The i.MX8MQ datasheet lists VDD_GPU nominal-mode operation as 0.81–1.05 V, typical 0.9 V, with maximum GPU frequency 800 MHz; overdrive mode is 0.9–1.05 V, typical 1.0 V, with maximum GPU frequency 1 GHz . Absolute maximum for VDD_GPU is 1.1 V, noted for overdrive . Do not simply raise the rail to 1.1 V as a “fix”; instead, confirm the actual rail, ripple, droop during UI/GPU load, PMIC sequencing, and whether your GPU frequency/OPP matches the configured voltage.

• Use reboot as the production recovery fallback.
  You can still attempt a less disruptive recovery sequence — stop UI app/WebView, stop SurfaceFlinger, unload/reload galcore if built as a module — but the documented module operation is only normal insmod / rmmod handling , not guaranteed recovery from a wedged hardware state. If the kernel is alive but GPU logs flood and galcore recovery fails, trigger a controlled reboot from a watchdog/health monitor.

Minimal triage matrix:

Test	Expected interpretation
Run same test on NXP 11.0.0_2.2.0+ image	If fixed, root cause is likely already addressed by later GPU/BSP patches.
Boot with mem=3072MiB	If fixed, suspect 4 GB / high physical address / GPU memory placement issue.
Increase/relocate CMA into low memory	If fixed, suspect GPU contiguous-memory allocation/addressing.
Add galcore.powerManagement=0	If fixed, suspect GPU power-management transition/clock/rail interaction.
Measure VDD_GPU during failure window	If droop/ripple correlates, fix PMIC/rail/OPP configuration.
Reproduce on EVK	If EVK is stable, focus on custom board DDR, power, thermal, and device tree.