2406004_ja-JP

はい

[IMX8MQ]GPUがフリーズし、リカバリーはできません

当社では、IMX8MQをベースにしたカスタムボードを使用しており、ウェブベースのユーザーインターフェースが動作します。

私たちのテストシナリオでは、問題は約2〜3時間で再現可能です。問題が発生すると、GPU関連のエラーログが大量に生成され、その後、UI全体がフリーズします。その他のカーネルレベルの機能は引き続き使用可能です。

GPU復旧対策は実施しましたが、通常のGPU動作を回復することはできません。デバイスを完全に再起動する以外に解決策はありません。

OS: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は8M Quad EVKイメージ i.MX Linux 5.10.72を使用しています。また、NXPコミュニティトレースで、RDのGPUパッチがAndroid 11の同様の問題をAndroid 11.0.0_2.2.0で修正し、その後Android 11/12に実装された「GPUに関連する重大なパッチ」と記載されていました。

リカバリーについては、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です。その後、i.MX8MQ向けには11.0.0_2.2.0、2.4.0、2.6.0などのNXP Android 11版も存在します。GPU関連のAndroid 11修正は特に11.0.0_2.2.0に関連しているため、複雑なランタイムリカバリーに投資する前に、まず11.0.0_2.2.0以降でワークロードをテストしてください。

DDRのサイズとGPUアドレス可能なメモリの配置を確認してください。
i.MX8MファミリのGPUのいくつかのハングやエラーはメモリ構成に関連しています。NXPのあるスレッドによると、GAリリースのVivante GPUドライバーは4GBのメモリアドレス範囲をサポートしておらず、システムを3GBに制限しmem=3072MiBでシステムがACIバスエラーの失敗を回避したとされています。別の注意点では、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 to tune contiguous GPU memory

これらはまずアイソレーションテストとして扱うべきであり、最終的な生産変更ではなく、明確に故障を排除するものであれば例外です。

GPUの電源レールと動作モードを確認してください。
i.MX8MQのデータシートには、VDD_GPUの標準動作電圧が0.81～1.05と記載されている。V、典型的な0.9V、最大GPU周波数800MHz;オーバードライブモードは0.9〜1.05ですV、典型的な1.0V、最大GPU周波数は1GHz。VDD_GPU の絶対最大値は 1.1 V で、オーバードライブの場合に記録されます。単にレールを1.1Vに上げて「修正」するのではなく、代わりに、UI/GPU負荷時の実際のレール、リップル、ドループ、PMICシーケンス、GPUの周波数やOPPが設定電圧と一致しているかを確認してください。

本番環境からの復旧の代替手段として、再起動を使用してください。
より少ない破壊的な回復手順を試みることは可能です。例えば、UIアプリやWebViewを停止し、SurfaceFlingerを停止し、モジュールとして構築された場合はgalcoreのアンロード/再ロードなどです。ただし、ドキュメント化されたモジュール操作は通常のinsmodやrmmodの処理であり、ウェッジしたハードウェア状態からの確実な回復は保証されません。カーネルが生きているのにGPUログがフラッシュし、galcoreの復旧が失敗した場合は、ウォッチドッグやヘルスモニターから制御された再起動をトリガーしてください。

最小限トリアージマトリックス:

テスト	想定される解釈
NXP 11.0.0_2.2.0+ イメージで同じテストを実行します。	もし修正されていれば、根本原因は後のGPUやBSPパッチで既に解決されている可能性が高いです。
mem=3072MiBで起動	もし直ったなら、4GBの物理アドレス/GPUメモリ配置の問題が疑われます。
CMAを低メモリ領域に拡張/再配置する	もし修正されていれば、GPUの連続メモリ割り当てやアドレッシングが疑われます。
galcore.powerManagement=0 を追加します。	もし修正されていれば、GPUの電源管理移行やクロック、レールの相互作用が疑われます。
障害発生期間中にVDD_GPUを測定する	ドロップ/リップルが相関している場合は、PMIC/レール/OPPの設定を修正してください。
EVKで再現する	EVKが安定している場合は、カスタムボードのDDR、電源、熱、およびデバイスツリーに焦点を当ててください。