Dell M14MK SFP28 rifiutato su OpenWrt con no common interface modes mentre un QSFPTEK SFP+ si collega
Piccolo lab domestico. Ho flashato un Linksys LGS328C con OpenWrt SNAPSHOT per allontanarmi dall'interfaccia web stock. Tutto è sopravvissuto al passaggio tranne una porta SFP28 che prima funzionava perfettamente.
- switch: Linksys LGS328C (Realtek rtl930x), OpenWrt SNAPSHOT
- modulo: Dell S28-10G-25G-SR-85C, dual-rate 10G/25G, l'EEPROM legge DELL M14MK rev A1
- modulo di riferimento nella stessa cage: QSFPTEK QT-SFP+-SR
- stessa fibra e stesso lato remoto in entrambi i test
Il modulo Dell viene rilevato e poi buttato fuori all'istante:
sfp sfp-p49: module DELL M14MK rev A1
rtl83xx-switch ...: unsupported SFP module: no common interface modes
# ethtool lan28
Advertised link modes: 10000baseCR/Full
Link detected: noCose che ho già controllato:
- sostituito con il QSFPTEK SFP+ nella stessa cage: il log mostra la porta che sceglie inband/10gbase-r, e ottengo un link pulito a 10 Gbps;
- lo stesso modulo Dell funzionava bene su questo switch con il firmware stock, quindi l'ottica non è morta;
- riseduto e pulito il connettore, nessun cambiamento nel log.
Il modulo è davvero programmato male, oppure il driver dello switch è pignolo con un componente capace di 25G? Preferirei capire questa faccenda piuttosto che comprare semplicemente un'altra ottica.
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
Quel dump spiega tutto. Il layer sfp del kernel ha esattamente un input quando deve capire quali modalità di interfaccia un modulo può gestire, e sono quei byte di compliance. Senza nessuno di essi impostato finisce con un insieme vuoto, lo interseca con quello che offre il MAC, non trova niente in comune, e stampa esattamente il messaggio che stai guardando. Il 10000baseCR/Full in ethtool è quello che resta dal lato porta, non qualcosa che il modulo ha chiesto. Il firmware stock del vendor non se ne cura, perché quelle immagini in genere saltano del tutto i byte di compliance e confrontano invece le stringhe vendor e part contro una lista hardcoded - ecco perché l'ottica funzionava prima che flashassi.
La correzione che regge davvero è un quirk per il modulo. In drivers/net/phy/sfp.c aggiungi una voce SFP_QUIRK_S che corrisponde al vendor DELL con part M14MK e forza ETHTOOL_LINK_MODE_10000baseSR_Full e PHY_INTERFACE_MODE_10GBASER, poi ricostruisci l'immagine. La porta sale come un normale link 10G che riporta 10000baseSR/Full e la riga unsupported-module sparisce dal log.
Due avvertenze. Tieni la patch in una forma che puoi mandare a netdev invece di tenertela sotto: l'EEPROM non si aggiusta da sola e altri hanno lo stesso componente Dell. E se preferisci non mantenerti dietro una build del kernel, l'alternativa noiosa è il QSFPTEK SFP+ che hai già - 10G è comunque tutto quello che questa porta ti darà.
Prima di dare la colpa al driver dello switch, fai il dump dell'EEPROM e guarda cosa dichiara il modulo:
ethtool --module-info lan28. Posta le prime righe del dump esadecimale più l'ethtool lan28completo. "no common interface modes" significa che il kernel non è riuscito a ricavare nemmeno una modalità utilizzabile dal modulo, quindi il contenuto di questi byte è tutta la storia qui.Un'altra cosa da confermare: il QSFPTEK sta nella stessa cage, non in una vicina? La tua riga di log dice p49 mentre l'output di ethtool è lan28, e confondere le porte in questo tipo di test fa perdere un sacco di tempo.
Fatto il dump. Versione breve: non c'è impostato nessun codice di compliance 10G - quei byte sono semplicemente vuoti, mentre le stringhe vendor e part sono popolate esattamente come ci si aspetterebbe per un DELL M14MK rev A1.
ethtool lan28mostra ancoraAdvertised link modes: 10000baseCR/FulleLink detected: no, edmesg | grep lan25non tira fuori nulla oltre le due righe del mio primo post.Quindi il modulo non dice quasi niente all'host su cosa può fare davvero, e il QSFPTEK nella stessa cage sta ancora collegato a 10 Gbps.
Vale la pena scriverlo, perché il bug report precedente su questo stesso abbinamento ipotizzava qualcosa di diverso. La teoria lì era che il modulo dual-rate annuncia 25gbase-r, il driver rtl930x non implementa quella modalità, l'intersezione viene vuota e non c'è niente di sbagliato nel modulo in sé. Il dump esadecimale demolisce quella spiegazione: il modulo non annuncia nulla, non 25G. Stesso messaggio del kernel, causa diversa, e solo il dump distingue le due cose.
È anche un promemoria che un'ottica a marchio vendor non è automaticamente codificata correttamente. Lo stesso OS10 di Dell mostra un Q28-128GFC-SW4 genuino (part KP0VM) come QSFP28 100GBASE-SR4 con Qualified false, perché alcuni lotti portano una codifica EEPROM che la sua qualificazione media non riconosce, e il link FC resta giù finché non permetti a mano i transceiver non supportati.
Ho costruito un'immagine con la voce SFP_QUIRK_S per DELL / M14MK e fa esattamente quello che hai descritto. La porta si collega a 10 Gbps,
ethtool lan28ora riporta 10000baseSR/Full con il link up, e il log è pulito - nessuna riga unsupported-module da nessuna parte. L'ho lasciata girare con traffico reale per qualche giorno prima di toccare qualsiasi altra cosa sul box, nessun flap.Sto ripulendo la patch adesso per mandarla a netdev, visto che tenerla nel mio albero personale non aiuta nessuno. Grazie per avermi spinto prima verso il dump di module-info, avevo passato due sere a leggere le tabelle delle modalità del driver.