ترقيع EEPROM الخاصة بـIntel X520 (بت IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP) لفتح كل وحدات SFP+
وثّق صاحب النقاش أن بطاقات X520 القائمة على 82599 تحمل بتًا غير موثّق في EEPROM (IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP، أدنى بت في كلمة القدرة عند الإزاحة 0x58، عادة 0xFC مقفل / 0xFD مفتوح) يحدد ما إذا كانت وحدات SFP+ النشطة من غير Intel مقبولة على ESXi وWindows، حيث لا يتوفر خيار تعريف Linux. يقدّم المنشور استعلام lspci -nn لمعرف الجهاز، وethtool -e enp1s0 offset 0x58 length 1 للقراءة، وethtool -E enp1s0 magic 0x10fb8086 offset 0x58 value 0xfd للكتابة، مع تحذيرات بتبديل ذلك البت فقط. أبلغ متابعون عن نتائج على X520-DA2، بطاقات من eBay استُخدمت مع ESXi ووحدات Finisar، بطاقة Dell rNDC من نوع X520/i350 (0xFC)، وHPE NC560SFP+ (كانت بالفعل 0xFD، عملت مع MikroTik S+RJ10) وبطاقة 82599 ما زالت ترفض وحدة Ubiquiti 10GbE RJ45.
- العتاد: Intel X520-DA1، Intel X520-DA2، بطاقة Dell rNDC من نوع Intel 2P X520/2P i350، HPE NC560SFP+، Intel 82599ES
- الوحدات الضوئية: Finisar SFP+، MikroTik S+RJ10، Ubiquiti UF-RJ45-10G
- الشكل: SFP+
الأعراض / الرسائل:
non-Intel active SFP+ rejected on ESXi/Windows
EEPROM byte 0x58 = 0xFC
Comments 2
اقرأ البايت 0x58، وعدّل فقط أدنى بت فيه (مثلًا من 0xFC إلى 0xFD) باستخدام ethtool -E والقيمة السحرية (magic) المكوّنة من معرّفي جهاز ومورّد PCI؛ بعدها تقبل البطاقة البصريات النشطة من طرف ثالث على أي نظام تشغيل. كابلات DAC السلبية ووحدات SFP العادية عادة ما تعمل حتى وهي مقفلة.
بطاقات OEM من HPE أو Dell أو Cisco قد تُشحن مفتوحة، مما يشير إلى أن القفل هو إعداد سياسة من Intel؛ إذا استمرت وحدة في الفشل بعد الفتح، اختبرها تحت Linux مع allow_unsupported_sfp لفصل عدم توافق حقيقي عن القفل.