Driver vendor StarTech ST10GSPEXNB (Tehuti TN4010) tidak mau build di Debian 11, kernel 5.10
Beli StarTech ST10GSPEXNB buat ngasih backup server port SFP+ 10G, dengan asumsi card yang dijual dengan driver Linux bakal bisa di-build lawan distro terkini. Itu optimis banget dari saya.
- StarTech ST10GSPEXNB, chip Tehuti TN4010
- Debian 11, kernel 5.10.0-13-amd64, header yang cocok sudah terpasang
- package driver vendor sebagaimana dikirim buat card-nya
- modul SFP+ 10G generic di cage-nya, bukan berarti card-nya udah nyampe sejauh itu buat peduli soal itu
make-nya jalan cukup jauh terus jatuh di transmit path-nya:
$ 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'Dua yang terakhir mendarat di DMA mapping call-nya.
Yang udah dicoba:
- chmod +x mvidtoh.sh, karena build-nya berhenti lebih awal dengan permission denied dan tidak mau generate header PHY-nya - bagian itu udah beres
- cek uname -r lawan header yang terpasang, cocok
- cari package yang lebih baru dari yang dikirim vendor-nya dan sama sekali tidak nemu apa-apa
Ada yang jalanin salah satu dari ini di kernel dari dekade ini, dan kalau ada, gimana caranya?
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
Package driver yang mana persisnya - ada versi yang tercap di tarball-nya, dan rentang kernel apa yang diklaim readme-nya? Tiap card berbasis Tehuti yang pernah lewat tangan saya kirim source tree yang nyebutin kernel yang didukungnya di readme, dan biasanya itu ketinggalan jauh dari apa pun yang beneran kamu jalankan.
Layak disebutin juga tree yang mana yang kamu build. Ada vendor drop yang dateng bareng card-nya, dan ada community tn40xx tree - tn40xx-006 dan tn40xx-003, plus branch linux-6.6 dan linux-6.7 - dan mereka sama sekali tidak di titik sejarah yang sama. Orang-orang suka bandingin catatan lintas semua itu tanpa nyadar mereka lagi ngomongin kode yang beda.
Terakhir: 3644 itu bener-bener error pertama di log-nya, atau ada sesuatu lebih ke atas yang kamu baca sebagai noise? Tiga baris itu kelihatan kayak satu perubahan API, tapi kalau build-nya udah rusak lebih awal, sisanya cuma dampak dari itu.
Community tree itu berita baru buat saya - saya cuma pernah punya tarball yang datang di kotaknya, dan semua di sini di-build dari itu, di-unpack apa adanya. Branch-branch itu bacaan saya berikutnya. Tidak ada versi di mana pun di tarball-nya atau di makefile-nya, buat apa pun nilainya.
Readme-nya persis seperti yang kamu bilang. Dia ngomongin kernel 3.x dan berhenti di garis 4.14. Saya baca itu sebagai catatan soal apa yang udah mereka tes, bukan batas keras, yang sekarang kelihatan naif.
Dan iya, 3644 itu error pertamanya. Di atasnya tidak ada apa-apa selain warning - variabel yang tidak dipakai, deklarasi implisit, jenis hal yang kelihatannya memang wajar dihasilkan tree itu - dan build-nya jalan lewat semua itu dengan santai sebelum berhenti mati di transmit path-nya. Tiga baris yang sama, 3644, 3648, dan 3651, dalam urutan yang sama, setiap run.
Itu batas keras, apa pun maksud readme-nya, dan error yang kamu paste itu ngejelasin kenapa.
Kernel-nya ngubah cara fragment skb direpresentasikan. Dari 5.4 ke atas, skb_frag_t itu bio_vec, dan struct skb_frag_struct memang sudah tidak ada lagi. Source yang assign ke struct skb_frag_struct * dapat persis komplain line 3644 kamu, dan apa pun yang kemudian dereference itu buat ngasih page dan offset ke DMA mapping call dapat invalid use of an undefined type di 3648 dan 3651. Tidak ada header, tidak ada flag, dan tidak ada compiler lama yang bisa bikin kamu muter dari tipe yang sudah tidak ada.
Jadi di 5.10, tree itu butuh diedit, bukan dikonfigurasi. Penanganan fragment di transmit path-nya harus ditulis ulang lawan accessor yang sekarang, dan itu patch beneran, bukan fix satu baris, karena DMA mapping di sekitar akses-akses itu berubah bentuk di saat yang sama.
Saya tidak punya salah satu card ini, jadi anggap itu diagnosis, bukan janji. Saya bisa kasih tahu kenapa build-nya gagal dan itu masalah source; saya tidak bisa kasih tahu bahwa driver-nya bakal bikin link naik setelahnya.
Sebelum kamu ngorbanin satu weekend buat patch itu, lihat dulu apa yang nunggu di sisi lainnya.
Saya punya StarTech PEX10000SFP di sini, varian TN9510, PCI 1fc9:4025 dengan subsystem 1fc9:3015. Driver tn40xx out-of-tree-nya build dan load buat itu, dan dmesg-nya cukup meyakinkan:
Terus interface-nya nongkrong di NO-CARRIER dengan lampu merah di modulnya, selamanya. Card yang sama, cage yang sama, optik yang sama di bawah driver Windows StarTech: langsung link. Jadi hardware-nya sehat dan firmware PHY-nya load, yang tidak pernah nyelesain tugasnya itu tahap link di port driver itu.
Saya udah coba Ubuntu 22.04 dan Rocky Linux 8.10, kernel 4.18, 5.15, 6.5, dan 6.9, dan branch tn40xx-006, tn40xx-003, linux-6.6, dan linux-6.7. Tidak satu pun ngasih saya carrier. Bikin benda ini kompilasi itu separuh yang gampang, jujur.
Itu argumen buat ngeluarin uang daripada satu weekend, dan saya bilang ini sebagai orang yang biasanya menikmati opsi weekend-nya. Card 10G Intel atau Mellanox bekas harganya lebih murah dari satu sore waktu kamu dan driver-nya udah ada di kernel yang kamu boot.
Satu hal yang perlu diketahui kalau kamu pilih Intel dan pasang optik pihak ketiga ke situ. X520 langsung menolak modulnya dengan "unsupported SFP+ module type was detected" dan kamu berakhir tanpa interface sama sekali. Fix-nya itu module option:
Card dual port mau 1,1 di situ. Terus update-initramfs -u dan cold boot, bukan cuma unload dan reload modulnya, karena state disabled itu ke-latch di firmware dan warm reload sering tidak bersihin itu. Itu cuma 82599 dan X520, tempat pengecekannya ada di driver. Di X710 pengecekannya ada di firmware dan opsi ini tidak akan menyelamatkan kamu.
Saran yang benar, masalah yang salah, dalam napas yang sama. allow_unsupported_sfp itu soal whitelist optik driver-nya, dan card di thread ini sama sekali tidak mau kompilasi - tidak ada satu pun di sini yang dekat ke titik optiknya ditolak. Berguna buat diketahui nanti, bukan jawaban buat sekarang.
Tapi kalau second hand masuk pertimbangan, yang lain yang bener-bener jalan itu HP NC523SFP, yang OEM-nya QLogic QLE3242, part HP 593715-001. Dia jalan di driver qlcnic yang udah in-kernel, jadi tidak ada apa pun yang perlu di-build sama sekali - saya punya box di sini yang report qlcnic 5.3.66 lawan firmware adapter 4.8.20, dan itu tidak butuh perhatian apa pun sejak dipasang.
Dua catatan. Dia jalan panas, sekitar 16 sampai 17 W waktu idle, yang bakal kamu sadari di ruangan yang sepi. Dan SR-IOV di situ itu simpang siur, tidak ada yang saya tanya bisa mengonfirmasi satu arah atau lainnya. Kalau kamu butuh SR-IOV, NC552SFP itu pilihan yang lebih baik, dia pakai bnx2x dan mendukungnya dengan benar, tapi kamu harus nyalain ARI forwarding di upstream-nya atau dia tidak akan muncul.