Turris Omnia, bir Luleey LL-XS2510 XPON stick'ini 1000baseX'e sabitliyor ve ethtool hiç 2.5G sunmuyor

Sadece link mesajını değil, tam ethtool eth2 çıktısını ve dmesg'den sfp satırlarını paylaş. İlginç olan kısım, host'un modülün neye muktedir olduğuna karar vermesi: phylink inband/1000base-x'te karar kıldıysa, bunu modülün kendi EEPROM'undan aldı, ve router'da konfigüre ettiğin hiçbir şey driver'ın hiç görmediği bir modu eklemeyecek.

Omnia'daki kafes 2.5G'ye kadar sorun değil, yani seni burada sınırlayan donanım değil. Ayrıca host'ta son zamanlarda bir şey değişti mi, bir image upgrade'i dahil, onu da söyle.

dmesg, her boot'ta aynı:

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

ethtool eth2, hem desteklenen hem de advertise edilen set olarak 1000baseX/Full veriyor, ve 1000Mb/s full duplex'te Link detected: yes. Çıktıda 1G'nin üzerinde hiçbir şey görünmüyor.

Stick üzerindeki flash set LAN_SDS_MODE 6 gerçekten geçiyor ve modülün reboot'undan sağ çıkıyor, ama host tarafı buna hiç tepki vermiyor: aynı mesaj, aynı 1G. Router, stick takıldığından beri bu image'de, yani geri dönülecek bir şey yok.

Bu, host'un modülü sözüne göre alması. sfp driver'ı EEPROM'u okuyor, 1000base-x deklare eden bir parça görüyor, ve eth2'yi inband/1000base-x'e sabitliyor; phylink'in o zaman sunacak bir 2.5G modu kalmıyor, ki bu da tam olarak paylaştığın ethtool çıktısı. RTL960x içinde LAN_SDS_MODE ile ayarladığın şey modülün kendi serdes'ine dokunuyor, router'a ne advertise ettiğine değil, yani bu zaten anlaşılan modu hiçbir zaman değiştirmeyecekti.

İki çıkış yolu var, ve sadece bu ikisini biliyorum. Ya modülün EEPROM'unu 2.5G advertise edecek şekilde yeniden yaz, ki bu DFP-34X-2C3'te bilinen numara, ama seninki bir 2C2 ve aynı offset'leri varsaymazdım. Ya da host'u patchle: sfp.c'ye bu modül için bir quirk ekle ve bununla bir kernel çalıştır, stick'e hiç dokunmadan.

Genel olarak host'u patchlerdim. Kolayca yeniden flashlayamayacağın bir stick'te tuğlalaşmış bir EEPROM, geri alabileceğin bir kernel'den çok daha kötü bir öğleden sonra.

Host'u modülden çok şüphe altında tutmak için bir neden daha. OpenWrt snapshot'larında, backport edilmiş generic phylink validate kodunun Omnia SFP kafesini doğrudan bozduğu bir dönem oldu: ethtool hâlâ 2500baseX/Full advertise ediyordu ve port sadece Link detected: no raporluyordu. Temiz bir şekilde o kernel commit'ine kadar bisect edildi, backport'u kaldırmak linki 2500Mb/s full duplex'te geri getirdi, ve sonraki bir düzeltme konuyu kapattı.

Seninkinden farklı bir belirti, aynı ders. mvneta ve phylink kartlarında host yazılımı kafesin neye izinli olduğuna karar veriyor, ve kendi image'ini oluşturmaya başlamadan önce geri dönülecek bilinen iyi bir image tutmak işe yarıyor.

Turris OS'te özel kernel yoluna gidersen, önce bir snapshot al: schnapps create "Before new kernel", sonra opkg install --force-reinstall /srv/kernel_5.15.148-1_arm_cortex-a9_vfpv3-d16.ipk ve reboot. Kernel yanlış davranırsa router'ı sökmek yerine geri dönersin.

Sonradan kadar kimsenin bahsetmediği ikinci şey: 2,5 Gbps'lik bir link, 2,5 Gbps'lik trafik demek değil. Omnia'daki Armada CPU'su bunu tek bir queue'da göndermeyecek, o yüzden hat üzerindeki rakam throughput'a dönüşmeden önce packet steering ve RPS ayarını planla.

Bunu farklı bir stick'le okuyan başkaları için ilgisiz bir tuzak: bazı PON modülleri kendi işletim sistemlerini çalıştırıyor ve hiç yanıt vermeden önce kabaca bir dakikaya ihtiyaç duyuyor, o yüzden soğuk boot'ta router kafesi çok erken yokluyor ve bakır magnetik'lere geri düşüyor. U-Boot'ta fw_setenv bootdelay 60 olağan çare. Senin durumun değil, çünkü senin modülün hemen tespit ediliyor.

Konuyu kapatalım: patch'lenmiş host kazandı. Modifiye edilmiş sfp.c ile bir kernel derledim, önce schnapps snapshot'ı aldım, ipk'yi --force-reinstall ile kurdum ve reboot ettim. ethtool eth2 artık 2500baseX/Full listeliyor ve link 2,5 Gbps'de geliyor.

Sonunda modüle hiçbir şey yapılmadı. LAN_SDS_MODE olduğu yerde kaldı ve ilgisiz olduğu ortaya çıktı, yani EEPROM'a hiç dokunmak zorunda kalmadım.

Throughput için ikinci tavsiyeye de ihtiyaç vardı. Reboot'tan hemen sonra kutu tek bir queue'da link hızının epey altında oturuyordu; packet steering ayarlandıktan sonra WAN sonunda stick'in alınma amacını yerine getiriyor.