Dell M14MK SFP28 geweigerd op OpenWrt met no common interface modes terwijl een QSFPTEK SFP+ linkt
Klein thuislab. Ik heb een Linksys LGS328C naar OpenWrt SNAPSHOT geflasht om van de standaard webinterface af te zijn. Alles overleefde de overstap behalve één SFP28-poort die vroeger prima werkte.
- switch: Linksys LGS328C (Realtek rtl930x), OpenWrt SNAPSHOT
- module: Dell S28-10G-25G-SR-85C, dual-rate 10G/25G, EEPROM leest DELL M14MK rev A1
- referentiemodule in dezelfde cage: QSFPTEK QT-SFP+-SR
- dezelfde vezel en dezelfde andere kant bij beide tests
De Dell-module wordt gedetecteerd en meteen weer buiten de deur gezet:
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: noDingen die ik al gecontroleerd heb:
- de QSFPTEK SFP+ in dezelfde cage gezet: het log toont dat de poort inband/10gbase-r kiest, en ik krijg een schone 10 Gbps-link;
- dezelfde Dell-module draaide prima op deze switch onder de standaardfirmware, dus de optiek is niet dood;
- opnieuw geplaatst en de connector schoongemaakt, geen verandering in het log.
Is de module daadwerkelijk verkeerd geprogrammeerd, of is de switchdriver kieskeurig over een 25G-capabel onderdeel? Ik begrijp dit liever dan gewoon nog een optiek te kopen.
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
Die dump verklaart het hele verhaal. De sfp-laag van de kernel heeft precies één invoer wanneer hij uitrekent welke interfacemodi een module kan draaien, en dat zijn die compliance-bytes. Staat daarvan niets gezet, dan komt hij uit op een lege set, snijdt die met wat de MAC aanbiedt, krijgt niets gemeenschappelijk, en print precies de melding die je ziet. De 10000baseCR/Full in ethtool is wat er van de poortkant overblijft, niet iets waar de module om vroeg. Standaard vendorfirmware trekt zich er niets van aan, want die images slaan de compliance-bytes doorgaans helemaal over en matchen in plaats daarvan vendor- en partstrings tegen een hardgecodeerde lijst: dat is waarom de optiek werkte voordat je flashte.
De fix die daadwerkelijk standhoudt is een module-quirk. Voeg in drivers/net/phy/sfp.c een SFP_QUIRK_S-item toe dat matcht op vendor DELL met part M14MK en forceer ETHTOOL_LINK_MODE_10000baseSR_Full en PHY_INTERFACE_MODE_10GBASER, herbouw dan de image. De poort komt op als een gewone 10G-link die 10000baseSR/Full rapporteert en de unsupported-module-regel verdwijnt uit het log.
Twee kanttekeningen. Houd de patch in een vorm die je naar netdev kunt sturen in plaats van hem downstream te laten zitten: de EEPROM gaat zichzelf niet repareren en anderen hebben hetzelfde Dell-onderdeel. En als je liever helemaal geen kernelbuild onderhoudt, is het saaie alternatief de QSFPTEK SFP+ die je al hebt: 10G is toch alles wat deze poort je gaat geven.
Voordat je de switchdriver de schuld geeft, dump eerst de EEPROM en kijk wat de module declareert:
ethtool --module-info lan28. Post de eerste rijen van de hexdump plus de volledigeethtool lan28. "no common interface modes" betekent dat de kernel geen enkele bruikbare modus uit de module kon afleiden, dus de inhoud van die bytes is hier het hele verhaal.Nog iets om te bevestigen: zit de QSFPTEK in dezelfde cage, niet een buurcage? Jouw logregel zegt p49 terwijl de ethtool-output lan28 is, en poorten door elkaar halen bij dit soort tests kost veel tijd.
Gedumpt. Korte versie: er is helemaal geen 10G-compliance-code gezet: die bytes zijn gewoon leeg, terwijl de vendor- en partstrings gevuld zijn precies zoals je zou verwachten voor een DELL M14MK rev A1.
ethtool lan28toont nog steedsAdvertised link modes: 10000baseCR/FullenLink detected: no, endmesg | grep lan25levert niets op behalve de twee regels uit mijn eerste post.De module vertelt de host dus bijna niets over wat hij daadwerkelijk kan, en de QSFPTEK in dezelfde cage linkt nog steeds op 10 Gbps.
Het is de moeite waard om dit vast te leggen, want het eerdere bugreport over precies deze combinatie gokte anders. De theorie daar was dat de dual-rate module 25gbase-r adverteert, de rtl930x-driver die modus niet implementeert, de doorsnede leeg uitkomt en er niets mis is met de module zelf. De hexdump maakt die verklaring onderuit: de module adverteert niets, geen 25G. Dezelfde kernelmelding, andere oorzaak, en alleen de dump onderscheidt de twee.
Het is ook een herinnering dat een optiek met vendormerk niet automatisch correct gecodeerd is. Dells eigen OS10 toont een echte Q28-128GFC-SW4 (part KP0VM) als QSFP28 100GBASE-SR4 met Qualified false, omdat sommige batches EEPROM-codering dragen die de mediakwalificatie niet herkent, en de FC-link blijft down totdat je met de hand niet-ondersteunde transceivers toestaat.
Een image gebouwd met het SFP_QUIRK_S-item voor DELL / M14MK en het doet precies wat je beschreef. De poort linkt op 10 Gbps,
ethtool lan28rapporteert nu 10000baseSR/Full met de link up, en het log is schoon: nergens een unsupported-module-regel. Een paar dagen met echt verkeer laten draaien voordat ik verder nog iets aan de doos aanraakte, geen flaps.De patch nu aan het opschonen om naar netdev te sturen, want hem in mijn eigen tree houden helpt niemand. Bedankt dat je me eerst naar de module-info-dump stuurde, ik had al twee avonden in de drivermodustabellen zitten lezen.