Supermicro AOC-STGN-i1S (X520) на Proxmox 7.1: нет интерфейса в ip link при вставленном DAC от HP
У меня дома небольшой сервер на Proxmox, и захотелось нормального 10G пути до узла хранения, так что поставил б/у Supermicro AOC-STGN-i1S. Это обычный дизайн на Intel 82599, плата с маркировкой E157872, и я думал, что это будет самая скучная часть сборки. Не тут-то было.
- Supermicro AOC-STGN-i1S, Intel X520-DA1, маркировка платы E157872
- Proxmox 7.1, ядро 5.15.30-1-pve
- пассивный SFP+ DAC под брендом HP до второй машины
- карта нормально определяется на шине PCI
Драйвер так и не заканчивает загрузку. В логе ядра написано, что загрузка прервана, потому что обнаружен неподдерживаемый тип модуля SFP+/QSFP, и после этого просто нет порта для настройки:
lspci -> the X520 is listed, no complaints
ip link -> lo and the onboard 1G only, no 10G interface at all
dmesg -> ixgbe aborts loading, unsupported SFP+/QSFP module typeЧто уже сделал:
- создал /etc/modprobe.d/ixgbe.conf со строкой
options ixgbe allow_unsupported_sfp=1, затемupdate-initramfs -uи перезагрузка: без изменений - передал ту же опцию как параметр ядра вместо этого: без изменений
rmmod ixgbeиmodprobe ixgbeвручную: вip linkпо-прежнему ничего нового
Карта мертва, или есть способ обойти эту проверку на ядре 5.15, который я упускаю?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
То, что вы описываете, - это ровно то, как выглядит попадание в EEPROM-белый список на ixgbe. Драйвер читает ID модуля, решает, что его нет в принятом списке Intel, и прерывает загрузку ещё до регистрации netdev, поэтому
lspciвидит карту, аip linkне показывает вообще ничего. Ничего из этого не является аппаратной неисправностью, и именно поэтому порт возвращается в ту же секунду, как модуль вынимают из слота.Задокументированный обходной путь - тот самый, что вы уже использовали:
На 5.15 эта опция просто ненадёжна. У меня на этом ядре был точно такой же нулевой результат, так что нет смысла переделывать это заново или искать опечатку в конфиге.
Что у меня решило вопрос: с пустым слотом интерфейс поднимался при
modprobe ixgbe, возврат кабеля HP снова его убирал, а тот же самый кабель HP линковался без проблем в Mellanox ConnectX-2. Кабель электрически исправен, Intel просто не нравится, как он закодирован.Сработало то, что поставил обычный небрендированный generic SFP+ DAC. Линк поднялся сразу, никаких опций модуля, никаких плясок с перезагрузкой. По поддержке: с любым не-Intel закодированным кабелем вы всё равно вне матрицы поддержки Intel, так что если эту коробку когда-нибудь нужно будет обслуживать по поддержке - купите DAC с кодировкой Intel, а не от HP.
Прежде чем списывать карту, проведите один тест. Полностью выньте DAC из слота, затем
rmmod ixgbe,modprobe ixgbeи снова посмотрите наip link. Если интерфейс появляется с пустым слотом, значит и карта, и драйвер в порядке, а проверка спотыкается именно о кабель.Ещё стоит узнать: линкуется ли этот DAC от HP где-нибудь ещё? Не-Intel сетевая карта обычно принимает его без единого слова жалобы. И точно ли это кабель с кодировкой HP, или у вас завалялся generic-кабель для сравнения?
Считайте, что вам повезло с X520, где хотя бы есть ручка драйвера, пусть и капризная. На X710 и XL710 проверка модуля переехала в прошивку, так что
allow_unsupported_sfpвообще ничего не даёт для i40e. Поставьте не-Intel модуль в X710-DA2 и получите:и на этом разговор закончен. Дальше варианты - оптика с кодировкой Intel, путь community-утилиты xl710-unlocker (залить свежий образ NVM родным апдейтером Intel, затем ковыряться в одиннадцатибитных полях где-то в районе 0x6800-0x7000 в EEPROM сторонними инструментами, полностью на свой страх и риск), либо выбрать OEM-вариант с самого начала: HPE 562SFP+ под капотом - это X710, и после обновления прошивки и i40e он принимал сторонние 10G и 1G медные модули вообще без хаков.
С OEM-вариантом всё оборачивается наоборот для карт X710-DA2 под брендами Dell и Lenovo: они отклоняют неодобренные SFP+ и DAC, а собственные утилиты Intel даже не видят эту плату в списке. К чему пришли люди - это прошивка на них стокового NVM от Intel. Сначала нужен драйвер QV из полного пакета BootUtil от Intel, иначе утилиты вообще не будут разговаривать с платой; сначала заменяется option ROM, и только потом вы инвентаризируете карту и прошиваете её:
Между инвентаризацией и прошивкой сократите nvmupdate.cfg до единственной записи X710, соответствующей размеру SPI-флеша карты, 4 МБ или 8 МБ. Выберете не тот размер - получите кирпич, который восстанавливается только сохранённым образом NVM и аппаратным программатором, так что сначала прочитайте ETrackID и будьте уверены. Прошивка в диапазоне 9.30-9.40 после этого сообщалась как рабочая, и люди попутно получали SR-IOV на платах Lenovo. Я бы всё равно пробовал это только на карте, потерю которой могу себе позволить.
Осторожнее с направлением кросс-прошивки и патчинга EEPROM в эту тему, потому что ни то ни другое не помогает в описанной ситуации. Правка OEM-флага в EEPROM X520 требует уже работающего интерфейса, через который вообще можно достучаться до карты, а здесь интерфейса нет вообще, пока кабель не вынут из слота. Это исправление для порта, который существует и отклоняет один конкретный модуль, а не для драйвера, который прерывает загрузку.
Ещё одну вещь я бы не стал переоценивать - тест в другой сетевой карте. Модуль, линкующийся в другом хосте, доказывает исправность модуля, а не того хоста, в который он реально нужен. У меня есть медные модули Ubiquiti UACC-CM-RJ45-MG, которые прекрасно работают в CCR2004 и в Intel X520-DA2 под Debian, а в слотах SFP+ CRS309 и CRS328 они вообще никогда не линкуются, ни с автосогласованием, ни с вручную зафиксированной скоростью. Зависимость от хоста реальна, так что проверяйте на той самой машине, прежде чем закупать стопку чего-либо.