1877162_ja-JP

はい

imx8mp GPU メモリ割り当て 6.1.22 でのカーネルパニックおよび 6.1.55

imx8mpベースのボードでAIモデルを実行すると、p1739413および p1753940で説明されているのと同様に、メモリダンプカーネルパニックが発生しています。パニックは、プロセスが大量のシステムメモリを使用している場合に発生しているようで、GPUメモリが必要なプロセスを開始します。

最初にデバイス上でVSCODEサーバーを起動し(システムメモリのかなりのチャンクを使い果たすため)、次に次のgstreamerパイプラインを実行することで、エラーを非常に確実にトリガーできます。

gst-launch-1.0 videotestsrc ! video/x-raw,format=YUY2,width=1920,height=1080 ! vpuenc_h264 ! vpudec ! queue ! imxvideoconvert_g2d rotation=2 ! video/x-raw,width=800,height=480 ! videoconvert ! perf ! fakesink

システムの負荷によっては、g2d_basic_testを実行しているだけでもパニックに陥る可能性があることがわかりました。

このエラーがトリガーされたとき、使用可能なシステムメモリはまだ十分にあることに注意してください。多くの場合、800M>。私はそれが十分に大きく隣接する領域を得ることができないだけだと思います...

当社のボードはKarp QSXPモジュールに基づいていますが、標準のNXPカーネルを実行しています。モジュールには 2GB の LPDDR4 があります。
投稿から、問題はCMAとGPUの予約済みメモリに関連しているようです。imx8mp-evkと私たちのデバイスツリーの変更を見てきましたが、それらは最小限です。

// OURS
//
memory@40000000 {
	device_type = "memory";
	reg = <0x0 0x40000000 0 0x40000000>,
	      <0x1 0x00000000 0 0x40000000>;
};

&resmem {
	/* overwrite freescale cma setting since it's not allocatable on qsxp */
	linux,cma {
		size = <0 0x1e000000>;
		/delete-property/ alloc-ranges;
	};

	gpu_reserved: gpu_reserved@100000000 {
		no-map;
		reg = <0x1 0x00000000 0 0x10000000>;
	};
};


// EVK
//
memory@40000000 {
	device_type = "memory";
	reg = <0x0 0x40000000 0 0xc0000000>,
	      <0x1 0x00000000 0 0xc0000000>;
};

resmem: reserved-memory {
	#address-cells = <2>;
	#size-cells = <2>;
	ranges;

	/* global autoconfigured region for contiguous allocations */
	linux,cma {
		compatible = "shared-dma-pool";
		reusable;
		size = <0 0x3c000000>;
		alloc-ranges = <0 0x40000000 0 0xC0000000>;
		linux,cma-default;
	};

	gpu_reserved: gpu_reserved@100000000 {
		no-map;
		reg = <0x1 0x00000000 0 0x10000000>;
	};
};

私が試したこと:

- alloc-ranges を cma に追加します。(変更なし)

- devicetree に ldb_phy = okay を追加します。(変更なし)

- CMAサイズの増加/減少。

-単に壊れやすくなったり、VPU操作がメモリの割り当てに失敗したりするだけです。

- devictree から CMA を削除し、カーネルパラメータで CMA サイズを指定します。

- これにより、サイズに関係なく、常にVPUが壊れます。

- memory@40000000エントリを 2 つの 1G エントリではなく、単一の 2G エントリに置き換える。

- gpu_reserved を大きくします。(変更なし)

どんな助けでもいただければ幸いです。これは、cma がスペースを確保できない場合に想定される動作ですか?メモリをgpu_reserved専用にすることは可能ですか?つまり、スペースを共有していませんか?
割り当て範囲は大丈夫ですか?カーネル構成に有効にする必要があるもの、またはイメージに必要なGPUサービスはありますか?

Re: 6.1.22 での imx8mp gpu メモリ割り当てカーネルパニックおよび 6.1.55

さて、何週間も検索した後、5.15と6.1の画像の違いはgpu_reserved@100000000セクションであることがわかりました。
https://github.com/nxp-imx/linux-imx/commit/2d5c743aef9613a209b8256e54730ed5a3066a47
https://github.com/nxp-imx/linux-imx/commit/af10b4943109e588c82dc0aa5dfb58b2e620b551

私は(6.6および6.1 Linuxで)それを除外するとメモリの問題が解消されたことを確認できます。
&mix_gpu_ml {
/delete-property/ メモリ領域;
};

/delete-node/ &gpu_reserved;

今のところ、gpu-memory領域なしで、このように使用できます。

この時点で、問題はubootにあると思います。カーネルデバイスツリーで指定されたメモリアドレス範囲が使用されていないことに気付きました、それは検出されている/現在使用されているものに基づいて推測されるようです。

/* デバイスツリー */
memory@40000000 {
device_type = 「メモリ」;
reg = <0x00 0x40000000 0x00 0x40000000 0x01 0x00 0x00 0x40000000>;
};

/* /proc/devicetree */
memory@40000000 {
device_type = 「メモリ」;
reg = <0x00 0x40000000 0x00 0x80000000>;
};

したがって、カーネルはubootからメモリ設定を再設定するのではなく、メモリ設定を検出するだけだと思います。もしそうなら、おそらく NXP は、この変更がカーネルに導入されたのと同じ時点で uboot メモリ構成を変更したのでしょう。

Re: 6.1.22 での imx8mp gpu メモリ割り当てカーネルパニックおよび 6.1.55

@Bio_TICFSLデフォルトの imx8mp-evk カーネル設定にリセットしてみましたが、何も変わりませんでした。

私が試すことができる他のヒントはありますか?

Re: 6.1.22 での imx8mp gpu メモリ割り当てカーネルパニックおよび 6.1.55

返信ありがとうございます。サポートされているカーネルを使用していますが、Linux 6.1.55_2.2.1 リリース。

私はあなたが= yの代わりにCONFIG_MXC_GPU_VIV = mを意味していると思いますか?arch/arm64/configs/imx_v8_defconfigファイルを確認したところ、CONFIG_MXC_GPU_VIV=yが使われていました。