Intel X520 num R630 rejeita um SFP+ de cobre 10GBASE-T com comp_codes_10g=0x00 apesar do allow_unsupported_sfp=1
Estamos consolidando um par de R630 em 10G e o cabeamento até o topo do rack é cobre, então em vez de puxar fibra coloquei módulos SFP+ 10GBASE-T nas placas X520. Do lado do switch eles são aceitos sem pestanejar. Os servidores recusam.
- Dell PowerEdge R630, Intel X520 (82599), dual port
- FS SFP-10GM-T-30, codificado Dell, um módulo por servidor
- ixgbe fora da árvore da Intel, compilado via DKMS
- /etc/modprobe.d/ixgbe.conf com o override setado para as duas portas
# 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=0x00O que já tentei:
modprobe ixgbe allow_unsupported_sfp=1na mão, além da entrada no modprobe.d- reconstruí o initramfs e dei cold boot na máquina, não só um reload de módulo
- movi o módulo para a segunda porta e depois para o segundo servidor, mesmo resultado
A parte interessante é esse byte de compliance: o módulo não reporta nada para 10G. O driver testa isso antes mesmo de olhar para o override, e tem algo a fazer além de comprar óptica com a codificação certa?
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
Você não está brigando com uma whitelist, está brigando com a ordem das checagens.
O SFF-8472 não tem bit de compliance para 10GBASE-T. Simplesmente não existe code point para isso, então um SFP+ de cobre honesto reporta códigos de compliance de 10G todos zerados, que é exatamente o seu
comp_codes_10g=0x00. O ixgbe lê esse byte, não acha nada que reconheça como módulo de 10G e desiste ali mesmo, antes de chegar perto do overrideallow_unsupported_sfp. É por isso que a flag funciona bem para um módulo óptico não qualificado ou um DAC e não faz absolutamente nada pelos seus de cobre.Existe um patch da comunidade contra o ixgbe fora da árvore da Intel que move essa checagem de compliance: quando o administrador setou explicitamente
allow_unsupported_sfp=1, um módulo que reporta códigos de compliance de 10G todos zerados é classificado como SR em vez de ser descartado logo cedo. Foi submetido upstream e continua sem merge, então você aplica na mão sobre a fonte do DKMS e mantém isso junto com sua build. Quem escreveu relatou 10 Gb/s full duplex num par de servidores depois disso, e outra pessoa confirmou que o mesmo patch faz módulos de cobre HLX-SFPX funcionarem num X520.Duas ressalvas antes de fazer isso. Uma óptica que a Intel não qualificou fica fora da garantia de compatibilidade deles, então isso vira problema seu, não deles. E o PHY do 10GBASE-T é uma peça quente - numa baia de servidor sem fluxo de ar próprio ela vai ficar bem acima de qualquer óptica no slot vizinho, então fique de olho na temperatura do módulo assim que o link subir.
Duas coisas para fechar antes de sair aplicando patch em qualquer coisa.
Primeiro, imprime o parâmetro como o kernel realmente vê ele,
/sys/module/ixgbe/parameters/allow_unsupported_sfp, numa máquina que passou por um cold boot e não só um reload de módulo. Se isso não retornar exatamente o que está no seu arquivo de conf, alguma coisa está carregando o driver antes da sua config entrar em ação e o resto da depuração é desperdício.Segundo, qual ixgbe está carregado? O
ethtool -inão adianta nada enquanto o driver nunca termina de carregar e as interfaces estão ausentes, então posta o que omodinfo ixgbereporta e a versão do pacote DKMS que você compilou.E de onde vem esse
comp_codes_10g=0x00- isso é o driver te dizendo, ou você mesmo fez o dump do EEPROM do módulo?O parâmetro é
1,1no arquivo e o/sys/module/ixgbe/parameters/allow_unsupported_sfpretorna1,1depois de um cold boot, então está aplicado, não sendo ignorado silenciosamente. O initramfs foi reconstruído antes do boot. Mesma linha no dmesg de qualquer jeito.Os códigos de compliance eu li direto dos dados SFF-8472 do próprio módulo, não do driver - o byte de compliance de 10G é zero, todo o resto nos campos de ID parece normal. O mesmo módulo na porta do switch linka em 10G, então não é um módulo morto.
Vale acrescentar do lado prático: com DKMS toda atualização de kernel reconstrói a partir das fontes em disco, então o patch tem que morar naquela árvore de fontes, não num diretório de build que você limpou depois. Confere se a porta volta depois do primeiro salto de kernel em vez de descobrir isso numa janela de reboot.
A lição mais ampla desse tipo de problema é que a safra do driver decide mais do que a codificação do módulo. Mesma história num X710 com um DAC passivo: um cabo, uma porta, feliz no Ubuntu 24.04 e morto no TrueNAS SCALE com
Link detected: noeSpeed: Unknown, porque essa build carregava o i40e do kernel 6.6.44-production. No 25.04-BETA.1, onde o i40e vem do 6.12.9-production, o twinax subiu sozinho - nada mais foi mexido, placa ainda no firmware 9.20. A óptica funcionava bem nessa porta nos dois sistemas, o que confirmou a falha em como o driver mais antigo lida com cobre passivo.ethtool -idos dois lados da comparação teria economizado muita troca de cabo.Tipo de módulo diferente, mesmo driver, e uma armadilha que vale descartar já que você está nisso. Dell R720 com uma daughter card X520, módulos Cisco 10G multimodo LC recusados, interfaces simplesmente ausentes. A opção estava no modprobe.d, estava no GRUB também, e nada mudou - porque o host dá boot via EFI e aquela linha de comando do GRUB nunca era usada.
Num Proxmox com boot EFI o parâmetro pertence a
/etc/kernel/cmdlinecomoixgbe.allow_unsupported_sfp=1, seguido depve-efiboot-tool refresh. Nesse caso nem isso resolveu e acabaram comprando módulos da própria Intel, então trata isso como algo para descartar, não como uma cura.A outra coisa dessa bagunça: os dois lados têm que ficar satisfeitos com a óptica de forma independente. Um módulo que o switch aceita ainda pode ser rejeitado pelo host, que é onde você já está.
Apliquei o patch na fonte do DKMS e reconstruí. As duas portas sobem em 10 Gb/s full duplex e continuam de pé sob carga desde então.
Funcionando, mas eu não diria que está resolvido. É um patch sem merge que agora carrego em cada atualização de kernel, e o driver apresenta a porta como SR, o que vai confundir quem olhar essa caixa depois de mim. O módulo também roda visivelmente mais quente que as ópticas no slot ao lado, e esse slot não tem fluxo de ar que preste. Para o próximo lote de servidores vou puxar fibra e parar de discutir com o driver.