☰

割り込み番号から割り込みの性質をどのように推論できますか？

tag-icon • tag-icon linux-kernel interrupt
割り込み番号から割り込みの性質をどのように推論できますか？

古いコンピュータを使用しようとしています（HPパビリオンエリートm9660de）。次のメッセージは、起動時に表示される最初のメッセージです（起動可能なUSBスティックと新規インストールの両方でUbuntuとFedora）。

do_IRQ: 1.55 ベクトル irq ハンドラなし

do_IRQ: 2.55 ベクトル irq ハンドラなし

do_IRQ: 3.55 ベクトル irq ハンドラなし

起動プロセスは長い時間（たとえば15分）中断され、最終的に続行されます。

私はこの特定の質問に対するサポートを求めるのではなく、そのようなメッセージを解釈する方法を理解したいと思います。

私はdo_IRQのカーネルコードで55がベクトルであることを発見しました。私が理解しているように、これは割り込みハンドラのアドレスを含むメモリ位置に対応する割り込みの数に似ています。

私は数字と停電につながったイベントの間に固定された対応関係があると思いました。これに関する文書はどこにありますか？これはLinux固有ですか、プロセッサ固有ですか、それともマザーボード固有ですか？

ベストアンサー1

do_IRQ: 1.55 ベクトル irq ハンドラなし

このメッセージはLinuxカーネルソースファイルにあり、arch/x86/kernel/irq.cx86固有の割り込み処理に関するものです。

/*
 * do_IRQ handles all normal device IRQ's (the special
 * SMP cross-CPU interrupts have their own specific
 * handlers).
 */
__visible unsigned int __irq_entry do_IRQ(struct pt_regs *regs)
{
        struct pt_regs *old_regs = set_irq_regs(regs);
        struct irq_desc * desc;
        /* high bit used in ret_from_ code  */
        unsigned vector = ~regs->orig_ax;

        entering_irq();

        /* entering_irq() tells RCU that we're not quiescent.  Check it. */
        RCU_LOCKDEP_WARN(!rcu_is_watching(), "IRQ failed to wake up RCU");

        desc = __this_cpu_read(vector_irq[vector]);

        if (!handle_irq(desc, regs)) {
                ack_APIC_irq();

                if (desc != VECTOR_RETRIGGERED && desc != VECTOR_SHUTDOWN) {
                        pr_emerg_ratelimited("%s: %d.%d No irq handler for vector\n",
                                             __func__, smp_processor_id(),
                                             vector);
                } else {
                        __this_cpu_write(vector_irq[vector], VECTOR_UNUSED);
                }
        }

        exiting_irq();

        set_irq_regs(old_regs);
        return 1;
}

したがって、最初の数字（ドットの前）はレポートプロセッサのID、55は見つかった割り込みベクトルです。 IRQベクトルが状態にある場合は、VECTOR_SHUTDOWNこのメッセージを回避できますVECTOR_RETRIGGERED。

arch/x86/kernel/apic/vector.cステータス表示に基づいて意図的にクリアされる割り込みベクタVECTOR_SHUTDOWN（ハードウェアデバイスが停止し、ドライバが制御された方法でアンロードされます）。

最後にVECTOR_RETRIGGERED設定されていますが、CPUホットプラグ、より具体的にCPUをオフラインで表示することと関連があるようです。fixup_irqs()arch/x86/kernel/irq.c

したがって、起動時に通常のPCでは両方の状態を使用できません。

割り込みベクタ番号と割り込み要因との間の固定された対応についてのあなたの考えは、もともとIBM PCのISAバスアーキテクチャに有効であり、その後もかなり長い間有効でした。

しかし、486プロセッサと第1世代のPentium時代にAPIC（Advanced Programmable Interrupt Controller）が導入されました。 PC アーキテクチャで複数のプロセッサが共存できるようにするコンポーネントの 1 つです。これにより、使用可能なハードウェア割り込みラインの数を15本（最初のIBM PC-ATのような8259個の割り込みコントローラーのペア）から最終的に224個の個々のハードウェア割り込みに増やすことができます。これにより、より複雑なシステムを設計でき、真の自己構成バスを達成するのに役立ちます。

デフォルトでは、システムファームウェアまたはオペレーティングシステムは特定の割り込みラインを使用するようにバス上のデバイスを設定し、割り込み信号をCPUの利用可能な割り込みベクトルにルーティングするようにAPICをプログラムする必要があります。これには、バスが実際にマザーボードにどのように接続されているかについての知識が必要になるため、実際にはほぼ完全にシステムファームウェアによって実行され、特にファームウェアバグパッチには多くの例外が適用されます。

PCIバスはもともと割り込みをISAスタイル割り込みにマッピングしましたが、APICがCPUに統合されると、この制限がなくなり、IRQの待ち時間が短縮され、より複雑なシステムを構築できます。 PCIバスバージョン2.2では、専用の物理割り込みラインなしで個々のハードウェア割り込みを許可するメッセージ信号割り込み（MSI）が導入されました。 PCI Expressでは、MSIは割り込みを処理する標準的な方法になりました。

したがって、システムハードウェアにIRQベクトル55にルーティングされたアクティブな割り込みソースが含まれているように見えますが、Linuxには現在それを処理するドライバがロードされていません。 PCI構成スペースは標準的な方法で読み取ることができ、Linuxはそれを読み取るため、PCIバス（またはPCIeリンク）内のすべてのデバイスを検出して識別し、対応する割り込み構成を知る必要があります。

IRQのソースがPCIデバイスではない可能性があります。プラットフォーム機器これは、システムチップセットの一部であるか、一部の非PCI互換インタフェースを使用して接続するのと同じです。これらのデバイスはすべてファームウェアACPIテーブルとして説明する必要がありますが、お客様の場合、これはIRQのソースではありません。

私の結論は、これがおそらくファームウェアのバグであるということです。 HPがシステムのBIOSアップデートを提供していることを確認してください。 （現在、HP Pavilion Elite m9660deのサポートダウンロードページがロードされていないようです。）

~によるとUbuntuフォーラムのこのスレッドpci=nomsi,noaerVIAチップセットのハードウェアバグかもしれません。システムにこのチップセットがある場合は、GRUBに起動オプションを追加すると問題が解決する可能性があります。

現在のカーネルがdebugfsCONFIG_GENERIC_IRQ_DEBUGFS カーネルオプションをサポートして有効にしている場合は、root として次のコマンドを使用して IRQ ベクトル 55 の状態に関する広範な情報を取得できます。

mount -t debugfs none /sys/kernel/debug
grep "Vector.*55" /sys/kernel/debug/irq/irqs/*

これにより、そのディレクトリ内のどのファイルに「Vector：55」が記載されているかがわかります。このファイルを読み取ると、カーネルがこの割り込みベクトルについて知っているすべてを知ることができます。

おすすめ記事