本文へスキップ
SDK Version: 2.4.0

FAQトラブルシューティングガイド

このガイドはDXNN SDK使用中に発生する一般的なエラーと症状を扱い、ステップバイステップの解決方法を提供します。

目次

  • Q1. コンテナ「Restarting」エラー（#dxrtd-conflict）
  • Q2. X11セッション警告とマウントエラー（Wayland問題）
  • Q3. ファームウェアバージョン不一致エラー
  • Q4. デバイスドライバー更新エラー
  • Q5. モデル-ランタイムバージョン互換性エラー
  • Q6. 共有メモリ（shm）不足エラー

Q1. コンテナ「Restarting」エラー（dxrtd競合）​

docker_run.sh実行後、コンテナの状態が繰り返しRestartingと表示されてコンテナに入れない場合に発生します。

診断ステップ​

  • Step 1. 状態確認: docker psを実行しSTATUSがRestarting (255)を繰り返すか確認します。
  • Step 2. ログ確認: docker logs <container_name>を実行し「Other instance of dxrtd is running」メッセージを確認します。
# コンテナ状態確認
docker ps

# 出力例: STATUSが'Restarting (255)'を繰り返す
CONTAINER ID   IMAGE             COMMAND                 STATUS                          NAMES
041b9a4933e3   dx-runtime:24.04  "/usr/local/bin/dxrtd"  Restarting (255) 4 seconds ago  dx-runtime-24.04

# コンテナログ確認
docker logs dx-runtime-24.04 
# 出力: "Other instance of dxrtd is running"

原因​

DEEPX Runtime Daemon（dxrtd）はシングルトンとして設計されています。システム全体（ホスト+すべてのコンテナ）で1つのインスタンスのみ実行できます。ホストでdxrtdがすでに実行中の場合、コンテナ内のデーモンが初期化に失敗してクラッシュループが発生します。

解決方法: ホストランタイムサービス（dxrtd）の停止​

方法1: ホストサービスの停止（推奨） コンテナ化されたデーモンがNPUを制御できるようにホストのサービスを停止します。

# ホストサービスの停止
sudo systemctl stop dxrt.service 

# コンテナの再実行
./docker_run.sh --target=dx-runtime --ubuntu_version=24.04

詳細は02. 環境設定のホストシステム準備セクションを参照してください。

方法2: コンテナ内での自動起動防止 ホストサービスを必ず維持する必要がある場合は、コンテナ起動時にデーモン（dxrtd）が自動起動しないよう設定します。

詳細は02. 環境設定の**Docker高度なトラブルシューティング（マルチランタイムコンテナ）**セクションを参照してください。

Q2. X11セッション警告とマウントエラー（Wayland問題）​

X11フォワーディング認証失敗によりGUIツールエラーが発生するか、コンテナ起動が拒否される場合です。

診断ステップ​

  • Q2.1 警告: 起動時に[WARN] it is recommended to use an X11 sessionが表示されます。
  • Q2.2 エラー: システム再起動またはログアウト後にコンテナがerror mounting /tmp/.docker.xauthで失敗します。

原因​

  • Q2.1: DX-TRONなどのGUIツールはX11に最適化されています。Waylandセッションはxauthプロセスを不安定にする可能性があります。
  • Q2.2: Waylandセッション終了時にX認証データが削除されるかディレクトリパスが変更され、Dockerマウントポイントが無効化される可能性があります。

解決方法: デフォルトシステムセッションをX11に設定​

最も安定した解決方法はログインセッションをX11（Xorg）に設定することです。これはUbuntu/GNOME環境の標準手順です。

Step 1. GDM設定の変更 GDM3設定ファイルを開きます。

sudo nano /etc/gdm3/custom.conf

WaylandEnable=falseのコメントを解除して、ログイン画面がXorgを使用するよう強制します。

# ログイン画面をXorgに強制
WaylandEnable=false

Step 2. 設定の適用 GDMを再起動するかシステムを再起動します。

sudo systemctl restart gdm3
# またはPCを単純に再起動

Step 3. リソースのクリーンアップ 再実行前に孤立したコンテナを削除します。

# 既存コンテナのクリーンアップ
docker compose -f docker/docker-compose.yml down --remove-orphans

# コンテナの再実行
./docker_run.sh --target=dx-runtime --ubuntu_version=24.04

詳細は02. 環境設定のDockerインストールセクションを参照してください。

Q3. ファームウェアバージョン不一致エラー​

NPUハードウェアのファームウェアが必要なソフトウェアスタックバージョンより古く、アプリケーションが中断される場合に発生します。

診断ステップ​

ターミナルで以下のエラーメッセージを確認します。

The current firmware version is X.X.X.
Please update your firmware to version Y.Y.Y or higher.

原因​

インストールされたDX-RT（ランタイム）ライブラリとNPUにフラッシュされたDX-FW（ファームウェア）間の不一致。

解決方法: ファームウェア（DX-FW）の更新とコールドブート​

方法1: 統合インストールスクリプトの使用（推奨） オールインワン設定スクリプトを使用してファームウェアを更新します。

./dx-runtime/install.sh --target=dx_fw

方法2: 専用CLIツール（dxrt-cli）の使用 特定のバイナリファイルを指定してファームウェアを手動更新します。

dxrt-cli -u ./dx-runtime/dx_fw/m1/X.X.X/mdot2/fw.bin

更新後の必須措置: コールドブート ハードウェアロジックを完全に初期化し、新しいファームウェアバージョンが適用されたことを確認するには、以下の手順に従います。

オプション1. 【推奨】コールドブート

  • 方法: システムを完全にシャットダウンし、残留電源を消費するために電源ケーブルを抜いてから再接続して電源を入れます。
  • 理由: NPUの完全なハードウェアレベルのリセットを保証する最も安定した方法です。

オプション2. リモート/SSH環境向け

  • 物理的な電源切断が不可能な場合（例: リモートサーバー室）、sudo rebootコマンドでOSレベルからシステムを再起動します。ほとんどの標準シナリオではシステム再起動でファームウェアを更新するのに十分です。

最終検証 再起動後、以下のコマンドを入力してファームウェアが正常に更新されたことを確認します。

dxrt-cli -s

詳細は02. 環境設定のファームウェア（DX-FW）の更新とアクティベーションセクションを参照してください。

Q4. デバイスドライバー更新エラー​

カーネルドライバーバージョンが古く、アプリケーション実行が中断される場合に発生します。

診断ステップ​

ターミナルで以下のエラーメッセージを確認します。

The current device driver version is X.X.X.
Please update your device driver to version Y.Y.Y or higher.

原因​

インストールされているカーネルドライバー（dx_rt_npu_linux_driver）が現在のDX-RTの最小要件を満たしていません。

解決方法: ホストOSでのデバイスドライバー更新​

これを解決するには、ホストオペレーティングシステムでドライバーモジュールを直接更新する必要があります。

Step 1. ドライバーモジュールのインストール ドライバーをターゲットとするインストールスクリプトを実行します。

./dx-runtime/install.sh --target=dx_rt_npu_linux_driver

Step 2. システム再起動 ドライバーをLinuxカーネルに再ロードする必要があるため、システム再起動が必須です。

sudo reboot

Step 3. 状態確認 再起動後、更新が正常に完了したことを確認します。

dxrt-cli -s
Dockerユーザーへの注意

Dockerコンテナはホストのカーネルを共有するため、ドライバー更新はコンテナ内部ではなくホストOSで実行する必要があります。コンテナ内部でドライバーを更新してもハードウェア通信レイヤーには影響しません。

詳細は02. 環境設定のモジュールのビルドとインストールセクションを参照してください。

Q5. モデル-ランタイムバージョン互換性エラー​

.dxnnファイルを生成したコンパイラーバージョンとランタイムライブラリバージョンが互換性がなく、アプリケーションが中断される場合に発生します。

診断ステップ​

ターミナルで以下のエラーメッセージを確認します。

The model's compiler version(X.X.X) is not compatible in this RT library. 
Please downgrade the RT library version to X.X.X or use a model file generated with a compiler version X.X.X or higher.

原因​

DX-COM（コンパイラー）とDX-RT（ランタイム）間のバージョン不一致時に発生します。

解決方法: 再コンパイルによるバージョン同期​

これを解決するには、モデルとランタイム環境が互換性のあるバージョンを使用するようにする必要があります。

方法1: モデルの再コンパイル（推奨） 現在のシステムのDX-RTバージョンと互換性のあるコンパイラーバージョンで.dxnnファイルを再生成します。最適なパフォーマンスと機能サポートを保証する最も安全な方法です。

方法2: ランタイムライブラリバージョンの調整 モデルの要件に合うバージョンでDX-RTを再インストールします。

注記

この方法を選択する場合、NPUドライバーとファームウェアの互換性も必ず再確認する必要があります。

バージョン確認ガイド 各モジュールの正確な互換性のある組み合わせを確認するには04. バージョン互換性のDXNN SDKバージョン互換性マトリックスを参照してください。

Copyright © DEEPX. All rights reserved.

Q6. 共有メモリ（shm）不足エラー​

モデルコンパイル中にDX-COM（DEEPXコンパイラー）のDockerデフォルト/dev/shmサイズが小さすぎる場合に発生します。

診断ステップ​

ターミナルで以下のエラーメッセージを確認します。

[ResourceError]: Insufficient shared memory (shm). Increase the available /dev/shm size (e.g. --shm-size for Docker).

原因​

Dockerコンテナにはデフォルトで64MBの/dev/shmが割り当てられます。DX-COMはモデルコンパイルプロセスで共有メモリを使用します。大きいまたは複雑なモデルをコンパイルする際にこのデフォルト上限を超える場合があります。

解決方法: Docker共有メモリサイズの増加​

方法1: docker runに--shm-sizeを使用（推奨） コンテナ起動時に--shm-sizeフラグを渡します。モデルサイズに応じて値を設定してください — 256mが一般的な出発点で、大型モデルの場合は1g以上に増やします。

docker run --shm-size=256m ...
# 大型モデルの場合
docker run --shm-size=1g ...

方法2: docker-compose.yml Docker Compose（例: docker_run.sh）でコンテナを管理する場合はdx-compilerサービス定義にshm_sizeフィールドを追加します。

services:
  dx-compiler:
    shm_size: '1gb'
適切なサイズの選択

256mの値でほとんどの場合が解決されます。より大きいまたはバッチ処理されるモデルでエラーが続く場合は1g以上に増やしてください。

Last updated: