Неудача с SAS Passthrough на Proxmox 9 с ядром 8.14, Proxmox Виртуальная Среда
Mindbang
Guest
0
23.08.2025 01:11:00
Привет, ребята! Недавно обновил свой кластер до Proxmox 9. Большинство вещей прошло без проблем, но я застрял на одной проблеме. В одной машине у меня стоит LSI 9207-8i, который я пробрасываю в виртуалку. На Proxmox 8 с ядром 6.8 всё работало прекрасно. После обновления до Proxmox 9 с ядром 6.14.8-2-pve проброс в итоге начинает сбоить. Проблема, видимо, где-то на этапе передачи контроллера в виртуалку (см. приложенный скриншот с ошибками). Я немного копался и заметил, что в драйвере mpt3sas для ядра были изменения (), и есть несколько интересных коммитов, которые могут быть связаны с проблемой: - -
Короче говоря, я на Proxmox 9, но закрепил ядро 6.8.12-13-pve. Всё работает нормально. Но это уже unsupported конфигурация, что мне не нравится. Кто-нибудь сталкивался с такой проблемой или может направить, где лучше копать?
Mindbang
Guest
0
06.09.2025 22:15:00
Я сделал несколько кастомных патчей для драйвера mpt3sas, прежде чем понял, что это не тот подход, потому что хост-машина сама аппарат не использует, а просто пробрасывает его. Проблема где-то в подсистемах vfio, iommu или kvm. Наверное, буду пытаться найти виновника методом бисекции, проверяя более новые версии ядра. Версия 6.11 minor тоже работает.
Mindbang
Guest
0
06.09.2025 22:57:00
Думаю, это регрессия, появившаяся с этим патчем . Вся функция может быть отключена с помощью параметра ядра "transparent_hugepage=never". Если его установить, всё снова работает.
hargibi
Guest
0
13.03.2026 17:02:00
У меня была та же проблема после ядра 6.8. Теперь наконец-то удалось обновиться до ядра 6.17. Спасибо!
drpepper285
Guest
0
23.03.2026 22:46:00
Спасибо, этот совет помог мне после того, как я почти весь уикенд пытался разобраться, как снова настроить passthrough для SAS-адаптера после обновления с версии 8 до 9.
drpepper285
Guest
0
23.03.2026 23:13:00
К сожалению, я слишком рано праздновал победу. "hugepager=never" действительно позволяет запустить виртуальную машину с прямым доступом к SAS, но как только я пытаюсь скопировать данные на диски в виртуальной машине, постоянно получаю ошибки, а скорость передачи данных остаётся на нуле. Пришлось снова откатиться с ядра 6.8.xx на 6.11.xx.
drpepper285
Guest
0
01.04.2026 00:07:00
После дополнительного копания я тоже нашёл решение для своего случая. Подсказка с «hugepage» была очень полезной, но проблема не исчезла полностью. Вот как я объясняю происходящее на своём примере: Патч, о котором говорилось выше, меняет то, как ядро выделяет IOVA (виртуальные адреса ввода-вывода) для DMA-маппингов. Там вводятся прозрачные огромные страницы (Transparent Huge Pages, THP) для IOMMU-маппингов вместо отдельных страниц по 4 КБ, используются огромные страницы по 2 МБ для DMA-трансляций. Это должно улучшить производительность (меньше пропусков в IOTLB), но дело в том, что: проблема с более старыми реализациями Intel IOMMU (например, с Z97, который у меня стоит, возможно, затрагивает и другие старые модели) в том, что железо IOMMU ожидает конкретный формат PTE. Когда ядро создаёт PTE для огромных страниц, старые юниты IOMMU не могут их правильно интерпретировать, и «зарезервированные поля» в PTE становятся не нулём, что и вызывает ошибку «fault reason 0x0c: non-zero reserved fields in PTE».
Почему параметр «transparent_hugepage=never» помог лишь частично в моём случае: он отключает THP для обычной памяти (MMU), но не полностью для DMA-маппингов IOMMU. Для небольших DMA-передач (например, инициализация контроллера SAS, как я предполагаю) хватает страниц 4 КБ, но для больших передач (перенос данных через SAS-контроллер) ядро всё равно переходит на более крупные маппинги, поэтому я мог загрузить TrueNAS с этой опцией, но передача данных не работала.
Решение: Просматривая документацию Red Hat... ... я наткнулся на параметр intel_iommu=sp_off, описание которого гласит: «По умолчанию поддерживаются суперстраницы, если Intel IOMMU это умеет. С этой опцией суперстраницы не поддерживаются». А «суперстраницы» — это IOMMU-огромные страницы, введённые проблемным патчем f9e54c3a2f5b. С «sp_off», насколько я понимаю, для IOMMU-маппингов используются только страницы по 4 КБ, то есть поведение такое же, как в старом ядре 6.8. Проверил — теперь могу использовать ядро 6.17 без ошибок DMAR.
Не проверенный советующий бонус: если не ставить «transparent_hugepage=never», это ещё и сохраняет производительность всей системы (а не только IOMMU), потому что обычная память тоже продолжает использовать огромные страницы с этой опцией.
