Kernel panic: Fatal exception in interrupt — Причины и исправление сбоя ядра Linux
Архитектура ошибки и симптомы сбоя
Критический сбой «Kernel panic - not syncing: Fatal exception in interrupt» указывает на возникновение фатального исключения внутри контекста прерывания (interrupt context / ISR). В отличие от пользовательского контекста или контекста процесса, ядро внутри обработчика прерывания не может выполнить переключение контекста, уйти в спящий режим или корректно обработать непредвиденное исключение, что приводит к мгновенной панике ядра.
Диагностическая таблица параметров сбоя
| Параметр | Значение | Инженерный смысл сбоя |
|---|---|---|
| Context | Interrupt / Bottom-Half | Сбой произошел при обработке аппаратного или программного прерывания драйвером. |
| Fault Source | Hardware / Kernel Module | Некорректный драйвер устройства (сетевые карты, контроллеры RAID/HBA) или аппаратный сбой PCIe/RAM. |
| RIP / PC | Instruction 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):
- Загрузитесь в однопользовательском режиме (single user mode / init 1).
- Внесите модуль в черный список через
/etc/modprobe.d/blacklist.conf:blacklist faulty_module_name - Обновите DKMS-пакеты драйверов от официального вендора оборудования.
Сценарий 3: Аппаратная проверка оперативной памяти и шины PCIe
Ошибки в контексте прерываний часто связаны с нестабильностью шины питания или дефектами RAM:
- Выполните стресс-тест памяти с помощью утилиты
memtest86+(минимум 2 полных прохода). - Проверьте логи IPMI/BMC на предмет ошибок PCIe Correctable/Uncorrectable Errors.
Падения в ISR требуют глубокого анализа дампов памяти (kdump/crash). Обратитесь к системным инженерам ITSTM для локализации аппаратных дефектов и оптимизации конфигураций ядер под highload.
Частые вопросы (FAQ)
Почему ядро не может просто перезапустить процесс при ошибке в interrupt context?
Обработчики аппаратных прерываний выполняются вне контекста какого-либо процесса. У них нет выделенного стека пользовательского пространства и структуры task_struct, поэтому ядро не может безопасно 'убить' один процесс и вынуждено остановить всю систему во избежание повреждения данных.
Как настроить сохранение дампов памяти kdump при таких сбоях?
Установите пакет kexec-tools, выделите память для ядра захвата в параметрах GRUB (например, crashkernel=512M) и включите службу kdump.