☰

如何从中断号推断中断的性质？

tag-icon • tag-icon linux-kernel interrupt
如何从中断号推断中断的性质？

我正在尝试使用旧电脑（惠普 Pavilion Elite m9660de）。以下消息是启动时显示的第一条消息（Ubuntu 和 Fedora，均来自可启动 USB 记忆棒和全新安装）：

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.c，因此它是关于 x86 特定的中断处理。

/*
 * 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设置fixup_irqs()在末尾arch/x86/kernel/irq.c，似乎与 CPU 热插拔有关，或者更具体地说，将 CPU 标记为离线。

因此，这两种状态在启动时都不适用于普通 PC。

您关于中断向量号和中断原因之间的固定对应关系的想法对于原始 IBM PC 的 ISA 总线架构来说是有效的......并且在那之后的相当长一段时间内。

但在 486 处理器和第一代奔腾时代的某个时候，引入了 APIC（高级可编程中断控制器）。它是使多个处理器能够在 PC 架构中共存的组件之一。它开辟了将可用硬件中断线数量从 15 个（一对 8259 中断控制器，如第一台 IBM PC-AT 中的中断控制器）增加到最终增加到 224 个离散硬件中断的途径。这使得能够设计更复杂的系统，并有助于实现真正的自动配置总线。

本质上，系统固件或操作系统都应该将总线上的设备配置为使用特定的中断线路，然后对 APIC 进行编程，将中断信号路由到 CPU 中的可用中断向量。这需要了解总线在主板上的实际接线方式，因此实际上这几乎完全由系统固件完成，并且许多例外都是专门为了修补固件错误。

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,noaer它也可能是 VIA 芯片组中的硬件错误：如果您的系统有此芯片组，在 GRUB 中添加引导选项可能会修复它。

如果您当前的内核debugfs支持并启用了 CONFIG_GENERIC_IRQ_DEBUGFS 内核选项，您可能会以 root 身份使用以下命令获得有关 IRQ 矢量 55 状态的大量信息：

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

这应该告诉您该目录中的哪些文件提到“Vector：55”。阅读这些文件应该可以告诉您内核所知道的有关该中断向量的所有信息。

相关内容