L'Intel X520 in un R630 rifiuta un SFP+ in rame 10GBASE-T con comp_codes_10g=0x00 nonostante allow_unsupported_sfp=1
Stiamo consolidando una coppia di R630 su 10G e il cablaggio verso la sommità del rack è in rame, quindi invece di tirare fibra ho messo moduli SFP+ 10GBASE-T nelle schede X520. Il lato switch li accetta senza fiatare. I server si rifiutano.
- Dell PowerEdge R630, Intel X520 (82599), doppia porta
- FS SFP-10GM-T-30, codificati Dell, un modulo per server
- ixgbe out-of-tree di Intel, compilato tramite DKMS
- /etc/modprobe.d/ixgbe.conf con l'override impostato su entrambe le porte
# cat /etc/modprobe.d/ixgbe.conf
options ixgbe allow_unsupported_sfp=1,1
# dmesg
ixgbe: failed to load because an unsupported SFP+ module type was detected
# 10G compliance codes read back from the module
comp_codes_10g=0x00Cosa ho già provato:
modprobe ixgbe allow_unsupported_sfp=1a mano oltre alla voce in modprobe.d- ricostruito l'initramfs e riavviato a freddo la macchina, non solo un reload del modulo
- spostato il modulo sulla seconda porta e poi sul secondo server, stesso risultato
La parte interessante è quel byte di compliance: il modulo non riporta assolutamente nulla per il 10G. Il driver lo controlla prima ancora di guardare l'override, e c'è qualcosa da fare senza comprare ottiche con la codifica giusta?
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 6
Non stai combattendo contro una whitelist, stai combattendo contro l'ordine dei controlli.
SFF-8472 non ha alcun bit di compliance per il 10GBASE-T. Semplicemente non esiste un code point per quello, quindi un onesto SFP+ in rame riporta codici di compliance 10G tutti a zero, che è esattamente il tuo
comp_codes_10g=0x00. ixgbe legge quel byte, non trova nulla che riconosca come modulo 10G e rinuncia lì, prima ancora di avvicinarsi all'overrideallow_unsupported_sfp. Ecco perché il flag funziona bene per un modulo ottico non qualificato o per un DAC e non fa assolutamente nulla per i tuoi moduli in rame.Esiste una patch della community contro l'ixgbe out-of-tree di Intel che sposta il test di compliance: quando l'amministratore ha esplicitamente impostato
allow_unsupported_sfp=1, un modulo che riporta codici di compliance 10G tutti a zero viene classificato come SR invece di essere scartato subito. È stata proposta upstream ed è ancora non mergiata, quindi la applichi a mano al sorgente DKMS e la tieni insieme alla tua build. Chi l'ha scritta ha riportato 10 Gb/s full duplex su una coppia di server in seguito, e qualcun altro ha confermato che la stessa patch fa funzionare i moduli in rame HLX-SFPX in una X520.Due avvertenze prima di farlo. Un'ottica che Intel non ha qualificato è fuori dalla loro garanzia di compatibilità, quindi diventa un problema tuo, non loro. E il PHY del 10GBASE-T è un componente che scalda - in uno slot server senza un flusso d'aria proprio starà ben sopra qualsiasi ottica nello slot vicino, quindi tieni d'occhio la temperatura del modulo una volta che il link è su.
Due cose da chiarire prima di metterti a patchare qualsiasi cosa.
Primo, stampa il parametro come lo vede davvero il kernel,
/sys/module/ixgbe/parameters/allow_unsupported_sfp, su una macchina che è passata per un boot a freddo e non per un reload del modulo. Se questo non rilegge esattamente quello che sta nel tuo file di conf, qualcosa sta caricando il driver prima che la tua configurazione entri in gioco, e il resto del debug è tempo perso.Secondo, quale ixgbe è caricato?
ethtool -inon ti serve a nulla finché il driver non finisce mai di caricarsi e le interfacce sono assenti, quindi posta cosa riportamodinfo ixgbee la versione del pacchetto DKMS che hai compilato.E da dove viene quel
comp_codes_10g=0x00- te lo dice il driver, oppure hai dumpato l'EEPROM del modulo tu stesso?Il parametro nel file è
1,1e/sys/module/ixgbe/parameters/allow_unsupported_sfprilegge1,1dopo un boot a freddo, quindi è applicato, non ignorato silenziosamente. L'initramfs è stato ricostruito prima del boot. Stessa riga in dmesg in entrambi i casi.I codici di compliance li ho letti dal modulo io stesso dai dati SFF-8472, non dal driver - il byte di compliance 10G è zero, tutto il resto nei campi ID sembra sano. Lo stesso modulo nella porta dello switch fa link a 10G, quindi non è un modulo morto.
Vale la pena aggiungere sul lato pratico: con DKMS ogni aggiornamento del kernel ricompila dai sorgenti sul disco, quindi la patch deve vivere in quell'albero sorgente, non in una directory di build che poi hai ripulito. Verifica che la porta torni dopo il primo salto di kernel invece di scoprirlo durante una finestra di reboot.
La lezione più ampia da questa classe di problemi è che l'annata del driver decide più della codifica del modulo. Stessa storia su un X710 con un DAC passivo: un cavo, una porta, felice sotto Ubuntu 24.04 e morta sotto TrueNAS SCALE con
Link detected: noeSpeed: Unknown, perché quella build portava l'i40e del kernel 6.6.44-production. Sulla 25.04-BETA.1, dove l'i40e viene dal 6.12.9-production, il twinax è salito da solo, nient'altro toccato, scheda ancora sul firmware 9.20. L'ottica andava bene su quella porta sotto entrambi i sistemi, il che è ciò che ha fissato il guasto sul modo in cui il driver più vecchio gestisce il rame passivo. Unethtool -isu entrambi i lati del confronto avrebbe risparmiato un sacco di scambi di cavi.Tipo di modulo diverso, stesso driver, e una trappola che vale la pena escludere finché ci sei. Dell R720 con una daughter card X520, moduli Cisco 10G multimodali LC rifiutati, interfacce semplicemente assenti. L'opzione era in modprobe.d, era anche in GRUB, e nulla cambiava - perché l'host fa boot via EFI e quella riga di comando GRUB non veniva mai usata.
Su un Proxmox avviato via EFI il parametro va in
/etc/kernel/cmdlinecomeixgbe.allow_unsupported_sfp=1, seguito dapve-efiboot-tool refresh. In quel caso nemmeno quello ha risolto e alla fine hanno comprato moduli a marchio Intel, quindi trattalo come qualcosa da escludere piuttosto che come una cura.L'altra cosa da quel pasticcio: entrambe le estremità devono essere soddisfatte dell'ottica in modo indipendente. Un modulo che lo switch accetta può comunque essere rifiutato dall'host, che è dove ti trovi già tu.
Applicata la patch al sorgente DKMS e ricompilato. Entrambe le porte salgono a 10 Gb/s full duplex e sono rimaste su sotto carico da allora.
Funziona, ma non la chiamerei risolta. È una patch non mergiata che ora mi porto dietro a ogni aggiornamento del kernel, e il driver presenta la porta come SR, il che confonderà chiunque guardi questa macchina dopo di me. Il modulo gira anche notevolmente più caldo dell'ottica nello slot accanto e quello slot non ha un flusso d'aria degno di questo nome. Per il prossimo lotto di server tirerò fibra e la smetterò di discutere con il driver.