# カーネルの問題のトラブルシューティング

カーネルの問題をトラブルシューティングするには、以下の方法を使用します。

## 誤ったDTBが選択されている、またはDTBが選択されていないことが原因の起動エラー

DTBの読み込みの問題が原因の起動エラーをトラブルシューティングする場合、認証とDTBの使用可否を確認して、問題修正の手順に従います。

次のような場合、起動エラーが発生します。

- **認証エラー**

    以下の例は、認証の誤りによるエラーのログを示しています。

Platform Subtype : 0
        DtPlatformLoadDtb qcs6490-rb3gen2.dtb is loaded
        Platform Subtype : -2090817768
        DtPlatformLoadSign qcs6490-rb3gen2.sgn is loaded
        failed to authenticate image !
        Copy to clipboard
- **DTBが使用できないことによるエラー**

    以下の例は、DTBがないことによるエラーのログを示しています。

DtPlatformLoadDtb qcs6490-rb3gen2.dtb is loading failed with Status = E
        DtPlatformDxeEntryPoint: no DTB blob could be loaded, defaulting to ACPI (Status == Not Found)
        Copy to clipboard

    DTBが使用できない問題を修正するには、以下を実行します。

    - 対応するDTBファイルが、パッケージ化された `efi.bin` ファイルの一部であるか確認します。
    - `efi.bin` ファイルをホスト開発機でローカルでマウントし、以下のことを確認します。

mount -t vfat efi.bin /mnt/
            
            ls -lR /mnt/
            Copy to clipboard
- **読み込まれたDTBをカーネルログから確認するには**

    以下のコマンドを使用すると、起動中に読み込まれたDTBをカーネルログから確認できます。

dmesg | grep -i model
        Copy to clipboard

## シリアルコンソールが動作しない

シリアルコンソールログのエラーをトラブルシューティングするには、特定のドライバーをカーネル構成で有効にして、関連パラメーターをカーネル起動引数に追加します。

- 以下のドライバーをカーネル構成ファイルで有効にします。

    - `CONFIG_SERIAL_QCOM_GENI=y`
    - `CONFIG_SERIAL_QCOM_GENI_CONSOLE=y`
- 以下のパラメーターをカーネル起動引数に追加します。

console=ttyMSM0,115200n8
        Copy to clipboard
- カーネルから早期起動メッセージを取得するには、以下のパラメーターをカーネル起動引数に追加します。

earlycon
        Copy to clipboard

## リモートプロセッサーのエラーをデバッグする

remoteprocエラーをトラブルシューティングするには、カーネルログを取得し、対応するファームウェア署名ファイルを使用して、デバイス内のファームウェアの位置を確認します。

- 対応するすべてのサブシステム・イメージが正常にフラッシュされていることを確認します。
- カーネルログにエラーがないか確認します。

    以下の例は、サンプルのカーネルログを示しています。

0x000000000A27652C |   5198.790423:   qcom_q6v5_pas 3000000.remoteproc: fatal error received: err_inject_crash.c:413:Crash injected via Diag
        0x000000000A276689 |   5198.801061:   remoteproc remoteproc2: crash detected in 3000000.remoteproc: type fatal error
        0x000000000A2767A1 |   5198.809602:   remoteproc remoteproc2: handling crash #1 in 3000000.remoteproc
        0x000000000A27688E |   5198.816837:   remoteproc remoteproc2: recovering 3000000.remoteproc
        0x000000000A276971 |   5198.823784:   qcom_q6v5_pas 8a00000.remoteproc: subsystem event rejected
        Copy to clipboard
- 以下のサブシステムの再起動エラーを無効にして、remoteprocクラッシュ署名がカーネルログで表示されるようにします。

echo disabled > /sys/kernel/debug/remoteproc/remoteprocN/recovery
        Copy to clipboard
- rootfsファイルシステムの `/lib/firmware/qcom/<SoC>` に、必要なファームウェアファイルがすべてあることを確認します。

## イメージに反映されていない構成やシンボルをデバッグする

カーネル構成変更で構成やシンボルがイメージに反映されない問題をデバッグするには、以下の手順に従います。

1. デバッグ構成ドライバーを `arch/arm64/configs/qcom_debug.config` ファイルに追加します。
2. `DEBUG_BUILD=1` マクロを、`bitbake` コマンドの実行前にエクスポートします。

注釈

以前のデバッグ構成ファイルはカスタムBSPバリアントに関連しています。基本BSPバリアントについては、`qcom.cfg` ファイルに変更を追加します。

## システムメモリの容量が少なすぎる

システムの空きメモリ容量が不足する問題をデバッグするには、[メモリ不足](https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-12/debugging_linux_kernel.html#out-of-memory) を参照してください。

## 起動中にDTBを識別する

デバイスの起動時に、ブートローダーは以下のIDを確認して、対応するDTBファイルを読み込みます。

qcom,msm-id = <x z>;
    qcom,board-id = <y y'>;
    Copy to clipboard

- x = SoCのID
- z = SoCのリビジョンのID（予備フィールド）
- y = CDP、MTP（ハードウェアのバリアント）、プラットフォームのID
- y' = サブタイプのID（ない場合は0）

## RTカーネルのデバッグ

RTカーネルの問題のトラブルシューティングには、以下の方法が使用されます。

- 基礎となるカーネルがリアルタイムであることをどのように確認すればよいですか？

    起動が完了した後、以下のコマンドを実行してカーネルの種類を確認します。

uname -r
        6.6-rt15
        uname -v
        SMP PREMPT_RT
        Copy to clipboard
- ドライバーをRTに準拠させるにはどうすればよいですか？

    同期プリミティブがRT仮定に反しないようにします。

    以下の例は、RT仮定に反し、予期しないシステム動作を引き起こす可能性があるシナリオです。

/* Acquiring a preemptible lock in non preemptible context */
        
        preempt_disable( )
        ……
        spin_lock( )
        
        /* Acquiring a preemptible lock in non preemptible context /
        
        raw_spin_lock( )
        ……
        spin_lock( )
        
        /* Acquiring a non preemptible lock in preemptible context /
        
        local_lock_irq( )
           …..
        raw_spin_lock( )
        Copy to clipboard
- RTカーネル構成のデバッグ

    以下は、RTカーネルのデバッグ構成です。

    - `CONFIG_DEBUG_ATOMIC_SLEEP` - アトミックセクション内のスリープを検証します。
    - `CONFIG_PROVE_RAW_LOCK_NESTING` - `raw_spinlock` とspinlock の入れ子ができるようになります。`PREEMPT_RT` カーネルのロック入れ子ルールの違反がないことを確認します。

        デバッグ中に、RTカーネルを非RTカーネルに切り替えることができます。切り替えるには、`meta-qcom-realtime/conf/layer.conf` ファイルの変更により `linux-qcom-base-rt` のバーチャル/カーネル設定を変更してからもう一度コンパイルします。

        変更するには、以下のコマンドを実行します。

- PREFERRED_PROVIDER_virtual/kernel = "linux-qcom-base"
            + PREFERRED_PROVIDER_virtual/kernel = "linux-qcom-base-rt"
            Copy to clipboard

RTカーネルでプリミティブをロックする方法の詳細については、[Lock types and their rules—The Linux Kernel documentation](https://www.kernel.org/doc/html/latest/locking/locktypes.html) を参照してください。

## virtioの問題のトラブルシューティング

virtioの問題のトラブルシューティングは、以下の方法で行います。

- カーネルのコンパイルが、必須の構成で行われていることを確認します。
- QEMUコマンドライン・オプション、またはlibvirt XML構成を確認します。
- システムログでエラーを確認します。
- 利用可能なトレースバックエンドを使用して、virtio向けのQEMUコマンドラインでトレースを有効にします。KVMトレースの詳細については、[KVMトレース](https://docs.qualcomm.com/doc/80-70020-3JA/topic/virtualization.html#kvm-traces) を参照してください。

Last Published: Jan 01, 2026

[Previous Topic
カーネルデバッガーを構成する](https://docs.qualcomm.com/bundle/publicresource/80-70020-3JA/topics/configure-kernel-debugger.md) [Next Topic
参考資料](https://docs.qualcomm.com/bundle/publicresource/80-70020-3JA/topics/references.md)