Intel X520 в R630 отклоняет медный SFP+ 10GBASE-T с comp_codes_10g=0x00, несмотря на allow_unsupported_sfp=1
Мы переводим пару R630 на 10G, а кабель до верха стойки - медный, поэтому вместо прокладки оптики я поставил в карты X520 медные модули 10GBASE-T SFP+. На стороне коммутатора они принимаются без единого слова. Серверы отказываются их принимать.
- Dell PowerEdge R630, Intel X520 (82599), два порта
- FS SFP-10GM-T-30, закодирован под Dell, по одному модулю на сервер
- ixgbe вне дерева ядра от Intel, собран через DKMS
- /etc/modprobe.d/ixgbe.conf с переопределением, выставленным для обоих портов
# cat /etc/modprobe.d/ixgbe.conf
options ixgbe allow_unsupported_sfp=1,1
# dmesg
ixgbe: failed to load because an unsupported SFP+ module type was detected
# 10G compliance codes read back from the module
comp_codes_10g=0x00Что я уже пробовал:
- вручную выполнить
modprobe ixgbe allow_unsupported_sfp=1, а не только через запись в modprobe.d - пересобрать initramfs и сделать холодную перезагрузку машины, а не просто перезагрузку модуля
- переставить модуль во второй порт, а затем на второй сервер - результат тот же
Интересная деталь - этот байт compliance: модуль вообще ничего не сообщает про 10G. Проверяет ли драйвер это до того, как вообще посмотрит на override, и можно ли что-то сделать, кроме покупки оптики с правильной кодировкой?
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 6
Вы боретесь не с белым списком, а с порядком проверок.
В SFF-8472 нет бита compliance для 10GBASE-T. Для него просто нет кодовой точки, поэтому честный медный SFP+ сообщает нулевые коды compliance для 10G - это как раз ваш
comp_codes_10g=0x00. ixgbe читает этот байт, не находит там ничего, что распознаёт как модуль 10G, и сдаётся прямо там, даже не добравшись до проверкиallow_unsupported_sfp. Поэтому этот флаг прекрасно работает для неквалифицированного оптического модуля или DAC и совершенно ничего не делает для ваших медных модулей.Есть патч от сообщества к внедревному ixgbe от Intel, который сдвигает эту проверку compliance: когда администратор явно выставил
allow_unsupported_sfp=1, модуль с нулевыми кодами compliance для 10G классифицируется как SR вместо того, чтобы быть отброшенным на раннем этапе. Патч был отправлен в апстрим и до сих пор не влит, так что применять его к исходникам DKMS придётся вручную и держать вместе со своей сборкой. Автор патча сообщал потом о полном дуплексе 10 Гбит/с на паре серверов, а кто-то ещё подтвердил, что тот же патч заставляет заработать медные модули HLX-SFPX в X520.Две оговорки перед тем, как это делать. Оптика, не квалифицированная Intel, выходит за рамки их гарантии совместимости, так что это становится вашей проблемой, а не их. И PHY 10GBASE-T - горячая деталь: в серверной корзине без собственного обдува она будет заметно горячее любой оптики в соседнем слоте, так что следите за температурой модуля после того, как линк поднимется.
Прежде чем что-то патчить, стоит уточнить две вещи.
Во-первых, выведите параметр так, как его реально видит ядро -
/sys/module/ixgbe/parameters/allow_unsupported_sfp- на машине, прошедшей холодную перезагрузку, а не просто перезагрузку модуля. Если там не то же самое значение, что в вашем конфиг-файле, значит драйвер загружается раньше, чем применяется ваша конфигурация, и остальная отладка бессмысленна.Во-вторых, какой именно ixgbe загружен?
ethtool -iвам не поможет, пока драйвер так и не заканчивает загрузку и интерфейсы отсутствуют, так что приведите выводmodinfo ixgbeи версию собранного вами пакета DKMS.И откуда взялось это
comp_codes_10g=0x00- это сообщил драйвер, или вы сами считали EEPROM модуля?В файле стоит
1,1, и после холодной перезагрузки/sys/module/ixgbe/parameters/allow_unsupported_sfpвозвращает1,1, то есть параметр применяется, а не игнорируется молча. Initramfs пересобирался до перезагрузки. Строка в dmesg одна и та же в обоих случаях.Коды compliance я считал сам из данных SFF-8472 модуля, а не от драйвера - байт compliance для 10G нулевой, остальные поля идентификации выглядят нормально. Тот же модуль в порту коммутатора линкуется на 10G, так что модуль не мёртвый.
Стоит добавить с практической стороны: при DKMS каждое обновление ядра пересобирает модуль из исходников на диске, так что патч должен жить в этом дереве исходников, а не в каталоге сборки, который потом почистили. Проверьте, что порт возвращается после первого же обновления ядра, а не выясняйте это уже во время окна перезагрузки.
Более общий урок из этого класса проблем - версия драйвера решает больше, чем кодировка модуля. Похожая история на X710 с пассивным DAC: один кабель, один порт, всё в порядке под Ubuntu 24.04 и мертво под TrueNAS SCALE с
Link detected: noиSpeed: Unknown, потому что в той сборке i40e был взят из ядра 6.6.44-production. На 25.04-BETA.1, где i40e взят из 6.12.9-production, twinax поднялся сам собой - больше ничего не трогали, карта осталась на прошивке 9.20. Оптика на этом порту работала нормально в обеих системах, что и указало на то, что дело в том, как старый драйвер обрабатывает пассивную медь.ethtool -iс обеих сторон сравнения сэкономил бы немало времени на перестановке кабелей.Другой тип модуля, тот же драйвер, и ловушка, которую стоит исключить, раз уж вы здесь. Dell R720 с дочерней картой X520, многомодовые модули Cisco 10G LC отклонялись, интерфейсы просто отсутствовали. Опция была прописана и в modprobe.d, и в GRUB, но ничего не менялось - потому что хост загружается через EFI, и эта командная строка GRUB вообще не использовалась.
На Proxmox с загрузкой через EFI параметр нужно прописывать в
/etc/kernel/cmdlineкакixgbe.allow_unsupported_sfp=1, а затем выполнитьpve-efiboot-tool refresh. В том случае даже это не помогло, и в итоге купили модули под маркой Intel, так что относитесь к этому как к варианту, который стоит исключить, а не как к гарантированному решению.Ещё один момент из той истории: обе стороны должны быть довольны оптикой независимо друг от друга. Модуль, который принимает коммутатор, всё равно может быть отклонён хостом - именно там вы сейчас и находитесь.
Применил патч к исходникам DKMS и пересобрал. Оба порта поднялись на 10 Гбит/с в полном дуплексе и держатся под нагрузкой с тех пор.
Работает, но назвать это решённым я бы не сказал. Это невлитый патч, который теперь приходится переносить через каждое обновление ядра, а драйвер показывает порт как SR, что запутает всякого, кто посмотрит на эту машину после меня. Модуль также работает заметно горячее, чем оптика в соседней корзине, а в этом слоте обдува считай что нет. Для следующей партии серверов я просто протяну оптику и перестану спорить с драйвером.