Intel-X520-EEPROM patchen (Bit IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP), um alle SFP+-Transceiver freizuschalten
Der Thread-Starter hat dokumentiert, dass 82599-basierte X520-Karten ein undokumentiertes EEPROM-Bit tragen (IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP, niedrigstes Bit des Capability-Worts bei Byte-Offset 0x58, typischerweise 0xFC gesperrt / 0xFD entsperrt), das entscheidet, ob aktive SFP+-Module von Drittanbietern unter ESXi und Windows akzeptiert werden, wo die Linux-Treiberoption nicht verfügbar ist. Der Beitrag zeigt das Auslesen der Device-ID per lspci -nn, ethtool -e enp1s0 offset 0x58 length 1 zum Lesen und ethtool -E enp1s0 magic 0x10fb8086 offset 0x58 value 0xfd zum Schreiben, mit der Warnung, nur dieses eine Bit zu kippen. Mitleser berichteten Ergebnisse auf X520-DA2, eBay-Karten mit ESXi und Finisar-Modulen, Dell-markiertem X520/i350-rNDC (0xFC), HPE NC560SFP+ (bereits 0xFD, funktionierte mit einem MikroTik S+RJ10) und einem 82599, das ein Ubiquiti-10GbE-RJ45-Modul weiterhin ablehnte.
- Hardware: Intel X520-DA1, Intel X520-DA2, Dell Intel 2P X520/2P i350 rNDC, HPE NC560SFP+, Intel 82599ES
- Transceiver: Finisar SFP+, MikroTik S+RJ10, Ubiquiti UF-RJ45-10G
- Formfaktor: SFP+
Symptome / Meldungen:
non-Intel active SFP+ rejected on ESXi/Windows
EEPROM byte 0x58 = 0xFC
Comments 2
Byte 0x58 lesen, nur das niedrigste Bit setzen (z. B. 0xFC auf 0xFD) mit ethtool -E und dem aus PCI-Device- und Vendor-ID gebildeten magic; danach akzeptiert die Karte aktive Drittanbieter-Optik unter jedem Betriebssystem. Passive DACs und schlichte SFP-Module funktionieren meist auch gesperrt.
OEM-Karten von HPE, Dell oder Cisco werden mitunter schon entsperrt ausgeliefert, was nahelegt, dass die Sperre eine Intel-Policy-Einstellung ist; schlägt ein Modul nach dem Entsperren weiterhin fehl, teste es unter Linux mit allow_unsupported_sfp, um eine echte Inkompatibilität von der Sperre zu unterscheiden.