ホスト アプリケーションがメモリにアクセス中にハングする - 2020.2 Japanese

Vitis 統合ソフトウェア プラットフォームの資料: アプリケーション アクセラレーション開発 (UG1393)

Document ID
UG1393
Release Date
2021-03-22
Version
2020.2 Japanese
アプリケーションのハングは、ホスト コードからの不完全な DMA 転送により発生することもあります。これは、必ずしもホスト コードが間違っているということではなく、カーネルが無効なトランザクションを発行したために AXI がロックアップすることもあります。
  1. プラットフォームに Vitis ターゲット プラットフォームと同様の AXI ファイアウォールがある場合、ファイアウォールが作動します。ドライバーにより SIGBUS が発行され、アプリケーションが強制終了されて、デバイスがリセットされます。これは xbutil query を実行するとチェックできます。次の図に、このようなファイアウォール ステータスのエラーを示します。
    Firewall Last Error Status:
    		0:		0x0	 (GOOD)
    		1:		0x0	 (GOOD)
    		2:		0x80000 (RECS_WRITE_TO_BVALID_MAX_WAIT). 
    				  Error occurred on Tue 2017-12-19 11:39:13 PST
    
    Xclbin ID:	0x5a39da87
    ヒント: ファイアウォールが作動しなかった場合、Linux ツール dmesg で追加の情報が示される場合があります。
  2. ファイアウォールが作動した場合は、DMA タイムアウトの原因を特定することが重要です。原因には、無効な DMA 転送、カーネルの誤動作などが考えられます。AXI ファイアウォールが作動すると、アプリケーションの強制終了後にドライバーのヘルス チェック機能によりボードがリセットされ、デバイス上にある根本的な原因を特定する役立つ情報はすべて失われます。この問題をデバッグするには、xclmgmt カーネル モジュールでヘルス チェック スレッドをディスエーブルにして、エラーがキャプチャされるようにします。これには、一般的な Unix カーネル ツールを次の順で使用します。
    1. sudo modinfo xclmgmt: モジュールの現在の設定をリストし、health_check パラメーターがオンかオフかを示します。xclmgmt モジュールへのパスも返します。
    2. sudo rmmod xclmgmt: xclmgmt カーネル モジュールを削除してディスエーブルにします。
    3. sudo insmod <path to module>/xclmgmt.ko health_check=0: ヘルス チェックをディスエーブルにした状態で xclmgmt カーネル モジュールを再インストールします。
      ヒント: このモジュールへのパスは、modinfo への呼び出しの出力にレポートされます。
  3. ヘルス チェックをディスエーブルにしたら、アプリケーションを再実行します。前述のように、カーネル インストルメンテーションを使用して問題を特定できます。