بطاقة Intel X520 في جهاز R630 ترفض وحدة SFP+ نحاسية من نوع 10GBASE-T مع comp_codes_10g=0x00 رغم ضبط allow_unsupported_sfp=1
نعمل على دمج جهازَي R630 على سرعة 10G، والتوصيل إلى أعلى الرف نحاسي، فبدلًا من مدّ ألياف بصرية ركّبتُ وحدات SFP+ من نوع 10GBASE-T في بطاقات X520. طرف المفتاح (switch) يقبلها دون أي مشكلة. الخوادم ترفضها.
- Dell PowerEdge R630, بطاقة Intel X520 (82599) بمنفذين
- FS SFP-10GM-T-30، بترميز Dell، وحدة واحدة لكل خادم
- برنامج ixgbe من خارج الشجرة (out-of-tree) من Intel، مبني عبر DKMS
- /etc/modprobe.d/ixgbe.conf مع ضبط خيار التجاوز على كلا المنفذين
# 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 - إعادة بناء initramfs وإعادة تشغيل الجهاز تشغيلًا باردًا، وليس مجرد إعادة تحميل الوحدة
- نقل الوحدة إلى المنفذ الثاني ثم إلى الخادم الثاني، وكانت النتيجة نفسها
الجزء المثير للاهتمام هو بايت التوافق ذاك: الوحدة لا تُبلّغ بأي شيء إطلاقًا لسرعة 10G. هل يختبر المشغّل (driver) هذا قبل أن ينظر أصلًا إلى خيار التجاوز (override)؟ وهل هناك ما يمكن فعله غير شراء وحدات بترميز صحيح؟
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)، بل تصارع ترتيب الفحوصات.
معيار SFF-8472 لا يحتوي على بت توافق لـ 10GBASE-T. لا يوجد ببساطة رمز مخصص له، لذا فإن وحدة SFP+ نحاسية صادقة تُبلّغ برموز توافق 10G صفرية بالكامل، وهذا بالضبط ما تراه في
comp_codes_10g=0x00. يقرأ ixgbe هذا البايت، ولا يجد فيه ما يتعرّف عليه كوحدة 10G، فيتوقف عند هذه النقطة، قبل أن يصل أصلًا إلى خيارallow_unsupported_sfp. لهذا السبب يعمل هذا الخيار جيدًا مع وحدة بصرية غير معتمدة أو كابل DAC، ولا يفعل شيئًا إطلاقًا مع وحداتك النحاسية.توجد رقعة (patch) من المجتمع لمشغّل ixgbe من خارج الشجرة الخاص بـ Intel تُغيّر مكان فحص التوافق: عندما يضبط المسؤول صراحةً
allow_unsupported_sfp=1، تُصنَّف الوحدة التي تُبلّغ برموز توافق 10G صفرية بالكامل على أنها SR بدلًا من رفضها مبكرًا. جرى تقديم هذه الرقعة إلى المشروع الأصلي (upstream) ولا تزال غير مدمجة، لذا عليك تطبيقها يدويًا على مصدر DKMS والاحتفاظ بها مع بنائك الخاص. أفاد من كتبها بتحقيق 10 جيجابت في الثانية دوبلكس كامل على زوج من الخوادم بعد ذلك، وأكّد شخص آخر أن الرقعة نفسها تجعل وحدات HLX-SFPX النحاسية تعمل في بطاقة X520.هناك تحذيران قبل أن تفعل ذلك. الوحدة البصرية التي لم تعتمدها Intel تقع خارج ضمان التوافق الخاص بها، فتصبح هذه مشكلتك أنت لا مشكلتهم. كما أن PHY الخاص بـ 10GBASE-T قطعة ساخنة - وفي حجرة خوادم بلا تهوية خاصة بها سترتفع حرارتها كثيرًا فوق أي وحدة بصرية في الفتحة المجاورة، لذا راقب درجة حرارة الوحدة بعد تشغيل الوصلة.
هناك أمران يجب التأكد منهما قبل تطبيق أي رقعة.
أولًا، اطبع القيمة كما تراها النواة (kernel) فعليًا عبر
/sys/module/ixgbe/parameters/allow_unsupported_sfp، على جهاز مرّ بإعادة تشغيل باردة وليس مجرد إعادة تحميل للوحدة. إن لم تُطابق هذه القراءة ما هو مكتوب في ملف الإعداد لديك، فهذا يعني أن شيئًا ما يحمّل المشغّل قبل أن يدخل إعدادك حيز التنفيذ، وبقية التشخيص سيكون مضيعة للوقت.ثانيًا، أي نسخة من ixgbe مُحمَّلة؟ الأمر
ethtool -iلا يفيدك ما دام المشغّل لا يكتمل تحميله والواجهات غير موجودة، لذا انشر ما يُظهرهmodinfo ixgbeوإصدار حزمة DKMS التي بنيتها.ومن أين يأتي
comp_codes_10g=0x00هذا - هل هو ما يخبرك به المشغّل، أم أنك استخرجت EEPROM الوحدة بنفسك؟القيمة في الملف هي
1,1، و/sys/module/ixgbe/parameters/allow_unsupported_sfpيعيد1,1بعد إعادة التشغيل الباردة، فهو مُطبَّق إذن وليس متجاهَلًا بصمت. أُعيد بناء initramfs قبل إعادة التشغيل. نفس السطر يظهر في dmesg في كلتا الحالتين.رموز التوافق قرأتُها بنفسي من بيانات SFF-8472 الخاصة بالوحدة، لا من المشغّل - بايت توافق 10G صفر، وبقية حقول التعريف تبدو سليمة. نفس الوحدة في منفذ المفتاح (switch) تعمل بسرعة 10G، فهي إذن ليست وحدة معطوبة.
يستحق الإضافة من الناحية العملية: مع DKMS تُعاد كل ترقية للنواة بناء المشغّل من المصادر الموجودة على القرص، لذا يجب أن تبقى الرقعة في شجرة المصادر تلك، لا في مجلد بناء تحذفه لاحقًا. تحقّق من عودة المنفذ إلى العمل بعد أول تحديث للنواة بدلًا من اكتشاف المشكلة أثناء نافذة إعادة تشغيل.
الدرس الأعم من هذا النوع من المشكلات هو أن إصدار المشغّل (driver) يحدد أكثر مما يحدده ترميز الوحدة. نفس القصة تتكرر على بطاقة X710 مع كابل DAC سلبي (passive): نفس الكابل ونفس المنفذ يعملان بسلاسة تحت Ubuntu 24.04 ويتعطلان تحت TrueNAS SCALE مع
Link detected: noوSpeed: Unknown، لأن ذلك الإصدار كان يحمل i40e من نواة 6.6.44-production. أما في 25.04-BETA.1، حيث يُؤخذ i40e من 6.12.9-production، فقد عمل كابل twinax من تلقاء نفسه - دون تغيير أي شيء آخر، والبطاقة لا تزال على الفيرموير 9.20. كانت الوحدات البصرية تعمل بشكل جيد على ذلك المنفذ تحت كلا النظامين، وهو ما أثبت أن الخلل في كيفية تعامل المشغّل الأقدم مع النحاس السلبي. تنفيذethtool -iعلى طرفي المقارنة كان سيوفر الكثير من تبديل الكابلات.نوع مختلف من الوحدات، ونفس المشغّل، وفخّ يستحق استبعاده وأنت في هذا الموضوع أصلًا. جهاز Dell R720 مع بطاقة X520 ابنة، وحدات Cisco 10G متعددة الأنماط LC مرفوضة، والواجهات ببساطة غير موجودة. كان الخيار موجودًا في modprobe.d، وموجودًا في GRUB أيضًا، ولم يتغير شيء - لأن الجهاز يقلع عبر EFI ولم تُستخدم سطر أوامر GRUB تلك أصلًا.
في نظام Proxmox يقلع عبر EFI، يجب أن يكون الخيار في
/etc/kernel/cmdlineبصيغةixgbe.allow_unsupported_sfp=1، متبوعًا بـpve-efiboot-tool refresh. وحتى في تلك الحالة لم يُصلح ذلك المشكلة، وانتهى بهم الأمر إلى شراء وحدات بعلامة Intel، فاعتبر هذا شيئًا يجب استبعاده لا حلًا.الأمر الآخر المستفاد من تلك الفوضى: يجب أن يكون الطرفان راضيين عن الوحدة البصرية كلٌّ على حدة. فالوحدة التي يقبلها المفتاح (switch) قد يرفضها المضيف (host)، وهو بالضبط الموضع الذي أنت فيه الآن.
طبّقتُ الرقعة على مصدر DKMS وأعدت البناء. كلا المنفذين يعملان الآن بسرعة 10 جيجابت في الثانية دوبلكس كامل وظلّا كذلك تحت الحمل منذ ذلك الحين.
يعمل، لكنني لن أسمّيه محلولًا. إنها رقعة غير مدمجة أحملها الآن مع كل تحديث للنواة، والمشغّل يعرض المنفذ على أنه SR، مما سيُربك من ينظر إلى هذا الجهاز بعدي. كما أن الوحدة تعمل بحرارة أعلى بوضوح من الوحدات البصرية في الحجرة المجاورة، وتلك الفتحة لا تكاد تحظى بأي تهوية. في الدفعة القادمة من الخوادم سأمدّ ألياف بصرية وأتوقف عن مجادلة المشغّل.