بطاقة Supermicro AOC-STGN-i1S (X520) على Proxmox 7.1: لا واجهة في ip link مع كابل DAC من HP مُركّب
أشغّل جهاز Proxmox صغيرًا في المنزل وأردت مسارًا حقيقيًا بسرعة 10G إلى عقدة التخزين، فركّبت بطاقة Supermicro AOC-STGN-i1S مستعملة. إنها تصميم Intel 82599 العادي، اللوحة تحمل علامة E157872، وافترضت أن هذا سيكون الجزء الممل من البناء. لم يكن كذلك.
- Supermicro AOC-STGN-i1S، Intel X520-DA1، علامة اللوحة E157872
- Proxmox 7.1، نواة 5.15.30-1-pve
- كابل DAC سلبي من نوع SFP+ بعلامة HP إلى الجهاز الثاني
- البطاقة تُعرَض بشكل طبيعي على ناقل PCI
التعريف (driver) لا ينتهي من التحميل أبدًا. سجل النواة يقول إنه أوقف العملية لأنه اكتشف نوع وحدة SFP+/QSFP لا يدعمه، وبعد ذلك ببساطة لا يوجد منفذ لإعداده:
lspci -> the X520 is listed, no complaints
ip link -> lo and the onboard 1G only, no 10G interface at all
dmesg -> ixgbe aborts loading, unsupported SFP+/QSFP module typeما فعلته بالفعل:
- أنشأت /etc/modprobe.d/ixgbe.conf يحتوي
options ixgbe allow_unsupported_sfp=1، ثمupdate-initramfs -uوإعادة تشغيل: لا تغيير - مررت نفس الخيار كمعامل نواة بدلًا من ذلك: لا تغيير
rmmod ixgbeوmodprobe ixgbeيدويًا: ما زال لا شيء جديد فيip link
هل البطاقة ميتة، أم توجد طريقة لتجاوز هذا الفحص على نواة 5.15 تفوتني؟
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 5
ما تصفه هو بالضبط ما يبدو عليه الاصطدام بقائمة بيضاء في EEPROM على ixgbe. يقرأ التعريف معرّف الوحدة، ويقرر أنها ليست ضمن قائمة Intel المقبولة، ويوقف العملية قبل أن يسجل أي netdev إطلاقًا، وهذا سبب رؤية
lspciللبطاقة بينماip linkلا يظهر شيئًا إطلاقًا. لا شيء من هذا عطل في العتاد، وهذا أيضًا سبب عودة المنفذ لحظة إخراج الوحدة من المقبس.المخرج الموثّق هو نفسه الذي استخدمته بالفعل:
على 5.15 هذا الخيار ببساطة غير موثوق. حصلت على نفس النتيجة السلبية على هذه النواة، لذا لا فائدة من إعادة تنفيذه أو البحث عن خطأ إملائي في ملف الإعداد.
ما حسم الأمر عندي: مع مقبس فارغ ظهرت الواجهة عند
modprobe ixgbe، وإعادة كابل HP جعلتها تختفي مجددًا، ونفس كابل HP عمل دون مشاكل في بطاقة Mellanox ConnectX-2. الكابل سليم كهربائيًا، فقط Intel لا تحب طريقة ترميزه.الإصلاح الذي نجح كان تركيب كابل DAC عام غير معلَّم بأي علامة تجارية بدلًا منه. الرابط يعمل فورًا، بلا خيارات وحدة، بلا رقصة إعادة تشغيل. بخصوص الدعم: مع أي كابل بترميز غير Intel أنت خارج مصفوفة Intel على أي حال، لذا إذا كان لهذا الجهاز يومًا حاجة للدعم، اشترِ كابل DAC بترميز Intel بدلًا من واحد من HP.
قبل أن تحكم على البطاقة بأنها ميتة، شغّل اختبارًا واحدًا. انزع كابل DAC من المقبس تمامًا، ثم
rmmod ixgbe، وmodprobe ixgbeوانظر إلىip linkمجددًا. إذا ظهرت الواجهة مع مقبس فارغ، فالبطاقة والتعريف كلاهما سليمان والكابل هو ما يعطّل الفحص.شيء آخر يستحق المعرفة: هل يعمل كابل HP ذاك في أي مكان آخر؟ عادة تقبله بطاقة شبكة من غير Intel دون أي اعتراض. وهل هو بالتأكيد الكابل بترميز HP، أم لديك كابل عام تقارن به؟
اعتبر نفسك محظوظًا لكونك على X520، حيث لديك على الأقل مقبضًا في التعريف، رغم عدم موثوقيته. على X710 وXL710 انتقل فحص الوحدة إلى البرنامج الثابت (firmware)، لذا فإن
allow_unsupported_sfpلا يفعل شيئًا إطلاقًا بالنسبة لـi40e. ضع وحدة من غير Intel في X710-DA2 وستحصل على:وهذا نهاية النقاش. من هناك الخيارات هي بصريات بترميز Intel، أو طريق xl710-unlocker المجتمعي (دفع صورة NVM جديدة بأداة تحديث Intel نفسها، ثم العبث بحقول من أحد عشر بت في مكان ما حول 0x6800-0x7000 في EEPROM بأدوات من طرف ثالث، على مسؤوليتك الكاملة)، أو اختيار نسخة OEM من البداية: بطاقة HPE 562SFP+ هي X710 من الداخل، وبعد تحديثات البرنامج الثابت وi40e قبلت وحدات نحاسية من طرف ثالث بسرعة 10G و1G دون أي حيل إطلاقًا.
بخصوص زاوية OEM، تسير بالاتجاه المعاكس لبطاقات X710-DA2 بعلامة Dell وLenovo: فهي ترفض SFP+ وDAC غير المعتمدة، وأدوات Intel نفسها لا تُدرج اللوحة إطلاقًا. ما استقر عليه الناس هو تحميل NVM قياسي من Intel عليها. تحتاج أولًا إلى تعريف QV من حزمة BootUtil الكاملة من Intel، وإلا فلن تتحدث الأدوات مع اللوحة إطلاقًا؛ يُستبدل option ROM قبل أي شيء آخر، وعندها فقط تجرد البطاقة وتحمّل عليها:
بين الجرد والتحميل، قلّص nvmupdate.cfg إلى إدخال X710 الواحد المطابق لحجم ذاكرة SPI الفلاش في البطاقة، 4 أو 8 ميغابايت. اختر الحجم الخاطئ وستحصل على قطعة معطلة تحتاج صورة NVM محفوظة وأداة تحميل عتادية لاستعادتها، لذا اقرأ ETrackID أولًا وتأكد. أُبلغ أن البرنامج الثابت في نطاق 9.30-9.40 يعمل بعد ذلك، وحصل الناس على SR-IOV على لوحات Lenovo كأثر جانبي. مع ذلك لن أجربها إلا على بطاقة يمكنني تحمل خسارتها.
احذر من توجيه طرق crossflash وتعديل EEPROM إلى هذا النقاش، لأن أيًا منهما لا يفيد الحالة الموصوفة. تعديل علامة OEM في EEPROM الخاصة بـX520 يحتاج إلى واجهة تعمل للوصول إلى البطاقة من خلالها أصلًا، وهنا لا توجد أي واجهة إطلاقًا حتى يخرج الكابل من المقبس. هذا إصلاح لمنفذ موجود ويرفض وحدة واحدة، وليس لتعريف يوقف العملية عند التحميل.
الشيء الآخر الذي لن أبالغ في تفسيره هو الاختبار في بطاقة شبكة أخرى. وحدة تعمل في مضيف مختلف تثبت الوحدة، وليس المضيف الذي تريدها فيه فعليًا. لديّ وحدات نحاسية Ubiquiti UACC-CM-RJ45-MG تعمل بسعادة في CCR2004 وفي Intel X520-DA2 تحت Debian، وفي مقابس SFP+ الخاصة بـCRS309 وCRS328 لا تعمل أبدًا إطلاقًا، سواء مع التفاوض التلقائي أو بسرعة مثبّتة يدويًا. اعتماد الوحدة على المضيف حقيقي، لذا تحقق في الجهاز المحدد نفسه قبل شراء كومة من أي شيء.