主页 / unix / 问题 / 535199
Accepted
Stefan
Asked: 2019-08-13 07:48:31 +0800 CST

如何从中断的数量推断出中断的性质？

  • 772

我正在尝试使用较旧的 PC ( HP Pavilion Elite m9660de ) 启动/安装 Linux 以进行学习。以下消息是启动时显示的第一件事（Ubuntu 和 Fedora，都来自可启动的 U 盘和全新安装）：

do_IRQ: 1.55 没有向量的 irq 处理程序

do_IRQ: 2.55 没有向量的 irq 处理程序

do_IRQ: 3.55 没有向量的 irq 处理程序

引导过程将在那里停顿很长时间（如 15 分钟），然后最终继续。

我不是要求获得对这个具体问题的支持，而是要了解如何解释这样的信息。

我在 do_IRQ 的内核代码中发现 55 是一个向量。据我了解，这或多或少是中断的编号，对应于包含中断处理程序地址的内存位置。

我原以为这些数字与导致中断的事件之间存在固定的对应关系。我在哪里可以找到这方面的文档？这是特定于 Linux、特定于处理器还是特定于主板？

linux-kernel interrupt

1 个回答

  1. Best Answer

    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 是您发现的中断向量。VECTOR_SHUTDOWN如果 IRQ 向量处于状态或，则可以避免该消息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 处理器和第一代 Pentium 时代的某个地方，引入了 APIC（高级可编程中断控制器）。它是使多个处理器在 PC 架构中共存的组件之一。它开辟了将可用硬件中断线的数量从 15 条（第一个 IBM PC-AT 中的一对 8259 中断控制器）增加到 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 论坛中的这个帖子，它也可能是 VIA 芯片组中的硬件错误：如果您的系统有这个芯片组，在 GRUB 中添加引导选项pci=nomsi,noaer可能会修复它。

    如果您当前的内核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”。阅读这些文件应该基本上告诉您内核所知道的有关该中断向量的所有信息。

    • 7

相关问题