StarTech ST10GSPEXNB (Tehuti TN4010) का vendor driver Debian 11, kernel 5.10 पर build नहीं होता
backup server को 10G SFP+ port देने के लिए एक StarTech ST10GSPEXNB खरीदा, यह मानकर कि Linux driver के साथ बिकने वाला card किसी current distribution के खिलाफ build हो जाएगा। यह मेरी तरफ से थोड़ा optimistic सोच थी।
- StarTech ST10GSPEXNB, Tehuti TN4010 chip
- Debian 11, kernel 5.10.0-13-amd64, matching headers installed
- card के लिए जैसे shipped है वैसा vendor driver package
- cage में generic 10G SFP+ module, वैसे card अभी इतनी दूर पहुंचा ही नहीं कि उसकी परवाह करे
make काफी दूर तक चलता है और फिर 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'आखिरी दो DMA mapping calls में हैं।
अब तक जो try किया:
- chmod +x mvidtoh.sh किया, क्योंकि build पहले permission denied के साथ रुक जाता था और PHY headers generate नहीं करता था - वह हिस्सा sorted है
- uname -r को installed headers से मिलाकर देखा, दोनों match करते हैं
- vendor जो package भेजता है उससे नया कोई package ढूंढा, कुछ भी नहीं मिला
क्या कोई इनमें से एक को इस decade के किसी kernel पर चला रहा है, और अगर हां, तो कैसे?
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
exactly कौन सा driver package - tarball पर कोई version stamped है, और उसकी readme किस kernel range का दावा करती है? हर Tehuti based card जो मेरे हाथ से गुज़रा है उसने एक source tree भेजा है जो readme में अपने supported kernels बताता है, और यह अक्सर आप जो actually चला रहे हैं उससे काफी पीछे होता है।
यह भी बताना ज़रूरी है कि आप कौन सा tree build कर रहे हैं। एक तो card के साथ आने वाला vendor drop है, और फिर community tn40xx trees हैं - tn40xx-006 और tn40xx-003, साथ ही linux-6.6 और linux-6.7 branches - और ये इतिहास में एक जैसी जगह पर कहीं नहीं हैं। लोग बिना यह notice किए कि अलग-अलग code की बात कर रहे हैं, इनके बीच notes compare करते रहते हैं।
आखिरी बात: क्या log में 3644 वाकई पहली error है, या ऊपर कुछ ऐसा है जिसे आपने noise समझकर छोड़ दिया? वे तीन lines एक ही API change जैसी दिखती हैं, पर अगर build पहले ही टूट गया था तो बाकी सब उसी का fallout है।
Community trees मेरे लिए नई बात है - मेरे पास हमेशा सिर्फ box में आया tarball रहा है, और यहां जो कुछ भी है वह वहीं से build हुआ है, shipped जैसा unpack करके। वे branches अब अगली चीज़ हैं जो मैं पढ़ूंगा। tarball पर या makefile में कहीं कोई version नहीं है, जितना वह मायने रखता हो।
readme बिल्कुल वैसी ही है जैसी आपने बताई। यह 3.x kernels की बात करती है और 4.14 line पर रुक जाती है। मैंने इसे hard limit के बजाय यह note समझा कि उन्होंने किस पर test किया था, जो अब naive लगता है।
और हां, 3644 ही पहली error है। इसके ऊपर सिर्फ warnings हैं - unused variables, implicit declarations, वैसी चीज़ें जो वह tree जाहिरा तौर पर आम बात की तरह पैदा करता है - और build इन सब से काफी खुशी-खुशी गुज़र जाता है इससे पहले कि transmit path में बिल्कुल रुक जाए। हर run में वही तीन lines, 3644, 3648 और 3651, उसी order में।
readme का मतलब जो भी रहा हो, यह hard limit है, और जो errors आपने paste किए वे बताते हैं क्यों।
kernel ने skb fragments को represent करने का तरीका बदल दिया। 5.4 से आगे skb_frag_t एक bio_vec है, और struct skb_frag_struct अब बिल्कुल है ही नहीं। जो source struct skb_frag_struct * को assign करता है, उसे ठीक आपकी line 3644 वाली शिकायत मिलती है, और जो कुछ भी फिर उसे dereference करके DMA mapping calls को एक page और offset देता है, उसे 3648 और 3651 पर undefined type के invalid use वाली error मिलती है। कोई header, कोई flag और कोई पुराना compiler आपको ऐसे type के आसपास नहीं ले जा सकता जो अब मौजूद ही नहीं।
तो 5.10 पर उस tree को configure करने के बजाय edit करना होगा। transmit path में fragment handling को current accessors के हिसाब से फिर से लिखना होगा, और यह एक line की fix नहीं, असली patch है, क्योंकि उन accesses के आसपास DMA mapping भी साथ ही shape बदल देती है।
मेरे पास इनमें से कोई card नहीं है, तो इसे diagnosis समझें, promise नहीं। मैं बता सकता हूं कि build क्यों fail होता है और यह source की problem है; यह नहीं बता सकता कि driver बाद में link up कर देता है।
उस patch में एक weekend झोंकने से पहले, देख लें कि उसके दूसरी तरफ क्या इंतज़ार कर रहा है।
मेरे पास यहां एक StarTech PEX10000SFP है, TN9510 variant, PCI 1fc9:4025 और subsystem 1fc9:3015 के साथ। out-of-tree tn40xx driver इसके लिए build और load होता है, और dmesg पूरी तरह उत्साहजनक है:
और फिर interface हमेशा के लिए NO-CARRIER पर बैठ जाता है, module में लाल light के साथ। वही card, वही cage, वही optic StarTech के Windows driver के नीचे: तुरंत link करता है। तो hardware सही है और PHY firmware load हो जाता है, बात driver port के link stage की है जो कभी काम पूरा नहीं करता।
मैंने Ubuntu 22.04 और Rocky Linux 8.10 से गुज़रा, kernels 4.18, 5.15, 6.5 और 6.9, और tn40xx-006, tn40xx-003, linux-6.6 और linux-6.7 branches। इनमें से किसी ने भी carrier नहीं दिया। ईमानदारी से, इसे compile कराना आसान वाला आधा हिस्सा है।
यह weekend के बजाय पैसे खर्च करने वाली दलील है, और मैं यह उस इंसान की तरह कह रहा हूं जो आमतौर पर weekend वाला option पसंद करता है। एक used Intel या Mellanox 10G card आपके एक दोपहर के समय से भी सस्ता पड़ता है और इसका driver उस kernel में पहले से है जिसे आप boot कर रहे हैं।
अगर Intel पर जाएं और उसमें third party optic लगाएं तो एक बात जान लें। एक X520 module को सीधे reject कर देता है, "unsupported SFP+ module type was detected" के साथ, और आपके पास कोई interface ही नहीं बचता। fix एक module option है:
Dual port cards वहां 1,1 चाहते हैं। फिर update-initramfs -u और एक cold boot, सिर्फ module unload-reload करने के बजाय, क्योंकि वह disabled state firmware में latch हो जाती है और warm reload अक्सर उसे clear नहीं करता। यह सिर्फ 82599 और X520 पर है, जहां check driver में रहता है। X710 पर check firmware में है और यह option आपको नहीं बचाएगा।
सही सलाह, गलत problem, एक ही सांस में। allow_unsupported_sfp driver की optic whitelist के बारे में है, और इस thread वाला card compile ही नहीं होता - यहां कोई भी optic reject होने वाले point के आसपास नहीं है। बाद में जानने लायक, अभी का जवाब नहीं।
अगर second hand table पर है तो, दूसरा जो बस काम करता है वह है एक HP NC523SFP, जो असल में OEM QLogic QLE3242 है, HP part 593715-001। यह in-kernel qlcnic driver पर चलता है, तो build करने को कुछ है ही नहीं - मेरे पास यहां एक box है जो qlcnic 5.3.66 को adapter firmware 4.8.20 के सामने report करता है, और लगने के बाद से इसे किसी ध्यान की ज़रूरत नहीं पड़ी।
दो caveats। यह गर्म चलता है, idle पर करीब 16 से 17 W, जो एक शांत कमरे में महसूस होता है। और उस पर SR-IOV एक उलझन है जिसे मैंने जिससे भी पूछा कोई एक तरफ से confirm नहीं कर पाया। अगर SR-IOV चाहिए तो NC552SFP बेहतर खरीद है, यह bnx2x इस्तेमाल करता है और उसे ठीक से support करता है, पर उसके ऊपर ARI forwarding enable करना होगा वरना यह दिखेगा ही नहीं।