Supermicro AOC-STGN-i1S (X520) no Proxmox 7.1: nenhuma interface no ip link com um DAC HP encaixado
Rodo uma caixa Proxmox pequena em casa e queria um caminho 10G de verdade até o nó de storage, então encaixei um Supermicro AOC-STGN-i1S usado. É o design Intel 82599 comum, placa marcada E157872, e achei que essa seria a parte chata do build. Não foi.
- Supermicro AOC-STGN-i1S, Intel X520-DA1, marcação de placa E157872
- Proxmox 7.1, kernel 5.15.30-1-pve
- DAC SFP+ passivo de marca HP para a segunda caixa
- a placa enumera direitinho no barramento PCI
O driver nunca termina de carregar. O log do kernel diz que abortou porque detectou um tipo de módulo SFP+/QSFP que não suporta, e depois disso simplesmente não tem porta para configurar:
lspci -> the X520 is listed, no complaints
ip link -> lo and the onboard 1G only, no 10G interface at all
dmesg -> ixgbe aborts loading, unsupported SFP+/QSFP module typeO que já fiz:
- criei /etc/modprobe.d/ixgbe.conf com
options ixgbe allow_unsupported_sfp=1, depoisupdate-initramfs -ue um reboot: sem mudança - passei a mesma opção como parâmetro de kernel em vez disso: sem mudança
rmmod ixgbeemodprobe ixgbena mão: continua sem nada novo emip link
A placa está morta, ou tem um jeito de passar dessa checagem num kernel 5.15 que estou deixando passar?
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
O que você descreve é exatamente a cara de esbarrar na whitelist da EEPROM no ixgbe. O driver lê o ID do módulo, decide que não está na lista aceita pela Intel e aborta antes até de registrar um netdev, e é por isso que o
lspcivê a placa e oip linknão mostra nada. Nada disso é falha de hardware, e é também por isso que a porta volta no momento em que o módulo sai da gaiola.A saída documentada é a que você já usou:
No 5.15 essa opção simplesmente não é confiável. Tive o mesmo não-resultado nesse kernel, então não adianta repetir ou caçar um erro de digitação no arquivo conf.
O que resolveu do meu lado: com a gaiola vazia a interface subia no
modprobe ixgbe, colocar o cabo HP de volta fazia ela sumir de novo, e o mesmo cabo HP linkou sem drama numa Mellanox ConnectX-2. O cabo está eletricamente bem, a Intel só não gosta de como ele é codificado.A correção que funcionou foi encaixar um DAC SFP+ genérico sem marca no lugar. Link up na hora, sem opções de módulo, sem dança de reboot. Sobre suporte: com qualquer cabo não codificado pela Intel você já está fora da matriz da Intel de qualquer forma, então se essa caixa algum dia tiver que ser suportável, compre um DAC codificado Intel em vez de um da HP.
Antes de dar a placa como perdida, rode um teste. Tire o DAC da gaiola completamente, depois
rmmod ixgbe,modprobe ixgbee olhe oip linkde novo. Se a interface aparecer com a gaiola vazia, a placa e o driver estão bem os dois e o cabo é o que está engasgando a checagem.Segunda coisa que vale saber: esse DAC HP linka em algum outro lugar? Uma NIC não-Intel normalmente aceita sem reclamar uma palavra sequer. E é com certeza o cabo codificado HP, ou você tem um genérico à mão para comparar?
Considere-se com sorte de estar num X520, onde pelo menos você tem uma chave de driver, por mais capenga que seja. No X710 e no XL710 a checagem de módulo se mudou para o firmware, então o
allow_unsupported_sfpnão faz absolutamente nada para o i40e. Coloca um módulo não-Intel num X710-DA2 e você recebe:e aí a conversa acaba. A partir daí as opções são óptica codificada Intel, o caminho comunitário do xl710-unlocker (gravar uma imagem NVM nova com o próprio updater da Intel, depois ir cutucar campos de onze bits em algum lugar perto de 0x6800-0x7000 na EEPROM com ferramentas de terceiros, totalmente por sua conta e risco), ou já escolher uma variante OEM de cara: uma HPE 562SFP+ é um X710 por baixo, e depois de atualizar firmware e i40e ela aceitou módulos de cobre de terceiros 10G e 1G sem nenhum hack.
No ângulo OEM, funciona ao contrário para placas X710-DA2 de marca Dell e Lenovo: elas rejeitam SFP+ e DAC não aprovados, e as próprias ferramentas da Intel nem listam a placa. Onde as pessoas chegaram foi gravando NVM Intel padrão nelas. Primeiro você precisa do driver QV do pacote BootUtil completo da Intel, senão as ferramentas simplesmente não conversam com a placa; a option ROM é substituída antes de qualquer outra coisa, e só depois você inventaria a placa e grava:
Entre o inventário e a gravação, reduza o nvmupdate.cfg até sobrar só a entrada X710 que bate com o tamanho da flash SPI da placa, 4 MB ou 8 MB. Escolha o tamanho errado e você tem um tijolo que precisa de uma imagem NVM salva e um flasher de hardware para recuperar, então leia o ETrackID primeiro e tenha certeza. Firmwares na faixa 9.30-9.40 foram relatados como funcionando depois disso, e as pessoas ganharam SR-IOV nas placas Lenovo como efeito colateral. Eu ainda assim só tentaria isso numa placa que eu pudesse perder sem problema.
Cuidado ao mirar as rotas de crossflash e patch de EEPROM nesse tópico, porque nenhuma das duas ajuda na situação descrita. Editar a flag de OEM numa EEPROM X520 primeiro precisa de uma interface funcionando para alcançar a placa, e aqui não tem interface nenhuma até o cabo sair da gaiola. Isso é uma correção para uma porta que existe e rejeita um módulo, não para um driver que aborta no carregamento.
A outra coisa que eu não superinterpretaria é o teste em outra NIC. Um módulo linkando num host diferente prova o módulo, não o host onde você realmente quer usá-lo. Tenho módulos de cobre Ubiquiti UACC-CM-RJ45-MG que rodam numa boa num CCR2004 e num Intel X520-DA2 sob Debian, e nas gaiolas SFP+ de um CRS309 e de um CRS328 eles nunca linkam, nem com autonegociação ligada nem com a velocidade fixada na mão. Dependência de host é real, então verifique na máquina exata antes de comprar uma pilha de qualquer coisa.