Łatanie EEPROM-u Intel X520 (bit IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP), żeby odblokować wszystkie transceivery SFP+
Autor wątku udokumentował, że karty X520 oparte na 82599 mają nieudokumentowany bit EEPROM (IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP, najniższy bit słowa capability pod przesunięciem bajtowym 0x58, zwykle 0xFC zablokowane / 0xFD odblokowane), który decyduje, czy aktywne moduły SFP+ innych producentów niż Intel są akceptowane na ESXi i Windows, gdzie opcja sterownika Linuksa jest niedostępna. Opis podaje wyszukanie ID urządzenia przez lspci -nn, ethtool -e enp1s0 offset 0x58 length 1 do odczytu i ethtool -E enp1s0 magic 0x10fb8086 offset 0x58 value 0xfd do zapisu, z ostrzeżeniami, żeby przełączać tylko ten bit. Czytelnicy zgłaszali wyniki na X520-DA2, kartach z eBay używanych z ESXi i modułami Finisar, Dell-owym X520/i350 rNDC (0xFC), HPE NC560SFP+ (już 0xFD, zadziałało z MikroTik S+RJ10) i 82599, które nadal odrzucało moduł Ubiquiti 10GbE RJ45.
- Sprzęt: Intel X520-DA1, Intel X520-DA2, Dell Intel 2P X520/2P i350 rNDC, HPE NC560SFP+, Intel 82599ES
- Transceivery: Finisar SFP+, MikroTik S+RJ10, Ubiquiti UF-RJ45-10G
- Format: SFP+
Objawy / komunikaty:
non-Intel active SFP+ rejected on ESXi/Windows
EEPROM byte 0x58 = 0xFC
Comments 2
Odczytaj bajt 0x58, ustaw tylko najniższy bit (np. z 0xFC na 0xFD) przez ethtool -E i magic złożony z PCI device i vendor ID; potem karta akceptuje aktywną optykę firm trzecich na dowolnym systemie. Pasywne DAC-i i zwykłe moduły SFP zwykle działają nawet przy zablokowanym bicie.
Karty OEM od HPE, Della czy Cisco mogą przychodzić już odblokowane, co sugeruje, że blokada to ustawienie polityki Intela; jeśli moduł nadal nie działa po odblokowaniu, przetestuj go pod Linuksem z allow_unsupported_sfp, żeby oddzielić prawdziwą niekompatybilność od blokady.