Supermicro AOC-STGN-i1S (X520) su Proxmox 7.1: nessuna interfaccia in ip link con un DAC HP inserito
Gestisco un piccolo box Proxmox in casa e volevo un percorso 10G vero verso il nodo storage, quindi ho montato un Supermicro AOC-STGN-i1S usato. È il design Intel 82599 semplice, scheda marcata E157872, e davo per scontato che questa fosse la parte noiosa della build. Non lo è.
- Supermicro AOC-STGN-i1S, Intel X520-DA1, marcatura scheda E157872
- Proxmox 7.1, kernel 5.15.30-1-pve
- DAC SFP+ passivo a marchio HP verso il secondo box
- la scheda si enumera bene sul bus PCI
Il driver non finisce mai di caricarsi. Il kernel log dice che ha abortito perché ha rilevato un tipo di modulo SFP+/QSFP non supportato, e dopo quello semplicemente non c'è nessuna porta da configurare:
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 typeCosa ho già fatto:
- creato /etc/modprobe.d/ixgbe.conf con dentro
options ixgbe allow_unsupported_sfp=1, poiupdate-initramfs -ue un riavvio: nessun cambiamento - passata la stessa opzione come parametro kernel invece: nessun cambiamento
rmmod ixgbeemodprobe ixgbea mano: ancora niente di nuovo inip link
La scheda è morta, oppure c'è un modo per aggirare questo controllo su un kernel 5.15 che mi sto perdendo?
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
Quello che descrivi è esattamente l'aspetto di una whitelist EEPROM che scatta su ixgbe. Il driver legge l'ID del modulo, decide che non è nella lista accettata da Intel e abortisce prima ancora di registrare un netdev, motivo per cui
lspcivede la scheda eip linknon mostra assolutamente nulla. Niente di tutto ciò è un guasto hardware, ed è anche per questo che la porta torna nel momento in cui il modulo esce dalla cage.La via di fuga documentata è quella che hai già usato:
Su 5.15 quell'opzione semplicemente non è affidabile. Ho ottenuto lo stesso non-risultato su questo kernel, quindi non ha senso rifarla o andare a caccia di un errore di battitura nel file conf.
Quello che ha risolto dal mio lato: con la cage vuota l'interfaccia saliva con
modprobe ixgbe, rimettere il cavo HP la faceva sparire di nuovo, e quello stesso cavo HP si collegava senza drammi in una Mellanox ConnectX-2. Il cavo è elettricamente a posto, semplicemente a Intel non piace come è codificato.La soluzione che ha funzionato è stata montare invece un DAC SFP+ generico senza marchio. Link su immediatamente, nessuna opzione modulo, nessuna danza di riavvii. Sul supporto: con qualsiasi cavo non codificato Intel sei comunque fuori dalla matrice Intel, quindi se questo box deve mai essere supportabile, compra un DAC codificato Intel invece di uno HP.
Prima di dare la scheda per morta, fai un test. Tira fuori del tutto il DAC dalla cage, poi
rmmod ixgbe,modprobe ixgbee riguardaip link. Se l'interfaccia compare con la cage vuota, la scheda e il driver sono entrambi a posto ed è il cavo su cui il controllo si sta strozzando.Seconda cosa che vale la pena sapere: quel DAC HP si collega da qualche altra parte? Una NIC non Intel normalmente lo accetta senza fiatare. Ed è sicuramente il cavo codificato HP, o ne hai uno generico in giro con cui confrontarlo?
Considerati fortunato a essere su un X520, dove almeno hai una leva nel driver, per quanto ballerina. Su X710 e XL710 il controllo del modulo si è spostato nel firmware, quindi
allow_unsupported_sfpnon fa assolutamente nulla per i40e. Metti un modulo non Intel in un X710-DA2 e ottieni:e lì finisce la conversazione. Da lì le opzioni sono ottiche codificate Intel, la strada comunitaria xl710-unlocker (spingere una nuova immagine NVM con l'updater di Intel, poi andare a frugare in campi a undici bit da qualche parte intorno a 0x6800-0x7000 nell'EEPROM con tool di terze parti, interamente a proprio rischio), oppure scegliere fin da subito una variante OEM: un HPE 562SFP+ è un X710 sotto, e dopo aggiornamenti di firmware e i40e ha accettato moduli in rame di terze parti 10G e 1G senza nessun trucco.
Sul discorso OEM, va nella direzione opposta per le schede X710-DA2 a marchio Dell e Lenovo: rifiutano SFP+ e DAC non approvati, e gli strumenti stessi di Intel non elencano nemmeno la scheda. Quello su cui si sono assestati in tanti è flashare sopra l'NVM Intel stock. Prima serve il driver QV dal pacchetto BootUtil completo di Intel, altrimenti le utility non parlano affatto con la scheda; l'option ROM viene sostituita prima di ogni altra cosa, e solo dopo si fa l'inventario della scheda e la si flasha:
Tra l'inventario e il flash, riduci nvmupdate.cfg alla singola voce X710 che corrisponde alla dimensione della flash SPI della scheda, 4 MB o 8 MB. Scegli la dimensione sbagliata e ti ritrovi un mattone che serve un'immagine NVM salvata e un flasher hardware per recuperarlo, quindi leggi prima l'ETrackID e sii sicuro. Firmware nella fascia 9.30-9.40 è stato segnalato funzionante dopo, e come effetto collaterale la gente ha guadagnato SR-IOV sulle schede Lenovo. Io lo proverei comunque solo su una scheda che potrei permettermi di perdere.
Attenzione a puntare le strade del crossflash e del patching EEPROM su questo thread, perché nessuna delle due aiuta la situazione descritta. Modificare il flag OEM in un EEPROM X520 richiede prima di tutto un'interfaccia funzionante attraverso cui raggiungere la scheda, e qui non c'è nessuna interfaccia finché il cavo non esce dalla cage. Quella è una soluzione per una porta che esiste e rifiuta un modulo, non per un driver che abortisce al caricamento.
L'altra cosa che non sopravvaluterei è il test in un'altra NIC. Un modulo che si collega in un host diverso dimostra il modulo, non l'host in cui lo vuoi davvero usare. Ho moduli in rame Ubiquiti UACC-CM-RJ45-MG che girano tranquillamente in un CCR2004 e in un Intel X520-DA2 sotto Debian, e nelle cage SFP+ di un CRS309 e di un CRS328 non si collegano mai, con autonegoziazione attiva o con la velocità fissata a mano. La dipendenza dall'host è reale, quindi verifica sulla macchina esatta prima di comprarne una scorta di qualsiasi cosa.