Застряли на старом графическом интерфейсе?

do_IRQ: 1.55 No irq handler for vector

Это сообщение можно найти в исходном файле ядра 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;
}

Итак, первая цифра (перед точкой )— это идентификатор процессора, создающего отчет, а 55 — это вектор прерывания, как вы обнаружили. Сообщение можно было бы избежать, если бы вектор IRQ находился в состоянии VECTOR_SHUTDOWNили VECTOR_RETRIGGERED.

Согласно arch/x86/kernel/apic/vector.cсостояние VECTOR_SHUTDOWNуказывает на вектор прерывания, который был намеренно очищен (, например. аппаратное устройство было остановлено, а его драйвер выгружен контролируемым образом ).

Параметр VECTOR_RETRIGGEREDустанавливается в fixup_irqs()в конце arch/x86/kernel/irq.cи, по-видимому, связан с горячим подключением ЦП или, точнее, с пометкой ЦП как отключенного.

Таким образом, ни одно из этих состояний не должно применяться на обычном ПК во время загрузки.

Ваша идея о фиксированном соответствии между номерами векторов прерываний и причинами прерываний была бы применима к архитектуре шины ISA оригинального IBM PC... и спустя некоторое время после этого.

Но где-то в эпоху процессоров 486 и первых Пентиумов,был представлен APIC (Advanced Programmable Interrupt Controller ). Это был один из компонентов, позволяющих нескольким процессорам сосуществовать в архитектуре ПК. Это открыло путь к увеличению количества доступных линий аппаратных прерываний с 15 (пары 8259 контроллеров прерываний, как в первом IBM PC -AT ), в конечном итоге до 224 дискретных аппаратных прерываний. Это позволило проектировать более сложные системы, а также помогло сделать возможными действительно автоматически -конфигурируемые шины.

По сути, либо микропрограмма системы, либо операционная система должны настроить устройство на шине для использования определенной линии прерывания, а затем запрограммировать APIC для направления сигнала прерывания на доступный вектор прерывания в ЦП. Это требует знаний о том, как шина на самом деле подключена к материнской плате, поэтому на практике это почти всегда делается системной прошивкой, и многие исключения предназначены специально для исправления ошибок прошивки.

Первоначально прерывания шины PCI были сопоставлены с прерываниями в стиле ISA -, но когда APIC стали интегрироваться в ЦП, это ограничение можно было снять, уменьшив задержку 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 :, если в вашей системе есть этот набор микросхем, добавление параметра загрузки pci=nomsi,noaerв GRUB может исправить это.

Если ваше текущее ядро ​​​​имеет поддержку debugfsи включен параметр ядра CONFIG _GENERIC _IRQ _DEBUGFS, вы можете получить много информации о состоянии вектора IRQ 55 с помощью следующих команд от root:

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

Это должно сказать вам, какие файлы в этом каталоге упоминают «Вектор :55». Чтение этих файлов должно сказать вам практически все, что известно ядру об этом векторе прерывания.