К старенькому HP Proliant DL20 подключили MSA 2050. Накатили новую систему: Debian 13. При попытке создать файловую систему — сервер уходит в ошибку, пищит, свистит, спамит в консоль. iLO в панике.
Помогает отключение Intel VT-d в BIOS.
Суть проблемы
Проблема массово проявилась после выхода дистрибутивов Linux с ядром 6.8, таких как Ubuntu 24.04 LTS (Noble Numbat), Fedora 40 и прочих. Владельцы старых серверов HP ProLiant (поколений G8, G9 и аналогичных систем на платформах Intel C600/C602), а также систем Supermicro и других, столкнулись с одними и теми же проблемами:
- Система зависает при загрузке.
- Постоянная перезагрузка.
- Массивный спам ошибок DMAR: [Firmware Bug]: No firmware reserved region can cover this RMRR [0x00000000bb800000-0x00000000bbffffff] в консоли.
- Полная неработоспособность, если в BIOS включен Intel VT-d (IOMMU).
Быстрое решение — отключение Intel VT-d в BIOS.
Изменения в ядре 6.8
Изменения касаются подсистемы IOMMU (Input-Output Memory Management Unit), которая управляет прямым доступом устройств к памяти (DMA) безопасным способом, изолируя устройства друг от друга.
Конкретная проблема связана с обработкой регионов памяти, зарезервированных firmware (например, BIOS/UEFI), так называемых RMRR (Reserved Memory Region Reporting).
Старая логика (до ядра 6.8)
Если драйвер IOMMU сталкивался с RMRR-областью, которая была помечена как некорректная или не могла быть корректно обработана (из-за ошибки в старой firmware вашего сервера, т.н. Firmware Bug), он мог проигнорировать её или обработать в обход, позволяя системе загрузиться с предупреждениями в логах.
Новая логика (начиная с ядра 6.8)
Были приняты патчи (в частности, серия коммитов от автора Lu Baolu), которые ужесточили требования к валидации и обработке этих RMRR-областей. Цель была благая — улучшить безопасность и стабильность работы IOMMU.
Ядро теперь строже проверяет, может ли оно создать изоляцию для устройства, которому назначена проблемная RMRR-область. Если область признаётся некорректной (как в моём случае: No firmware reserved region can cover this RMRR), и система не может безопасно её обработать, новый код приводит к фатальной ошибке и останавливает дальнейшую инициализацию IOMMU, что вызывает зависание системы.
Почему старые серверы?
Производители серверов (HP, Dell и др.) много лет назад закладывали в свою firmware определенные RMRR-области для своих специфических аппаратных компонентов (например, встроенных RAID-контроллеров, сетевых карт, BMC iLO). В этой firmware были ошибки или несоответствия стандартам, которые раньше ядро прощало, а теперь — нет.
Что делать?
- Отключение VT-d. Решение работает сразу, система загружается. Вы теряете все функции, связанные с IOMMU: изоляцию устройств виртуальных машин (PCIe passthrough), защиту от DMA-атак, некоторые возможности безопасности.
- Добавление параметра ядра
intel_iommu=off. В загрузчике (GRUB) нужно отредактировать строку загрузки, добавив этот параметр. Это делает то же самое, что и отключение в BIOS, но иногда удобнее. - Даунгрейд ядра. Установить ОС на основе более старого ядра (например, Ubuntu 22.04 LTS с ядром 5.15), а затем вручную обновиться только до версии ядра 6.5 из репозиториев Ubuntu (например, linux-generic-hwe-22.04 на момент написания даёт ядро 6.5). Простое обновление ubuntu-22.04 до ubuntu-24.04 приведет к установке ядра 6.8 и снова вызовет проблему. Нужно явно запрещать обновление ядра или оставаться на 22.04.
- Использование параметра
intel_iommu=relaxable(предпочтительный метод для опытных). Этот параметр заставляет ядро вернуться к более "мягкому" поведению при обработке RMRR, похожему на то, что было раньше. Он может помочь обойти проблему, не отключая полностью IOMMU. - Обновление прошивки (Firmware/BIOS) сервера. В новых версиях прошивки производители часто исправляют такие ошибки, перекладывая RMRR-регионы или делая их корректными с точки зрения новых требований ядра.
