StarTech ST10GSPEXNB (Tehuti TN4010) vendor driver'ı Debian 11'de, kernel 5.10'da derlenmiyor
Bir yedek sunucuya 10G SFP+ portu vermek için bir StarTech ST10GSPEXNB aldım, Linux driver'ıyla satılan bir kartın güncel bir dağıtıma karşı derleneceği varsayımıyla. Bu benim açımdan iyimserlikti.
- StarTech ST10GSPEXNB, Tehuti TN4010 çip
- Debian 11, kernel 5.10.0-13-amd64, eşleşen header'lar kurulu
- kart için sevk edildiği haliyle vendor driver paketi
- kafeste generic bir 10G SFP+ modül, kartın buna aldırış edecek kadar ileri gittiği de yok zaten
make uzunca bir yol kat ediyor ve sonra transmit yolunda çöküyor:
$ 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'Son ikisi DMA mapping çağrılarına düşüyor.
Şimdiye kadar denenenler:
- chmod +x mvidtoh.sh, çünkü build daha önce permission denied ile durmuştu ve PHY header'larını üretmiyordu - bu kısım halloldu
- uname -r'yi kurulu header'lara karşı kontrol ettim, eşleşiyorlar
- vendor'ın sevk ettiğinden daha yeni bir paket aradım ve hiçbir şey bulamadım
Bunlardan birini bu on yıldan bir kernel'de çalıştıran var mı, varsa nasıl?
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
Tam olarak hangi driver paketi - tarball üzerinde damgalanmış bir versiyon var mı, ve readme'si hangi kernel aralığını iddia ediyor? Elimden geçen her Tehuti tabanlı kart, desteklediği kernel'leri readme'de adlandıran bir source tree ile geliyor, ve bu genelde gerçekte çalıştırdığından epey geride oluyor.
Hangi tree'yi derlediğini söylemekte de fayda var. Kartla birlikte gelen vendor sürümü var, bir de topluluk tn40xx tree'leri var - tn40xx-006 ve tn40xx-003, artı linux-6.6 ve linux-6.7 dalları - ve bunlar tarihte birbirine hiç yakın noktalarda değil. İnsanlar farklı kodu tartıştıklarını fark etmeden sürekli bunlar arasında notlarını karşılaştırıyor.
Son bir şey: 3644 log'daki gerçekten ilk hata mı, yoksa daha yukarıda gürültü olarak okuduğun bir şey mi var? Bu üç satır tek bir API değişikliği gibi görünüyor, ama build daha önce bozulduysa geri kalanı bunun sadece yan etkisi.
Topluluk tree'leri benim için yeni bir haber - şimdiye kadar sadece kutuda gelen tarball'ım oldu, ve buradaki her şey sevk edildiği haliyle açılıp ondan derlendi. Bu dallar bir sonraki okuyacağım şey. Ne tarball'da ne de makefile'da hiçbir yerde bir versiyon var, değeri neyse.
Readme tam olarak tarif ettiğin gibi. 3.x kernel'lerden bahsediyor ve 4.14 hattında duruyor. Ben bunu sert bir sınırdan çok neyle test ettiklerine dair bir not olarak okudum, ki şimdi saf görünüyor.
Ve evet, 3644 ilk hata. Üzerinde sadece uyarılar var - kullanılmayan değişkenler, örtük bildirimler, o tree'nin anlaşılan doğal olarak ürettiği türden şeyler - ve build transmit yolunda tam olarak durmadan önce bunların hepsinden gayet mutlu bir şekilde geçiyor. Her çalıştırmada aynı üç satır, 3644, 3648 ve 3651, aynı sırayla.
Readme ne demek istemiş olursa olsun, bu sert bir sınır, ve yapıştırdığın hatalar nedenini açıkça ortaya koyuyor.
Kernel, skb fragment'larının nasıl temsil edildiğini değiştirdi. 5.4'ten itibaren skb_frag_t bir bio_vec, ve struct skb_frag_struct artık orada basitçe yok. Bir struct skb_frag_struct *'a atama yapan kaynak kod tam olarak senin 3644 satırındaki şikayeti kazanıyor, ve ardından bunu bir sayfa ile bir offset'i DMA mapping çağrılarına vermek için dereference eden her şey 3648 ve 3651'de tanımsız bir tipin geçersiz kullanımını kazanıyor. Hiçbir header, hiçbir flag ve hiçbir eski derleyici artık var olmayan bir tipin etrafından dolaşmanı sağlamıyor.
Yani 5.10'da o tree'nin konfigüre edilmeye değil düzenlenmeye ihtiyacı var. Transmit yolundaki fragment işleme güncel accessor'lara göre yeniden yazılmalı, ve bu tek satırlık bir düzeltmeden çok gerçek bir patch, çünkü bu erişimlerin etrafındaki DMA mapping de aynı anda şekil değiştiriyor.
Bu kartlardan birine sahip değilim, o yüzden bunu bir söz değil bir teşhis olarak al. Sana build'in neden başarısız olduğunu ve bunun bir kaynak kod sorunu olduğunu söyleyebilirim; driver'ın sonrasında bir link kaldıracağını söyleyemem.
O patch'e bir hafta sonu batırmadan önce, onun diğer tarafında seni neyin beklediğine bir bak.
Burada bir StarTech PEX10000SFP'm var, TN9510 varyantı, subsystem 1fc9:3015 ile PCI 1fc9:4025. Tree dışı tn40xx driver onun için derleniyor ve yükleniyor, ve dmesg oldukça cesaret verici:
Ve sonra arayüz modülde kırmızı bir ışıkla sonsuza dek NO-CARRIER'da oturuyor. Aynı kart, aynı kafes, StarTech Windows driver'ı altında aynı optik: anında link kuruyor. Yani donanım sağlam ve PHY firmware'i yükleniyor, işi hiç bitirmeyen şey o driver portunun link aşaması.
Ubuntu 22.04 ve Rocky Linux 8.10'u, kernel 4.18, 5.15, 6.5 ve 6.9'u, ve tn40xx-006, tn40xx-003, linux-6.6 ve linux-6.7 dallarını denedim. Hiçbiri bana bir carrier vermedi. Açıkçası şeyi derletmek işin kolay yarısı.
Bu, bir hafta sonu yerine para harcamanın argümanı, ve bunu normalde hafta sonu seçeneğinden keyif alan biri olarak söylüyorum. İkinci el bir Intel ya da Mellanox 10G kart, bir öğleden sonranın maliyetinden daha ucuza geliyor ve driver'ı zaten boot ettiğin kernel'in içinde.
Intel'e gidip içine üçüncü taraf bir optik koyarsan bilinmesi gereken bir şey. Bir X520 modülü "unsupported SFP+ module type was detected" ile doğrudan reddediyor ve sonunda hiç arayüzün kalmıyor. Düzeltme bir modül opsiyonu:
Çift portlu kartlar orada 1,1 istiyor. Sonra sadece modülü kaldırıp yeniden yüklemek yerine update-initramfs -u ve bir soğuk boot, çünkü o disabled durumu firmware'de kilitleniyor ve sıcak bir reload çoğu zaman bunu temizlemiyor. Bu sadece 82599 ve X520 için geçerli, kontrolün driver'da yaşadığı yer. X710'da kontrol firmware'de ve bu opsiyon seni kurtarmaz.
Aynı nefeste doğru tavsiye, yanlış sorun. allow_unsupported_sfp, driver'ın optik whitelist'iyle ilgili, bu thread'deki kart ise hiç derlenmiyor - burada kimse bir optiğin reddedilmesi noktasına yakın bile değil. Sonradan bilinmesi faydalı, ama şimdilik bir cevap değil.
Yine de ikinci el masadaysa, sadece çalışan bir diğeri HP NC523SFP, OEM QLogic QLE3242'nin ta kendisi, HP parça numarası 593715-001. Kernel içi qlcnic driver'ı üzerinde çalışıyor, yani derlenecek hiçbir şey yok - burada adaptör firmware 4.8.20'ye karşı qlcnic 5.3.66 raporlayan bir kutum var, ve içeri girdiğinden beri hiçbir ilgiye ihtiyaç duymadı.
İki uyarı. Sıcak çalışıyor, boşta 16 ila 17 W civarında, sessiz bir odada fark ediyorsun. Ve üzerindeki SR-IOV, sorduğum kimsenin ne yönde olduğunu doğrulayamadığı bir karmaşa. SR-IOV'a ihtiyacın varsa NC552SFP daha iyi bir alım, bnx2x kullanıyor ve bunu düzgünce destekliyor, ama önünde ARI forwarding'i etkinleştirmen gerekiyor yoksa görünmüyor.