Solarflare SFN7122F под TrueNAS: карта определяется, но рабочие многомодовые SFP+ модули остаются тёмными
Собираю дома коробку для хранения и взял недорогой двухпортовый 10GbE Solarflare SFN7122F (SFC9120). Сама карта выглядит здоровой, система её видит, оба порта энумерируются, но ни один из моих рабочих многомодовых модулей SFP+ не поднимает в ней линк.
- Solarflare SFN7122F, два порта, контроллер SFC9120
- TrueNAS SCALE на NAS, изначально планировался CORE
- 10G многомодовые модули SFP+, которые без жалоб линкуются в другой сетевой карте
- короткий многомодовый патч-корд, тот же, что использовался в рабочем тесте
eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP>
eth3: <NO-CARRIER,BROADCAST,MULTICAST,UP>Что пробовал:
- оба порта, оба модуля, все четыре комбинации - линк не поднимается никогда
- перенёс те же самые модули и тот же патч-корд на другую карту - линк поднимается сразу
- поменял патч-корды на случай грязного торца
То есть волокно и модули не проблема. Эта карта отклоняет оптику, не закодированную под неё, или что-то не так со стороной драйвера, и будет ли CORE вести себя иначе, чем SCALE? Если дело в кодировке, какие модули у людей реально работают в SFN7122F?
Comments 3
Сторона драйвера не ваша проблема. Драйвер sfxge во FreeBSD покрывает адаптеры 10GbE семейства Solarflare SFC9000, так что SFC9120 в порядке на CORE, и вы уже видите, что SCALE энумерирует железо. Вы упираетесь в собственную проверку трансивера карты: она принимает модули, закодированные под Solarflare, и тихо игнорирует остальные, что выглядит ровно как у вас - здоровая карта с портами, которые никогда не поднимаются.
Детали, которые у людей реально работают в этих картах: FTLX8571D3BCL-SL и SFM10G-SR. FS также поставит модули, предкодированные под Solarflare, если указать целевую платформу при заказе, что обычно проще, чем искать сток с оригинальной кодировкой.
Прежде чем тратиться, подумайте, сколько этой карте осталось жить. Solarflare перешла к Xilinx, и работа над драйвером остановлена, так что дальше для неё ничего не будет. Для коробки, о которой хочется забыть, я бы поставил на первое место Chelsio на этой платформе, а на второе - Intel. Кстати, было одно долгоиграющее сообщение здесь про два года безотказной службы близкородственной SFN6122F, которая, по отзывам, более терпима к случайным трансиверам, чем сидящий рядом Intel X520 - но это более старая карта, и это не меняет поведение кодировки на вашей.
Заказал пару SFM10G-SR, закодированных под карту, и оба порта поднялись с первой установки, так что теория про кодировку подтверждается. Правда, результат частичный: старые многомодовые модули по-прежнему полностью мертвы в этой сетевой карте и работают только в другой, так что теперь держу два комплекта оптики, помеченных и разложенных отдельно.
Карта остаётся, пока делает своё дело, но подсказку про Chelsio беру на заметку для следующей покупки - не хочется каждый раз покупать специально закодированную оптику при добавлении порта.
Стоит добавить одну проверку в общую процедуру, потому что "неподдерживаемая оптика" означает очень разные вещи в зависимости от коробки. На Instant On 1930 24G собственный ответ вендора был, что неподдерживаемый модуль (SX, LH и подобные) только помечается - мигающим светодиодом порта плюс сообщением в syslog - а порт вообще не отключается, так что линк, который там остаётся down, указывает на физический тракт, а не на блокировку. Тот случай закончился новой прокладкой волокна плюс сторонним одномодовым 10G LR SFP+, и линк поднялся.
Та же ловушка работает и в обратную сторону с HBA: Brocade 825 показывается дважды в lspci, и установка оптики ничего не даёт в dmesg, что люди читают как неисправность. Драйверы логируют состояние линка, а не установку модуля, так что тишина там тоже не диагноз.
В вашем случае вы уже провели тест, который всё решает - тот же модуль и тот же шнур линкуются в другой сетевой карте, так что блокировка по кодировке - верный вывод. Просто не давайте никому убедить вас в этом выводе на коробке, где это всего лишь светодиод и строка в логе.