برنامج التشغيل الخاص بالمورّد لبطاقة StarTech ST10GSPEXNB (شريحة Tehuti TN4010) لا يُبنى على Debian 11 بنواة 5.10
اشتريت بطاقة StarTech ST10GSPEXNB لإعطاء خادم احتياطي منفذ SFP+ بسرعة 10G، على افتراض أن بطاقة تُباع مع برنامج تشغيل لينكس ستُبنى مقابل توزيعة حديثة. كان هذا تفاؤلًا مني.
- StarTech ST10GSPEXNB، شريحة Tehuti TN4010
- Debian 11، نواة 5.10.0-13-amd64، مع رؤوس مطابقة مثبتة
- حزمة برنامج التشغيل الخاص بالمورّد كما شُحنت مع البطاقة
- وحدة SFP+ عامة بسرعة 10G في الفتحة، رغم أن البطاقة لم تصل بعد لمرحلة الاهتمام بها
يتقدم make لمسافة طويلة ثم يفشل في مسار الإرسال:
$ 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.
ما تم تجربته حتى الآن:
- تنفيذ chmod +x mvidtoh.sh، لأن البناء توقف سابقًا برسالة permission denied ولم يُولّد رؤوس PHY - هذا الجزء تم حله
- التحقق من uname -r مقابل الرؤوس المثبتة، وهما متطابقان
- البحث عن حزمة أحدث من التي يشحنها المورّد ولم أجد شيئًا على الإطلاق
هل يُشغّل أحد إحدى هذه البطاقات على نواة من هذا العقد، وإذا كان الأمر كذلك، كيف؟
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
أي حزمة برنامج تشغيل بالضبط - هل هناك رقم إصدار مطبوع على ملف tarball، وما نطاق النواة الذي يدّعيه ملف readme الخاص بها؟ كل بطاقة مبنية على Tehuti مرّت بين يديّ تُشحن مع شجرة مصدر تُسمّي النوى المدعومة في readme، وعادةً ما تكون متأخرة كثيرًا عن أي نواة تُشغّلها فعليًا.
يستحق الذكر أيضًا أي شجرة تبنيها. هناك حزمة المورّد التي تأتي مع البطاقة، وهناك أشجار المجتمع tn40xx - tn40xx-006 وtn40xx-003، بالإضافة إلى فرعي linux-6.6 وlinux-6.7 - وهي ليست قريبة أبدًا من نفس النقطة في التاريخ. يقارن الناس ملاحظاتهم عبرها جميعًا طوال الوقت دون أن يلاحظوا أنهم يناقشون أكوادًا مختلفة.
آخر شيء: هل السطر 3644 هو حقًا أول خطأ في السجل، أم أن هناك شيئًا أعلى قرأته كضوضاء؟ هذه الأسطر الثلاثة تبدو كتغيير واحد في واجهة برمجة التطبيقات، لكن إذا فشل البناء قبل ذلك فإن الباقي مجرد تبعات له.
أشجار المجتمع خبر جديد بالنسبة لي - لم يكن لدي سوى ملف tarball الذي جاء في الصندوق، وكل شيء هنا مبني منه، مفكوكًا كما شُحن. تلك الفروع هي الشيء التالي الذي سأقرأه. لا يوجد رقم إصدار في أي مكان على tarball أو في makefile، إن كان لهذا فائدة.
ملف readme هو بالضبط كما وصفت. يتحدث عن نوى 3.x ويتوقف عند خط 4.14. فهمت ذلك كملاحظة حول ما اختُبر عليه وليس حدًا صارمًا، وهذا الآن يبدو ساذجًا.
ونعم، 3644 هو أول خطأ. فوقه لا يوجد سوى تحذيرات - متغيرات غير مستخدمة، إعلانات ضمنية، النوع الذي تُنتجه تلك الشجرة بشكل طبيعي على ما يبدو - ويمر البناء عبرها كلها بسعادة قبل أن يتوقف تمامًا في مسار الإرسال. نفس الأسطر الثلاثة، 3644 و3648 و3651، بنفس الترتيب، في كل تشغيل.
إنه حد صارم، مهما كان ما قصده readme، والأخطاء التي لصقتها توضح السبب.
غيّرت النواة طريقة تمثيل أجزاء skb. من الإصدار 5.4 فصاعدًا، skb_frag_t هو bio_vec، وstruct skb_frag_struct ببساطة لم يعد موجودًا. المصدر الذي يُسند إلى struct skb_frag_struct * يحصل بالضبط على شكوى السطر 3644 لديك، وأي شيء يُلغي مرجعيته بعد ذلك لتسليم صفحة وإزاحة لاستدعاءات ربط DMA يحصل على invalid use of an undefined type في السطرين 3648 و3651. لا رأس، ولا علامة، ولا مترجم أقدم يمكنه تجاوز نوع لم يعد موجودًا.
إذن على 5.10 تحتاج تلك الشجرة إلى تعديل وليس إعداد. يجب إعادة كتابة معالجة الأجزاء في مسار الإرسال مقابل دوال الوصول الحالية، وهو تصحيح حقيقي وليس إصلاحًا بسطر واحد، لأن ربط DMA حول تلك الوصولات يتغيّر شكله في نفس الوقت.
لا أملك واحدة من هذه البطاقات، لذا خذ هذا كتشخيص وليس وعدًا. أستطيع أن أخبرك لماذا يفشل البناء وأنها مشكلة مصدر؛ لا أستطيع أن أخبرك أن برنامج التشغيل سيُشغّل الرابط بعد ذلك.
قبل أن تُمضي عطلة نهاية أسبوع في ذلك التصحيح، ألقِ نظرة على ما ينتظر على الجانب الآخر منه.
لدي هنا بطاقة StarTech PEX10000SFP، نسخة TN9510، PCI 1fc9:4025 مع نظام فرعي 1fc9:3015. برنامج التشغيل tn40xx خارج الشجرة يُبنى ويُحمّل لها، وdmesg مُشجّع تمامًا:
ثم تبقى الواجهة في حالة NO-CARRIER بضوء أحمر في الوحدة، إلى الأبد. نفس البطاقة، نفس الفتحة، نفس الوصلة الضوئية تحت برنامج تشغيل StarTech لويندوز: تعمل فورًا. إذن العتاد سليم والبرنامج الثابت لـ PHY يُحمَّل، إنها مرحلة الرابط في منفذ برنامج التشغيل هذا التي لا تُنهي المهمة أبدًا.
مررت عبر Ubuntu 22.04 وRocky Linux 8.10، نوى 4.18 و5.15 و6.5 و6.9، وفروع tn40xx-006 وtn40xx-003 وlinux-6.6 وlinux-6.7. لم يعطني أي منها حاملًا (carrier). الحصول على تجميع الشيء هو النصف السهل، بصراحة.
هذه هي الحجة لإنفاق المال بدلاً من عطلة نهاية أسبوع، وأقولها كشخص يستمتع عادةً بخيار عطلة نهاية الأسبوع. بطاقة Intel أو Mellanox بسرعة 10G مستعملة تكلف أقل من فترة بعد ظهر من وقتك وبرنامج تشغيلها موجود بالفعل في النواة التي تُقلعها.
شيء واحد يجب معرفته إذا اخترت Intel ووضعت فيها وصلة ضوئية من طرف ثالث. بطاقة X520 ترفض الوحدة تمامًا برسالة "unsupported SFP+ module type was detected" وتنتهي بدون واجهة على الإطلاق. الحل هو خيار للوحدة:
البطاقات ثنائية المنفذ تريد 1,1 هناك. ثم update-initramfs -u وإعادة تشغيل كاملة بدلاً من مجرد إلغاء تحميل الوحدة وإعادة تحميلها، لأن تلك الحالة المعطّلة تُثبَّت في البرنامج الثابت وإعادة التحميل الساخنة غالبًا لا تمسحها. هذا يخص 82599 وX520 فقط، حيث يعيش الفحص في برنامج التشغيل. على X710 الفحص في البرنامج الثابت وهذا الخيار لن ينقذك.
نصيحة صحيحة، مشكلة خاطئة، في نفس الوقت. allow_unsupported_sfp يتعلق بالقائمة البيضاء للوصلات الضوئية في برنامج التشغيل، والبطاقة في هذا الموضوع لا تُترجم على الإطلاق - لا أحد هنا قريب حتى من نقطة رفض وصلة ضوئية. مفيدة معرفتها لاحقًا، ليست إجابة الآن.
إذا كانت المستعملة مطروحة، فالبطاقة الأخرى التي تعمل ببساطة هي HP NC523SFP، وهي نسخة OEM من QLogic QLE3242، رقم قطعة HP 593715-001. تعمل على برنامج التشغيل qlcnic المدمج في النواة، فلا شيء يحتاج للبناء على الإطلاق - لدي جهاز هنا يُبلّغ عن qlcnic 5.3.66 مقابل برنامج ثابت 4.8.20 للبطاقة، ولم يحتج لأي اهتمام منذ تركيبه.
تحفظان. تعمل بحرارة عالية، حوالي 16 إلى 17 واط عند الخمول، وهو ما تلاحظه في غرفة هادئة. وSR-IOV عليها فوضى لم يستطع أي شخص سألته تأكيدها بشكل قاطع. إذا كنت تحتاج SR-IOV فإن NC552SFP هو الخيار الأفضل، يستخدم bnx2x ويدعمه بشكل صحيح، لكن يجب تفعيل توجيه ARI فوقه وإلا لن يظهر.