Драйвер вендора StarTech ST10GSPEXNB (Tehuti TN4010) не собирается на Debian 11, ядро 5.10
Купил StarTech ST10GSPEXNB, чтобы дать резервному серверу порт 10G SFP+, предполагая, что карта, продаваемая с драйвером под Linux, соберётся против современного дистрибутива. Это было наивно с моей стороны.
- StarTech ST10GSPEXNB, чип Tehuti TN4010
- Debian 11, ядро 5.10.0-13-amd64, установлены соответствующие заголовки
- пакет драйвера вендора, как поставляется для карты
- обобщённый модуль SFP+ 10G в клетке, хотя карта пока даже не дошла до того, чтобы им заниматься
make проходит долгий путь, а затем падает на пути передачи:
$ make
...
tn40.c:3644: error: assignment to 'struct skb_frag_struct *' from incompatible pointer type
tn40.c:3648: error: invalid use of undefined type 'struct skb_frag_struct'
tn40.c:3651: error: invalid use of undefined type 'struct skb_frag_struct'Последние два попадают в вызовы отображения DMA.
Что пробовал:
- chmod +x mvidtoh.sh, потому что сборка раньше останавливалась с permission denied и не генерировала заголовки PHY - эта часть решена
- сверил uname -r с установленными заголовками, они совпадают
- искал пакет новее, чем поставляет вендор, и вообще ничего не нашёл
Кто-нибудь запускал такую карту на ядре из этого десятилетия, и если да, то как?
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
Какой именно пакет драйвера - есть ли версия, проставленная на тарболе, и какой диапазон ядер заявляет его readme? Каждая карта на Tehuti, что прошла через мои руки, поставляет исходное дерево, называющее поддерживаемые ядра в readme, и обычно это далеко отстаёт от того, что вы реально запускаете.
Стоит также сказать, какое дерево вы собираете. Есть дистрибутив от вендора, который идёт с картой, и есть деревья сообщества tn40xx - tn40xx-006 и tn40xx-003, плюс ветки linux-6.6 и linux-6.7 - и они находятся совсем не в одной точке истории. Люди постоянно сверяют заметки между ними, не замечая, что обсуждают разный код.
Последнее: 3644 - это действительно первая ошибка в логе, или выше есть что-то, что вы прочитали как шум? Эти три строки выглядят как одно изменение API, но если сборка сломалась раньше, то остальное - просто следствие.
Деревья сообщества для меня новость - у меня был только тарбол из коробки, и всё здесь собрано из него, распакованного как поставлялся. Эти ветки - следующее, что я почитаю. Версии нигде нет - ни на тарболе, ни в makefile, если это имеет значение.
Readme в точности как вы описываете. Там говорится про ядра 3.x и останавливается на линии 4.14. Я прочитал это как заметку о том, на чём тестировали, а не как жёсткое ограничение, и теперь это выглядит наивно.
И да, 3644 - первая ошибка. Выше неё нет ничего, кроме предупреждений - неиспользуемые переменные, неявные объявления, то, что это дерево, очевидно, выдаёт как норму, - и сборка спокойно проходит через всё это, прежде чем остановиться намертво на пути передачи. Те же три строки, 3644, 3648 и 3651, в том же порядке, при каждом запуске.
Это жёсткое ограничение, что бы ни имелось в виду в readme, и вставленные вами ошибки объясняют почему.
Ядро изменило представление фрагментов skb. Начиная с 5.4 skb_frag_t - это bio_vec, а struct skb_frag_struct просто больше не существует. Код, который присваивает в struct skb_frag_struct *, получает ровно вашу жалобу на строку 3644, а всё, что затем разыменовывает это, чтобы передать страницу и смещение в вызовы отображения DMA, получает invalid use of an undefined type на 3648 и 3651. Никакой заголовок, никакой флаг и никакой более старый компилятор не обойдут тип, которого больше не существует.
Так что на 5.10 это дерево нужно редактировать, а не настраивать. Обработку фрагментов на пути передачи нужно переписать под текущие акцессоры, и это настоящий патч, а не правка в одну строку, потому что отображение DMA вокруг этих обращений одновременно меняет форму.
У меня нет такой карты, так что примите это как диагноз, а не обещание. Я могу сказать, почему сборка падает, и что это проблема исходников; не могу сказать, что драйвер после этого поднимет линк.
Прежде чем потратить выходные на этот патч, посмотрите, что ждёт по ту его сторону.
У меня здесь есть StarTech PEX10000SFP, вариант TN9510, PCI 1fc9:4025 с подсистемой 1fc9:3015. Внешний драйвер tn40xx для неё собирается и загружается, и dmesg вполне обнадёживает:
А затем интерфейс навсегда застревает в NO-CARRIER с красным огоньком на модуле. Та же карта, та же клетка, та же оптика под драйвером StarTech для Windows: линкуется мгновенно. То есть железо исправно и прошивка PHY загружается, просто стадия установления линка в этом драйвере никогда не доводит дело до конца.
Прошёл через Ubuntu 22.04 и Rocky Linux 8.10, ядра 4.18, 5.15, 6.5 и 6.9, и ветки tn40xx-006, tn40xx-003, linux-6.6 и linux-6.7. Ни одна не дала мне carrier. Заставить это скомпилироваться, честно говоря, - самая простая половина задачи.
Это аргумент в пользу потратить деньги, а не выходные, и говорю это как человек, которому обычно нравится вариант с выходными. Б/у карта Intel или Mellanox 10G стоит меньше, чем полдня вашего времени, а её драйвер уже в ядре, которое вы загружаете.
Одна вещь на заметку, если пойдёте по пути Intel и вставите туда стороннюю оптику. X520 напрямую отклоняет модуль с "unsupported SFP+ module type was detected", и в итоге у вас вообще нет интерфейса. Решение - опция модуля:
Двухпортовым картам там нужно 1,1. Затем update-initramfs -u и холодная перезагрузка, а не просто выгрузка и загрузка модуля, потому что это отключённое состояние фиксируется в прошивке, и тёплая перезагрузка часто его не снимает. Это касается только 82599 и X520, где проверка живёт в драйвере. На X710 проверка в прошивке, и эта опция вас не спасёт.
Правильный совет, но не по той проблеме, в том же дыхании. allow_unsupported_sfp - это про белый список оптики драйвера, а карта в этой теме вообще не компилируется - здесь никто ещё близко не подошёл к моменту, когда оптику отклоняют. Полезно знать на будущее, но не ответ сейчас.
Если б/у вариант на столе, то другая карта, которая просто работает, - это HP NC523SFP, это OEM QLogic QLE3242, партномер HP 593715-001. Она работает на встроенном в ядро драйвере qlcnic, так что собирать вообще ничего не нужно - у меня здесь устройство сообщает qlcnic 5.3.66 против прошивки адаптера 4.8.20, и оно не требовало внимания с момента установки.
Два предостережения. Она греется, где-то 16-17 Вт на холостом ходу, что заметно в тихом помещении. И с SR-IOV на ней путаница, которую никто из тех, кого я спрашивал, не смог подтвердить ни в ту, ни в другую сторону. Если вам нужен SR-IOV, лучше взять NC552SFP, она использует bnx2x и поддерживает его как следует, но нужно включить ARI forwarding выше по потоку, иначе она не появится.