Центр Диагностики & База Системных Ошибок

Решения для Windows Server, Active Directory, 1С, СУБД, Linux, Cisco, MikroTik и IP-телефонии.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, баз данных и сетевого оборудования. Перед выполнением действий обязательно создайте резервную копию. При отсутствии необходимой квалификации обратитесь к ИТ-специалистам.
Fatal exception in interrupt Linux / DevOps

Kernel panic: Fatal exception in interrupt — Причины и исправление сбоя ядра Linux

Обновлено: 18.08.2026  ·  Официальная база знаний

Архитектура ошибки и симптомы сбоя

Критический сбой «Kernel panic - not syncing: Fatal exception in interrupt» указывает на возникновение фатального исключения внутри контекста прерывания (interrupt context / ISR). В отличие от пользовательского контекста или контекста процесса, ядро внутри обработчика прерывания не может выполнить переключение контекста, уйти в спящий режим или корректно обработать непредвиденное исключение, что приводит к мгновенной панике ядра.

Диагностическая таблица параметров сбоя

ПараметрЗначениеИнженерный смысл сбоя
ContextInterrupt / Bottom-HalfСбой произошел при обработке аппаратного или программного прерывания драйвером.
Fault SourceHardware / Kernel ModuleНекорректный драйвер устройства (сетевые карты, контроллеры RAID/HBA) или аппаратный сбой PCIe/RAM.
RIP / PCInstruction PointerАдрес сбойной инструкции внутри скомпилированного модуля или ядра.

Пошаговое дерево решений и сценарии траблшутинга

Сценарий 1: Локализация сбойного драйвера по стеку вызовов (Call Trace)

Изучите стек вызовов, отображаемый на консоли (IPMI/iLO/KVM) перед остановкой:

# Если система еще загружается или сохраняет kdump, изучите логи:
journalctl -k -b -1 | grep -E "(Call Trace|RIP:|EIP:)"

# Проверка статистики прерываний и разделяемых линий IRQ:
cat /proc/interrupts

Сценарий 2: Отключение/обновление проблемных модулей

Если в Call Trace фигурирует сторонний сетевой или дисковый драйвер (например, igb, r8169, megaraid_sas):

  1. Загрузитесь в однопользовательском режиме (single user mode / init 1).
  2. Внесите модуль в черный список через /etc/modprobe.d/blacklist.conf:
    blacklist faulty_module_name
  3. Обновите DKMS-пакеты драйверов от официального вендора оборудования.

Сценарий 3: Аппаратная проверка оперативной памяти и шины PCIe

Ошибки в контексте прерываний часто связаны с нестабильностью шины питания или дефектами RAM:

  • Выполните стресс-тест памяти с помощью утилиты memtest86+ (минимум 2 полных прохода).
  • Проверьте логи IPMI/BMC на предмет ошибок PCIe Correctable/Uncorrectable Errors.
Критический сбой на физическом сервере?
Падения в ISR требуют глубокого анализа дампов памяти (kdump/crash). Обратитесь к системным инженерам ITSTM для локализации аппаратных дефектов и оптимизации конфигураций ядер под highload.
Практический опыт инженера: Если ошибка возникает под пиковой сетевой нагрузкой, проверьте распределение очередей сетевой карты (RSS) по ядрам CPU с помощью set_smp_affinity.sh, чтобы разгрузить CPU0.

Частые вопросы (FAQ)

Почему ядро не может просто перезапустить процесс при ошибке в interrupt context?

Обработчики аппаратных прерываний выполняются вне контекста какого-либо процесса. У них нет выделенного стека пользовательского пространства и структуры task_struct, поэтому ядро не может безопасно 'убить' один процесс и вынуждено остановить всю систему во избежание повреждения данных.

Как настроить сохранение дампов памяти kdump при таких сбоях?

Установите пакет kexec-tools, выделите память для ядра захвата в параметрах GRUB (например, crashkernel=512M) и включите службу kdump.