Turris Omnia trava um stick XPON Luleey LL-XS2510 em 1000baseX, e o ethtool nunca oferece 2.5G

Poste a saída completa do ethtool eth2 e as linhas de sfp do dmesg, não só a mensagem de link. A parte interessante é o que o host decidiu que o módulo é capaz de fazer: se o phylink se estabeleceu em inband/1000base-x, ele tirou isso da própria EEPROM do módulo, e nada que você configurar no roteador vai adicionar um modo que o driver nunca viu.

A gaiola do Omnia está bem até 2.5G, então o hardware não é o que está te limitando aqui. Diga também se algo mudou no host recentemente, incluindo upgrade de imagem.

dmesg, idêntico em todo boot:

mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
Link is Up - 1Gbps/Full

ethtool eth2 dá 1000baseX/Full tanto no conjunto supported quanto no advertised, e Link detected: yes a 1000Mb/s full duplex. Nada acima de 1G aparece em lugar nenhum na saída.

flash set LAN_SDS_MODE 6 no stick passa sim e sobrevive a um reboot do módulo, mas o lado host não reage a isso em nada: mesma mensagem, mesmo 1G. O roteador está nessa imagem desde que o stick entrou, então não tem para onde voltar.

Isso é o host tomando a palavra do módulo como verdade. O driver sfp lê a EEPROM, vê uma peça que declara 1000base-x, e trava a eth2 em inband/1000base-x; o phylink então não tem modo 2.5G para oferecer, que é exatamente a saída do ethtool que você postou. O que você ajusta dentro do RTL960x com LAN_SDS_MODE mexe no serdes do próprio módulo, não no que ele anuncia para o roteador, então isso nunca ia mudar o modo negociado.

Duas saídas, e só conheço essas duas. Ou reescreve a EEPROM do módulo para ele anunciar 2.5G, que é o truque conhecido na DFP-34X-2C3, mas a sua é uma 2C2 e eu não presumiria os mesmos offsets. Ou faz patch no host: adiciona uma exceção para esse módulo no sfp.c e roda um kernel com isso, deixando o stick intocado.

No geral eu faria patch no host. Uma EEPROM zoada num stick que você não consegue regravar fácil é uma tarde bem pior do que um kernel que dá para reverter.

Outro motivo para manter o host sob suspeita, em vez do módulo. Nos snapshots do OpenWrt houve uma fase em que o código genérico de validação do phylink, trazido por backport, quebrou de vez a gaiola SFP do Omnia: o ethtool continuava anunciando 2500baseX/Full, e a porta só reportava Link detected: no. Foi isolado com bisect direto até aquele commit do kernel, remover o backport trouxe o link de volta a 2500Mb/s full duplex, e uma correção posterior fechou o caso.

Sintoma diferente do seu, mesma lição. Em placas mvneta e phylink, o software do host decide o que a gaiola pode fazer, e vale a pena manter uma imagem sabidamente boa para recorrer antes de começar a construir a sua própria.

Se você for mesmo pelo caminho do kernel personalizado no Turris OS, tire um snapshot primeiro: schnapps create "Before new kernel", depois opkg install --force-reinstall /srv/kernel_5.15.148-1_arm_cortex-a9_vfpv3-d16.ipk e reboot. Se o kernel se comportar mal, você reverte em vez de desmontar o roteador.

A segunda coisa que ninguém menciona até acontecer: um link de 2,5 Gbps não é 2,5 Gbps de tráfego. A CPU Armada do Omnia não vai empurrar isso numa fila só, então planeje packet steering e ajuste de RPS antes de o número no fio virar throughput.

Uma armadilha à parte para quem mais estiver lendo isso com um stick diferente: alguns módulos PON rodam o próprio sistema operacional e precisam de uns bons sessenta segundos antes de responder qualquer coisa, então num cold boot o roteador sonda a gaiola cedo demais e volta para os magnéticos de cobre. fw_setenv bootdelay 60 no U-Boot é a cura de sempre. Não é o seu caso, já que seu módulo é detectado na hora.

Fechando o ciclo: o host com patch venceu. Compilei um kernel com o sfp.c modificado, tirei o snapshot do schnapps primeiro, instalei o ipk com --force-reinstall e reiniciei. ethtool eth2 agora lista 2500baseX/Full, e o link sobe a 2,5 Gbps.

Nada foi feito no módulo no final. O LAN_SDS_MODE ficou como estava e acabou sendo irrelevante, então nunca precisei tocar na EEPROM.

O throughput precisou do segundo conselho também. Logo depois do reboot a caixa ficava bem abaixo da taxa do link numa fila só; com o packet steering ajustado, a WAN finalmente faz o que o stick foi comprado para fazer.