Turris Omnia mengunci stick XPON Luleey LL-XS2510 ke 1000baseX dan ethtool tidak pernah nawarin 2.5G

Post output ethtool eth2 yang lengkap dan baris sfp dari dmesg, bukan cuma pesan link-nya. Bagian yang menarik itu apa yang host-nya putuskan soal kapabilitas modulnya: kalau phylink settle di inband/1000base-x, itu diambil dari EEPROM modulnya sendiri, dan apa pun yang kamu konfigurasi di router tidak akan nambahin mode yang tidak pernah dilihat driver-nya.

Cage di Omnia-nya baik-baik saja sampai 2.5G, jadi hardware-nya bukan yang ngebatasin kamu di sini. Bilang juga apakah ada yang berubah di host-nya belakangan ini, termasuk upgrade image.

dmesg, sama persis tiap boot:

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

ethtool eth2 ngasih 1000baseX/Full sebagai set supported maupun advertised-nya, dan Link detected: yes di 1000Mb/s full duplex. Tidak ada apa pun di atas 1G yang muncul di mana pun di output-nya.

flash set LAN_SDS_MODE 6 di stick-nya memang jalan dan bertahan lewat reboot modulnya, tapi sisi host-nya sama sekali tidak bereaksi ke itu: pesan yang sama, 1G yang sama. Router-nya udah di image ini sejak stick-nya dipasang, jadi tidak ada yang bisa di-roll-back.

Itu host-nya nganggep omongan modulnya apa adanya. Driver sfp-nya baca EEPROM-nya, lihat part yang declare 1000base-x, dan ngunci eth2 ke inband/1000base-x; phylink-nya jadi tidak punya mode 2.5G buat ditawarin, yang persis output ethtool yang kamu post. Apa yang kamu set di dalam RTL960x pakai LAN_SDS_MODE nyentuh serdes modulnya sendiri, bukan apa yang dia advertise ke router-nya, jadi itu memang tidak akan pernah ngubah mode yang di-negotiate.

Dua jalan keluar, dan saya cuma tahu dua ini. Salah satunya nulis ulang EEPROM modulnya biar dia advertise 2.5G, yang itu trik yang udah dikenal di DFP-34X-2C3, tapi punya kamu itu 2C2 dan saya tidak akan asumsiin offset-nya sama. Atau patch host-nya: tambahin quirk buat modul ini di sfp.c dan jalanin kernel dengan itu, stick-nya dibiarkan tidak disentuh.

Kalau ditimbang-timbang, saya bakal patch host-nya. EEPROM yang bricked di stick yang tidak gampang di-reflash itu sore yang jauh lebih buruk daripada kernel yang bisa kamu roll back.

Alasan lain buat tetap curigain host-nya daripada modulnya. Di OpenWrt snapshot ada masa waktu kode generic phylink validate yang di-backport ngerusak cage SFP Omnia-nya langsung: ethtool tetap advertise 2500baseX/Full dan port-nya cuma lapor Link detected: no. Ini bisa dibisect dengan bersih ke commit kernel itu, drop backport-nya bikin link-nya balik di 2500Mb/s full duplex, dan fix susulan nutup itu.

Gejalanya beda dari punya kamu, pelajarannya sama. Di board mvneta dan phylink, software host-nya yang nentuin apa yang boleh dilakukan cage-nya, dan ada untungnya simpan image yang sudah terbukti bagus buat fallback sebelum kamu mulai bikin punya sendiri.

Kalau kamu emang mau ambil jalur kernel custom di Turris OS, ambil snapshot dulu: schnapps create "Before new kernel", terus opkg install --force-reinstall /srv/kernel_5.15.148-1_arm_cortex-a9_vfpv3-d16.ipk dan reboot. Kalau kernel-nya berulah, kamu roll back aja daripada bongkar router-nya.

Hal kedua yang tidak ada yang nyebutin sampai belakangan: link 2.5 Gbps itu bukan traffic 2.5 Gbps. CPU Armada di Omnia-nya tidak akan bisa dorong itu di satu queue doang, jadi rencanain packet steering dan tuning RPS sebelum angka di kabelnya berubah jadi throughput.

Trap yang tidak berkaitan buat yang lain baca ini dengan stick yang beda: sebagian modul PON jalanin operating system-nya sendiri dan butuh kira-kira satu menit sebelum mereka jawab sama sekali, jadi di cold boot, router-nya probe cage-nya kecepetan dan fallback ke magnetics copper-nya. fw_setenv bootdelay 60 di U-Boot itu obat yang biasa dipakai. Bukan kasus kamu, karena modul kamu terdeteksi langsung.

Nutup loop-nya: host yang di-patch yang menang. Build kernel dengan sfp.c yang dimodifikasi, ambil snapshot schnapps dulu, install ipk-nya pakai --force-reinstall dan reboot. ethtool eth2 sekarang nyantumin 2500baseX/Full dan link-nya naik di 2.5 Gbps.

Tidak ada yang dilakukan ke modulnya di akhir. LAN_SDS_MODE tetap di tempatnya dan ternyata tidak relevan, jadi saya tidak pernah perlu nyentuh EEPROM-nya.

Throughput-nya butuh saran kedua juga. Langsung setelah reboot, box-nya duduk jauh di bawah link rate-nya di satu queue; dengan packet steering yang di-tuning, WAN-nya akhirnya ngerjain apa yang jadi tujuan stick-nya dibeli.