Dell M14MK SFP28 recusado no OpenWrt com no common interface modes enquanto um QSFPTEK SFP+ linka
Laboratório caseiro pequeno. Fiz o flash de um Linksys LGS328C para OpenWrt SNAPSHOT para fugir da interface web de fábrica. Tudo sobreviveu à mudança, exceto uma porta SFP28 que costumava funcionar perfeitamente.
- switch: Linksys LGS328C (Realtek rtl930x), OpenWrt SNAPSHOT
- módulo: Dell S28-10G-25G-SR-85C, taxa dupla 10G/25G, a EEPROM lê DELL M14MK rev A1
- módulo de referência na mesma gaiola: QSFPTEK QT-SFP+-SR
- mesma fibra e mesma outra ponta nos dois testes
O módulo Dell é detectado e depois jogado fora na hora:
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: noCoisas que já checei:
- troquei pelo SFP+ QSFPTEK na mesma gaiola: o log mostra a porta escolhendo inband/10gbase-r, e eu ganho um link 10 Gbps limpo;
- o mesmo módulo Dell rodava bem nesse switch sob o firmware de fábrica, então a óptica não está morta;
- reencaixei e limpei o conector, nenhuma mudança no log.
O módulo está realmente mal programado, ou o driver do switch está sendo exigente com uma peça capaz de 25G? Eu preferia entender isso a só comprar outra óptica.
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
Esse dump explica tudo. A camada sfp do kernel tem exatamente uma entrada quando calcula quais modos de interface um módulo pode rodar, e são esses bytes de compliance. Com nenhum deles setado, ela acaba com um conjunto vazio, cruza isso com o que a MAC oferece, não sobra nada em comum, e imprime exatamente a mensagem que você está vendo. O 10000baseCR/Full no ethtool é o que sobrou do lado da porta, não algo que o módulo pediu. O firmware de fábrica do fabricante não se importa, porque essas imagens geralmente pulam os bytes de compliance completamente e batem as strings de vendor e part contra uma lista fixa no código - é por isso que a óptica funcionava antes do seu flash.
A correção que realmente se sustenta é um quirk de módulo. No drivers/net/phy/sfp.c, adicione uma entrada SFP_QUIRK_S que combine com vendor DELL e part M14MK e force ETHTOOL_LINK_MODE_10000baseSR_Full e PHY_INTERFACE_MODE_10GBASER, depois reconstrua a imagem. A porta sobe como um link 10G comum reportando 10000baseSR/Full e a linha de unsupported-module some do log.
Duas ressalvas. Mantenha o patch num formato que você possa mandar para o netdev em vez de guardar ele rio abaixo: a EEPROM não vai se corrigir sozinha e outras pessoas têm essa mesma peça Dell. E se você preferir não manter um build de kernel de jeito nenhum, a alternativa chata é o SFP+ QSFPTEK que você já tem - 10G é tudo que essa porta vai te dar mesmo.
Antes de culpar o driver do switch, dê um dump na EEPROM e veja o que o módulo declara:
ethtool --module-info lan28. Poste as primeiras linhas do hex dump mais oethtool lan28completo. "no common interface modes" significa que o kernel não conseguiu derivar um único modo utilizável a partir do módulo, então o conteúdo desses bytes é a história toda aqui.Mais uma coisa para confirmar: o QSFPTEK está sentado na mesma gaiola, não numa vizinha? Sua linha de log diz p49 enquanto a saída do ethtool é lan28, e misturar portas nesse tipo de teste desperdiça bastante tempo.
Fiz o dump. Versão curta: não tem nenhum código de compliance 10G setado - esses bytes estão simplesmente vazios, enquanto as strings de vendor e part estão preenchidas exatamente como se esperaria para um DELL M14MK rev A1.
ethtool lan28ainda mostraAdvertised link modes: 10000baseCR/FulleLink detected: no, edmesg | grep lan25não traz nada além das duas linhas do meu primeiro post.Então o módulo não diz quase nada ao host sobre o que ele realmente consegue fazer, e o QSFPTEK na mesma gaiola continua linkando a 10 Gbps.
Vale registrar, porque o relato de bug anterior nesse exato emparelhamento chutou diferente. A teoria de lá era que o módulo de taxa dupla anuncia 25gbase-r, o driver rtl930x não implementa esse modo, a interseção sai vazia e não tem nada de errado com o módulo em si. O hex dump mata essa explicação: o módulo não anuncia nada, nem 25G. Mesma mensagem de kernel, causa diferente, e só o dump distingue as duas.
Também é um lembrete de que uma óptica de marca do fabricante não vem automaticamente codificada corretamente. O próprio OS10 da Dell mostra um Q28-128GFC-SW4 genuíno (peça KP0VM) como QSFP28 100GBASE-SR4 com Qualified false, porque alguns lotes carregam codificação de EEPROM que a qualificação de mídia dele não reconhece, e o link FC fica caído até você permitir transceptores não suportados na mão.
Construí uma imagem com a entrada SFP_QUIRK_S para DELL / M14MK e faz exatamente o que você descreveu. A porta linka a 10 Gbps,
ethtool lan28agora reporta 10000baseSR/Full com o link up, e o log está limpo - nenhuma linha de unsupported-module em lugar nenhum. Deixei rodando com tráfego real por alguns dias antes de mexer em mais alguma coisa na caixa, nenhum flap.Agora estou limpando o patch para mandar para o netdev, já que mantê-lo só na minha árvore não ajuda ninguém. Valeu por me empurrar para o dump do module-info primeiro, eu já tinha passado duas noites lendo as tabelas de modo do driver.