Patchare l'EEPROM Intel X520 (bit IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP) per sbloccare tutti i transceiver SFP+
Chi ha aperto il thread ha documentato che le schede X520 basate su 82599 portano un bit EEPROM non documentato (IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP, bit più basso della capability word all'offset di byte 0x58, tipicamente 0xFC bloccato / 0xFD sbloccato) che decide se i moduli SFP+ attivi non Intel vengono accettati su ESXi e Windows, dove l'opzione del driver Linux non è disponibile. Lo scritto fornisce il lookup lspci -nn dell'ID dispositivo, ethtool -e enp1s0 offset 0x58 length 1 per leggere, ed ethtool -E enp1s0 magic 0x10fb8086 offset 0x58 value 0xfd per scrivere, con l'avvertenza di toccare solo quel bit. Chi ha seguito ha riportato risultati su X520-DA2, schede eBay usate con ESXi e moduli Finisar, Dell-branded X520/i350 rNDC (0xFC), HPE NC560SFP+ (già a 0xFD, funzionava con un MikroTik S+RJ10) e un 82599 che continuava a rifiutare un modulo Ubiquiti 10GbE RJ45.
- 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
- Fattore di forma: SFP+
Sintomi / messaggi:
non-Intel active SFP+ rejected on ESXi/Windows
EEPROM byte 0x58 = 0xFC
Comments 2
Leggi il byte 0x58, imposta solo il bit più basso (ad esempio da 0xFC a 0xFD) con ethtool -E e il magic composto da device ID e vendor ID del PCI; dopo di che la scheda accetta ottiche attive di terze parti su qualsiasi OS. I DAC passivi e i semplici moduli SFP di solito funzionano anche da bloccati.
Le schede OEM di HPE, Dell o Cisco possono arrivare già sbloccate, il che suggerisce che il blocco sia un'impostazione di policy Intel; se un modulo continua a fallire dopo lo sblocco, testalo sotto Linux con allow_unsupported_sfp per separare un'incompatibilità reale dal blocco.