Dell M14MK SFP28 refused on OpenWrt with no common interface modes while a QSFPTEK SFP+ links
Small home lab. I flashed a Linksys LGS328C over to OpenWrt SNAPSHOT to get away from the stock web interface. Everything survived the move except one SFP28 port that used to work perfectly well.
- switch: Linksys LGS328C (Realtek rtl930x), OpenWrt SNAPSHOT
- module: Dell S28-10G-25G-SR-85C, dual-rate 10G/25G, EEPROM reads DELL M14MK rev A1
- reference module in the same cage: QSFPTEK QT-SFP+-SR
- same fibre and same far end in both tests
The Dell module is detected and then thrown straight out:
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: noThings I checked already:
- swapped in the QSFPTEK SFP+ in the same cage: the log shows the port picking inband/10gbase-r, and I get a clean 10 Gbps link;
- the same Dell module ran fine on this switch under the stock firmware, so the optic is not dead;
- reseated it and cleaned the connector, no change in the log.
Is the module actually mis-programmed, or is the switch driver being picky about a 25G-capable part? I would rather understand this one than just buy another optic.
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
That dump explains the whole thing. The kernel's sfp layer has exactly one input when it works out which interface modes a module can run, and that is those compliance bytes. With none of them set it ends up with an empty set, intersects that with what the MAC offers, gets nothing in common, and prints exactly the message you are looking at. The 10000baseCR/Full in ethtool is what is left over from the port side, not something the module asked for. Stock vendor firmware does not care, because thsoe images generally skip the compliance bytes altogether and match vendor and part strings against a hardcoded list instead - that is why the optic worked before you flashed.
The fix that actually holds is a module quirk. In drivers/net/phy/sfp.c add an SFP_QUIRK_S entry that matches vendor DELL with part M14MK and force-sets ETHTOOL_LINK_MODE_10000baseSR_Full and PHY_INTERFACE_MODE_10GBASER, then rebuild the image. The port comes up as an ordinary 10G link reporting 10000baseSR/Full and the unsupported-module line disappears from the log.
Two caveats. Keep the patch in a shape you can send to netdev instead of sitting on it downstream: the EEPROM is not going to fix itself and other people own the same Dell part. And if you would rather not maintain a kernel build at all, the boring alternative is the QSFPTEK SFP+ you already havve - 10G is all this port is going to give you anyway.
Before you blame the switch driver, dump the EEPROM and look at what the module declares:
ethtool --module-info lan28. Post the first rows of the hex dump plus the fullethtool lan28. "no common interface modes" means the kernel could not derive a single usable moode from the module, so the contents of thse bytes are the whole story here.One more thing to confirm: is the QSFPTEK sitting in the same cage, not a neighbouring one? Your log line says p49 while the ethtool output is lan28, and mixing up ports in this kind of test wastes a lot of time.
Dumped it. Short version: there is no 10G compliance coode set at all - those bytes are simply empty, while the vendor and part strings are populated exactly as you would expect for a DELL M14MK rev A1.
ethtool lan28still showsAdvertised link modes: 10000baseCR/FullandLink detected: no, anddmesg | grep lan25turns up nothing beyond the two lines from my first post.So the module tells the host almost nothing about what it can actually do, and the QSFPTEK in the same cage is still linking at 10 Gbps.
Worth writing down, because the earlier bug report on this exact pairing guessed differently. The theory there was that the dual-rate module advertises 25gbase-r, the rtl930x driver does not implement that mode, the intersection comes out empty and nothing is wrong with the module itself. The hex dump kills that explanation: the module advertises nothing, not 25G. Same kernel message, different cause, and only the dump tells the two apart.
It is also a reminder that a vendor-branded optic is not automatically coded correctly. Dell's own OS10 will show a genuine Q28-128GFC-SW4 (part KP0VM) as QSFP28 100GBASE-SR4 with Qualified false, because some batches carry EEPROM coding its media qualification does not recognise, and the FC link stays down until you allow unsupported transceivers by hand.
Built an image with the SFP_QUIRK_S entry for DELL / M14MK and it does exactly what you described. The port links at 10 Gbps,
ethtool lan28now reports 10000baseSR/Full with the link up, and the log is clean - no unsupported-module line anywhere. Left it running with real traffic for a few days before touching anything else on the box, no flaps.Cleaning the patch up now to send to netdev, since keeping it in my own tree helps nobody. Thanks for pushing me at the module-info dump first, I had been reading the driver mode tables for two evenings.