R630 में Intel X520, allow_unsupported_sfp=1 के बावजूद comp_codes_10g=0x00 वाले 10GBASE-T copper SFP+ को reject करता है
हम एक जोड़ी R630s को 10G पर consolidate कर रहे हैं और rack के top तक जाने वाली cabling copper है, तो fibre खींचने के बजाय मैंने X520 cards में 10GBASE-T SFP+ modules डाल दिए। switch वाला सिरा इन्हें बिना किसी एतराज़ के ले लेता है। servers लेने से मना कर देते हैं।
- Dell PowerEdge R630, Intel X520 (82599), dual port
- FS SFP-10GM-T-30, Dell-coded, हर server में एक module
- Intel का out-of-tree ixgbe, DKMS से build किया
- /etc/modprobe.d/ixgbe.conf जिसमें दोनों ports के लिए override set है
# cat /etc/modprobe.d/ixgbe.conf
options ixgbe allow_unsupported_sfp=1,1
# dmesg
ixgbe: failed to load because an unsupported SFP+ module type was detected
# 10G compliance codes read back from the module
comp_codes_10g=0x00मैं पहले ही जो आज़मा चुका हूं:
modprobe ixgbe allow_unsupported_sfp=1हाथ से, साथ ही modprobe.d वाली entry भी- initramfs फिर से बनाया और machine को cold boot किया, सिर्फ module reload नहीं
- module को दूसरे port में और फिर दूसरे server में ले गया, नतीजा वही
दिलचस्प हिस्सा वह compliance byte है: module 10G के लिए बिल्कुल कुछ नहीं बताता। क्या driver override को देखने से पहले ही यह test कर लेता है, और सही coding वाले optics खरीदने के अलावा कुछ किया जा सकता है?
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
आप किसी whitelist से नहीं, checks के क्रम से लड़ रहे हैं।
SFF-8472 में 10GBASE-T के लिए कोई compliance bit ही नहीं है। इसके लिए सीधे कोई code point मौजूद नहीं, तो एक ईमानदार copper SFP+ all-zero 10G compliance codes बताता है, जो ठीक आपका
comp_codes_10g=0x00है। ixgbe वह byte पढ़ता है, उसे 10G module जैसी कोई पहचानी हुई चीज़ नहीं मिलती और वह वहीं हार मान लेता है,allow_unsupported_sfpoverride के आसपास पहुंचने से भी पहले। यही वजह है कि यह flag किसी unqualified optical module या DAC के लिए ठीक काम करता है और आपके copper वालों के लिए बिल्कुल कुछ नहीं करता।Intel के out-of-tree ixgbe के खिलाफ एक community patch है जो compliance test को आगे-पीछे कर देता है: जब administrator ने साफ तौर पर
allow_unsupported_sfp=1set किया हो, तो all-zero 10G compliance codes बताने वाला module जल्दी बाहर फेंके जाने के बजाय SR के तौर पर classify हो जाता है। यह upstream submit हुआ था और अभी भी unmerged है, तो इसे DKMS source में हाथ से apply करें और अपनी build के साथ रखें। इसे लिखने वाले ने बाद में एक जोड़ी servers पर 10 Gb/s full duplex रिपोर्ट किया, और किसी और ने पुष्टि की कि यही patch HLX-SFPX copper modules को एक X520 में काम करा देता है।यह करने से पहले दो caveats। जिस optic को Intel ने qualify नहीं किया वह उनकी compatibility guarantee से बाहर है, तो यह अब आपकी समस्या है, उनकी नहीं। और 10GBASE-T PHY एक गर्म हिस्सा है - बिना अपने airflow वाले server cage में यह बगल वाले slot के किसी भी optical चीज़ से काफी ऊपर बैठेगा, तो link up होने के बाद module का temperature देखते रहें।
कुछ भी patch करने जाने से पहले दो चीज़ें पक्की कर लें।
पहली, parameter को वैसे ही print करें जैसे kernel असल में उसे देखता है,
/sys/module/ixgbe/parameters/allow_unsupported_sfp, ऐसी machine पर जो module reload नहीं बल्कि cold boot से गुज़री हो। अगर यह ठीक वही वापस नहीं पढ़ता जो आपकी conf file में लिखा है, तो कुछ आपके config के असर में आने से पहले ही driver load कर रहा है और बाकी debugging बेकार है।दूसरी, कौन सा ixgbe load हुआ है? जब तक driver load होना पूरा नहीं करता और interfaces नहीं होते, तब तक
ethtool -iआपके किसी काम का नहीं, तोmodinfo ixgbeजो बताता है वह post करें और साथ ही आपने जो DKMS package build किया उसका version भी।और वह
comp_codes_10g=0x00आता कहां से है - क्या driver आपको यह बता रहा है, या आपने खुद module का EEPROM dump किया?file में parameter
1,1है और cold boot के बाद/sys/module/ixgbe/parameters/allow_unsupported_sfpभी1,1वापस पढ़ता है, तो यह apply हो रहा है, चुपचाप नज़रअंदाज़ नहीं हो रहा। boot से पहले initramfs फिर से बनाया गया था। dmesg में दोनों ही हाल में वही लाइन।compliance codes मैंने खुद SFF-8472 data से module से निकाले, driver से नहीं - 10G compliance byte zero है, ID fields में बाकी सब कुछ ठीक-ठाक लगता है। switch port में वही module 10G पर link करता है, तो यह मरा हुआ module नहीं है।
practical पहलू में यह जोड़ने लायक है: DKMS के साथ हर kernel update disk पर मौजूद sources से फिर से build होता है, तो patch को उसी source tree में रहना होगा, किसी ऐसी build directory में नहीं जिसे आपने बाद में साफ कर दिया। पहले kernel bump के बाद port वापस आता है या नहीं यह जांच लें, न कि किसी reboot window के दौरान पता चले।
इस तरह की समस्या से बड़ा सबक यह है कि module की coding से ज़्यादा driver की उम्र मायने रखती है। एक passive DAC वाले X710 पर वही कहानी: एक cable, एक port, Ubuntu 24.04 के तहत खुश और TrueNAS SCALE के तहत
Link detected: noऔरSpeed: Unknownके साथ मरा हुआ, क्योंकि उस build में i40e 6.6.44-production kernel से आया था। 25.04-BETA.1 पर, जहां i40e 6.12.9-production से लिया गया है, twinax अपने आप up हो गया - और कुछ नहीं छुआ, card अभी भी firmware 9.20 पर। उस port पर optics दोनों systems के तहत ठीक थे, जिसने गलती को पुराने driver के passive copper संभालने के तरीके पर टिका दिया। तुलना के दोनों तरफethtool -iचलाने से cable बदलने की बहुत मेहनत बच जाती।अलग module type, वही driver, और एक trap जिसे आप वहीं हाथ में हैं तो rule out कर लेना अच्छा है। एक X520 daughter card वाला Dell R720, Cisco 10G multimode LC modules reject, interfaces बस गायब। option modprobe.d में था, GRUB में भी था, और कुछ नहीं बदला - क्योंकि host EFI से boot होता है और वह GRUB command line कभी इस्तेमाल ही नहीं हुई।
EFI-booted Proxmox पर parameter
/etc/kernel/cmdlineमेंixgbe.allow_unsupported_sfp=1के तौर पर जाता है, उसके बादpve-efiboot-tool refresh। उस मामले में यह भी काम नहीं आया और आखिरकार उन्होंने Intel-brand वाले modules खरीद लिए, तो इसे इलाज नहीं बल्कि खारिज करने वाली चीज़ मानें।उस गड़बड़ से एक और बात: दोनों सिरों को optic से अलग-अलग खुश होना पड़ता है। जो module switch accept करता है उसे host फिर भी reject कर सकता है, और आप वहीं पहुंचे हुए हैं।
DKMS source पर patch apply किया और फिर से build किया। दोनों ports 10 Gb/s full duplex पर up हो गए हैं और तब से load में भी बने हुए हैं।
काम कर रहा है, पर मैं इसे solved नहीं कहूंगा। यह एक unmerged patch है जिसे मैं अब हर kernel update में साथ ले जाता हूं, और driver port को SR के तौर पर दिखाता है, जो मेरे बाद इस box को देखने वाले किसी को भी confuse करेगा। module भी बगल वाले cage के optics से साफ ज़्यादा गर्म चलता है और उस slot में airflow के नाम पर कुछ नहीं है। servers के अगले batch के लिए मैं fibre खींचूंगा और driver से बहस करना बंद कर दूंगा।