Driver hãng của StarTech ST10GSPEXNB (Tehuti TN4010) không build được trên Debian 11, kernel 5.10
Mua một StarTech ST10GSPEXNB để cho máy chủ backup một cổng SFP+ 10G, với giả định rằng một card bán kèm driver Linux thì sẽ build được trên một distro hiện hành. Đó là suy nghĩ hơi lạc quan.
- StarTech ST10GSPEXNB, chip Tehuti TN4010
- Debian 11, kernel 5.10.0-13-amd64, đã cài header khớp phiên bản
- gói driver hãng đúng bản đi kèm card
- module SFP+ 10G generic trong cage, dù card còn chưa build xong để mà quan tâm tới nó
make chạy được một đoạn khá dài rồi gãy ở transmit path:
$ 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'Hai lỗi cuối rơi vào các lệnh gọi DMA mapping.
Đã thử:
- chmod +x mvidtoh.sh, vì build trước đó dừng lại với permission denied và không sinh ra được PHY header - phần này đã xong
- kiểm tra uname -r đối chiếu với header đã cài, khớp nhau
- tìm một gói mới hơn bản vendor đang phát hành nhưng không thấy gì cả
Có ai đang chạy một con card này trên kernel của thập kỷ này không, và nếu có thì chạy kiểu gì?
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
Chính xác là gói driver nào - trên tarball có đóng dấu version không, và readme của nó khai phạm vi kernel nào? Mọi card dựa trên Tehuti từng qua tay tôi đều đi kèm một source tree ghi rõ các kernel được hỗ trợ trong readme, và thường thì nó tụt lại khá xa so với kernel bạn đang thực sự chạy.
Cũng đáng nói luôn là bạn đang build cây nào. Có bản vendor đi kèm card, và có các cây tn40xx của cộng đồng - tn40xx-006 và tn40xx-003, cộng thêm nhánh linux-6.6 và linux-6.7 - và chúng chẳng ở gần cùng một mốc lịch sử nào cả. Người ta hay so sánh ghi chú qua lại giữa các cây này mà không để ý là đang bàn về những đoạn code khác nhau.
Điều cuối: 3644 có thực sự là lỗi đầu tiên trong log không, hay có gì phía trên mà bạn đọc thành nhiễu? Ba dòng đó trông như một thay đổi API duy nhất, nhưng nếu build gãy từ trước đó thì phần còn lại chỉ là hệ quả kéo theo.
Cây của cộng đồng thì đây là lần đầu tôi nghe - từ trước tới giờ chỉ có mỗi tarball đi kèm trong hộp, và mọi thứ ở đây build từ đó, giải nén đúng như hãng gửi. Mấy nhánh đó là thứ tiếp theo sẽ đọc. Không có version nào ghi trên tarball hay trong makefile cả, nói vậy để biết.
Readme đúng như bạn mô tả. Nó nói về kernel 3.x và dừng lại ở dòng 4.14. Tôi đọc đó như một ghi chú về những gì họ đã test qua, chứ không phải giới hạn cứng - giờ nghĩ lại thấy hơi ngây thơ.
Và đúng, 3644 là lỗi đầu tiên. Phía trên nó chỉ toàn warning - biến không dùng, khai báo implicit, kiểu thứ mà cây đó rõ ràng sinh ra như chuyện thường ngày - và build đi qua hết chỗ đó khá thoải mái trước khi chết hẳn ở transmit path. Vẫn ba dòng đó, 3644, 3648 và 3651, đúng thứ tự, mỗi lần chạy đều vậy.
Đó là giới hạn cứng, dù readme có ý gì đi nữa, và mấy lỗi bạn dán ra nói rõ vì sao.
Kernel đã đổi cách biểu diễn skb fragment. Từ 5.4 trở đi skb_frag_t là một bio_vec, và struct skb_frag_struct đơn giản là không còn tồn tại nữa. Source nào gán vào một struct skb_frag_struct * sẽ ăn đúng lỗi dòng 3644 của bạn, và bất kỳ chỗ nào dereference nó để đưa page và offset vào các lệnh gọi DMA mapping sẽ ăn lỗi invalid use of an undefined type ở 3648 và 3651. Không header nào, không flag nào, không compiler cũ nào giúp lách được một type đã không còn tồn tại.
Nên trên 5.10 thì cây đó cần sửa chứ không phải cấu hình lại. Phần xử lý fragment trong transmit path phải được viết lại theo accessor hiện tại, và đó là một patch thật sự chứ không phải sửa một dòng, vì DMA mapping quanh các chỗ truy cập đó cũng đổi hình dạng cùng lúc.
Tôi không sở hữu con card này, nên coi đây là chẩn đoán chứ không phải lời hứa. Tôi có thể nói vì sao build fail và đó là vấn đề source; tôi không thể nói driver có đưa được link lên sau đó hay không.
Trước khi đổ cả một cuối tuần vào patch đó, thử nhìn xem cái gì đang chờ ở phía bên kia.
Tôi có một StarTech PEX10000SFP ở đây, bản TN9510, PCI 1fc9:4025 với subsystem 1fc9:3015. Driver tn40xx out-of-tree build và load được cho nó, và dmesg thì rất đáng khích lệ:
Rồi sau đó interface cứ nằm ở NO-CARRIER với đèn đỏ trên module, mãi mãi. Cùng card, cùng cage, cùng optic mà dùng driver Windows của StarTech thì lên link ngay lập tức. Nên phần cứng vẫn ổn và PHY firmware vẫn load được, chính giai đoạn lên link của driver port đó là thứ không bao giờ xong việc.
Tôi đã thử qua Ubuntu 22.04 và Rocky Linux 8.10, kernel 4.18, 5.15, 6.5 và 6.9, cùng các nhánh tn40xx-006, tn40xx-003, linux-6.6 và linux-6.7. Không cái nào cho tôi carrier cả. Nói thật, làm cho nó compile được mới chỉ là nửa dễ.
Đó là lý do nên bỏ tiền ra thay vì bỏ một cuối tuần, và tôi nói vậy dù bản thân thường thích phương án cuối tuần hơn. Một card Intel hay Mellanox 10G cũ giá còn rẻ hơn một buổi chiều thời gian của bạn, và driver của nó đã có sẵn trong kernel bạn đang boot.
Có một điều cần biết nếu chọn Intel và cắm optic bên thứ ba vào. Một con X520 từ chối thẳng module với thông báo "unsupported SFP+ module type was detected" và kết quả là chẳng có interface nào cả. Cách sửa là một module option:
Card hai cổng cần ghi 1,1 ở đó. Sau đó update-initramfs -u và cold boot hẳn, chứ đừng chỉ unload rồi load lại module, vì trạng thái bị khóa đó latch xuống tận firmware và một lần reload nóng thường không xóa được. Đó chỉ đúng với 82599 và X520, nơi kiểm tra nằm trong driver. Trên X710 kiểm tra nằm trong firmware và option này sẽ không cứu được bạn.
Lời khuyên đúng, nhưng sai vấn đề, trong cùng một câu. allow_unsupported_sfp là chuyện whitelist optic của driver, còn card trong thread này thì không compile nổi - chẳng ai ở đây gần tới cái mức bị driver từ chối optic cả. Hữu ích để biết sau này, chứ không phải câu trả lời cho lúc này.
Nhưng nếu hàng cũ cũng được tính, thì thứ khác đơn giản là chạy tốt là một HP NC523SFP, chính là bản OEM của QLogic QLE3242, HP part 593715-001. Nó chạy trên driver qlcnic có sẵn trong kernel, nên chẳng cần build gì cả - tôi có một hộp ở đây báo qlcnic 5.3.66 đối với adapter firmware 4.8.20, và từ lúc lắp vào tới giờ không cần đụng tới gì thêm.
Hai điều cần lưu ý. Nó khá nóng, khoảng 16 đến 17 W lúc idle, đủ để nhận ra trong một phòng yên tĩnh. Và SR-IOV trên nó thì mù mờ, không ai tôi hỏi xác nhận được rõ theo hướng nào. Nếu cần SR-IOV thì NC552SFP là lựa chọn tốt hơn, nó dùng bnx2x và hỗ trợ SR-IOV đàng hoàng, nhưng phải bật ARI forwarding ở phía trên nó thì mới hiện ra.