Сообщение вида IOMMU: initialized error report или строки об инициализации отчёта об ошибках IOMMU в выводе dmesg чаще всего не являются критической неисправностью — это информационная запись о том, что подсистема виртуализации ввода-вывода запустила механизм регистрации ошибок. Однако если рядом с ней появляются строки AMD-Vi: Event logged, DMAR: fault reason или система зависает при загрузке, речь уже идёт о реальных сбоях трансляции адресов устройств.

В этой статье разберём, что означает инициализация отчёта об ошибке IOMMU, чем отличаются безобидные логи от симптомов проблемы, и какие шаги диагностики безопасны для любой материнской платы и дистрибутива Linux.

Что такое IOMMU и зачем нужен отчёт об ошибках

IOMMU (Input-Output Memory Management Unit) — аппаратный блок, который управляет доступом устройств к оперативной памяти через DMA. У Intel эта технология называется VT-d, у AMD — AMD-Vi. Без неё любое устройство с прямым доступом к памяти теоретически могло бы читать и писать любые области ОЗУ, что создаёт риски безопасности и мешает пробросу устройств в виртуальные машины.

Отчёт об ошибках — это встроенный механизм журналирования: когда устройство пытается обратиться к недопустимому адресу памяти, IOMMU фиксирует событие и передаёт его драйверу ядра. Строка об инициализации этого отчёта означает лишь то, что ядро успешно подключило обработчик таких событий при загрузке. Это нормальный этап старта системы, а не признак поломки.

Проблемой ситуация становится тогда, когда после инициализации начинают сыпаться сами события: записи о фолтах, прерываниях и сбоях трансляции. Именно их содержимое и нужно анализировать.

Как отличить нормальный лог от симптома сбоя

Откройте терминал и посмотрите полный вывод ядра:

dmesg | grep -i -E "iommu|dmar|amd-vi"

Интерпретируйте результат по следующему принципу:

  • ✅ Строки «IOMMU enabled», «initialized error report», «Default domain type: Translated» без последующих ошибок — штатная работа, вмешательство не требуется.
  • ⚠️ Повторяющиеся записи «AMD-Vi: Event logged [IO_PAGE_FAULT...]» или «DMAR: [DMA Read] Request device ... fault status» — устройство конфликтует с IOMMU.
  • 🔴 Зависания при загрузке, отваливание USB, сетевой карты или дисков вместе с такими логами — сбой влияет на работу системы.
  • ℹ️ Единичные ошибки сразу после старта, не повторяющиеся в процессе работы, часто связаны с особенностями инициализации конкретной прошивки и обычно безвредны.
💡

Сама по себе строка об инициализации отчёта об ошибках IOMMU — информационное сообщение ядра. Тревогу должны вызывать записи о фолтах (page fault, DMAR fault), которые появляются после неё.

Типичные причины ошибок IOMMU

Если в логах всё же присутствуют фолты, вам нужно проверить несколько вероятных источников. Назвать одну универсальную причину нельзя — она зависит от платформы, прошивки и подключённого оборудования.

  • 🔧 Устаревший BIOS/UEFI. Ошибки в таблицах IVRS (AMD) или DMAR (Intel) — один из самых частых источников сбоев, производители исправляют их в обновлениях прошивки.
  • 💾 Проблемное устройство. Некоторые USB-контроллеры, сетевые адаптеры и накопители некорректно работают при активной трансляции адресов.
  • 🧩 Конфликт драйверов. Сторонние или устаревшие модули ядра могут обращаться к памяти вне выделенных доменов.
  • ⚙️ Ручные параметры ядра. Ранее добавленные опции вроде iommu=pt или intel_iommu=on иногда провоцируют конфликты на конкретном железе.
⚠️ Внимание: не отключайте IOMMU «для профилактики», если планируете проброс видеокарты или других устройств в виртуальные машины — без этой технологии VFIO-проброс работать не будет.

Безопасная диагностика: пошаговый порядок

Начинайте с обратимых проверок, которые не меняют конфигурацию системы. Сначала зафиксируйте, какое именно устройство фигурирует в ошибках: в записях о фолтах указывается адрес вида 0000:03:00.0. Сопоставить его с устройством поможет команда:

lspci -nnk | grep -A 3 "03:00.0"

Далее действуйте по чек-листу:

☑️ Диагностика ошибок IOMMU

Выполнено: 0 / 5

Если фолты указывают на конкретное устройство и система при этом работает нестабильно, временно отключите это устройство физически (если оно съёмное) или через BIOS и проверьте, исчезли ли ошибки. Это подтвердит локальный характер проблемы.

📊 Где вы встретили ошибки IOMMU?
При обычной загрузке Linux
При пробросе устройств в виртуальную машину
После обновления BIOS или ядра
Система зависает при старте

Настройка BIOS и параметров ядра

В BIOS/UEFI проверьте состояние опций виртуализации. Названия различаются у производителей: у AMD ищите IOMMU или AMD IOMMU в разделе Advanced, у Intel — VT-d или Intel Virtualization Technology for Directed I/O. Точный путь зависит от модели платы, поэтому сверяйтесь с её документацией.

Если ошибки мешают загрузке, ядру можно передать диагностические параметры через загрузчик. Отредактируйте /etc/default/grub, добавив в строку GRUB_CMDLINE_LINUX_DEFAULT нужную опцию, затем выполните:

sudo update-grub

Полезные параметры для диагностики (не применяйте их все сразу — меняйте по одному и проверяйте результат):

Параметр ядраДействиеКогда применять
iommu=softПрограммная эмуляция IOMMUВременная проверка, виновата ли аппаратная часть
amd_iommu=offОтключение AMD-ViДиагностика на платформах AMD при зависаниях
intel_iommu=offОтключение VT-dДиагностика на платформах Intel
iommu=ptСквозной режим трансляцииСнижение накладных расходов при стабильной работе
⚠️ Внимание: параметры amd_iommu=off и intel_iommu=off полностью отключают аппаратную виртуализацию ввода-вывода. Используйте их только как временный диагностический шаг, а не как постоянное решение — иначе потеряете изоляцию DMA и возможность проброса устройств.

Обновление прошивки и ядра

Заметная часть ошибок IOMMU уходит после обновления BIOS/UEFI, поскольку производители правят таблицы ACPI, описывающие топологию шины. Порядок обновления строго зависит от производителя материнской платы или ноутбука — используйте только официальную утилиту и файл прошивки именно для вашей ревизии платы.

Параллельно убедитесь, что ядро Linux актуально: в новых версиях регулярно исправляют обработку ошибок AMD-Vi и VT-d для конкретных чипсетов. Обновление штатными средствами дистрибутива — безопасная операция, которую стоит выполнить до любых экспериментов с параметрами загрузки.

💡

Перед обновлением BIOS сфотографируйте или выпишите текущие настройки (XMP-профиль памяти, порядок загрузки, состояние виртуализации) — после прошивки они часто сбрасываются на заводские значения.

IOMMU и виртуализация: отдельный случай

Если ошибки появляются при настройке проброса устройств через VFIO, ситуация меняется: здесь IOMMU должен быть не просто включён, а корректно разбивать устройства на изолированные группы. Проверить группы можно командой:

for d in /sys/kernel/iommu_groups//devices/; do echo "${d#/iommu_groups/}"; done

Если нужное устройство оказалось в одной группе с критичными компонентами (мостами, контроллерами), проброс может быть небезопасен или невозможен без дополнительных мер. Это ограничение топологии конкретной платы, а не ошибка настройки.

Почему устройства объединяются в одну группу IOMMU

Группировка зависит от того, как устройства подключены к шине PCIe. Если несколько устройств сидят за одним коммутатором или мостом без поддержки изоляции ACL, IOMMU не может разделить их потоки DMA и объединяет в общую группу. Это аппаратное свойство платы, программно его не изменить — помогает только перестановка карты в другой слот или применение патчей вроде ACS override, которые снижают безопасность изоляции.

Когда обращаться за помощью

Самостоятельная диагностика исчерпана, если после обновления прошивки и ядра фолты продолжаются, а система теряет устройства или зависает. В этом случае соберите полный лог dmesg, версию ядра (uname -r), модель материнской платы и версию BIOS — эти данные понадобятся при обращении в поддержку производителя или в баг-трекер дистрибутива.

Для серверного оборудования и рабочих станций с критичными задачами разумнее привлечь специалиста: некорректные эксперименты с доменами IOMMU на боевой системе могут привести к повреждению данных на дисках.

💡

Порядок действий при ошибках IOMMU: сначала анализ логов и определение устройства, затем обновление BIOS и ядра, и только потом — диагностические параметры загрузки. Полное отключение IOMMU — крайняя временная мера.

Частые вопросы

Опасна ли строка об инициализации отчёта об ошибке IOMMU?

Нет. Это информационное сообщение о том, что ядро подключило обработчик событий IOMMU. Опасны только сами записи о фолтах, которые могут появляться после неё.

Можно ли просто отключить IOMMU и забыть о проблеме?

Можно как временную диагностическую меру через параметры ядра. Но постоянное отключение лишает систему изоляции DMA и делает невозможным проброс устройств в виртуальные машины, поэтому лучше найти и устранить причину фолтов.

Ошибки IOMMU появились после обновления BIOS — что делать?

Проверьте настройки виртуализации: после прошивки они часто сбрасываются. Если ошибки сохраняются при корректных настройках, сообщите о проблеме производителю платы — возможно, в новой версии прошивки регрессия в таблицах IVRS/DMAR.

Влияет ли IOMMU на производительность?

Трансляция адресов добавляет небольшие накладные расходы. Параметр iommu=pt переводит подсистему в сквозной режим для доверенных драйверов, что снижает нагрузку, но применять его стоит только на стабильно работающей системе.

Как понять, какое устройство вызывает фолты?

В записи об ошибке указан адрес шины вида 0000:03:00.0. Найдите его в выводе lspci -nnk — так вы увидите название устройства и используемый драйвер.