Turris Omnia ghim Luleey LL-XS2510 XPON stick ở 1000baseX, ethtool không bao giờ đưa ra 2.5G
WAN quang của mình chạy vào một Turris Omnia, và đã chuyển từ hộp ISP sang một XPON stick để bớt một hop. Con stick là loại 2.5G, cage của Omnia chạy được 2.5G, mà mọi thứ vẫn cứ dừng ở 1G.
- Turris Omnia, Turris OS 7.0.2 HBS, kernel 5.15.148
- Luleey LL-XS2510 XPON SFP, dựa trên RTL960x, họ DFP-34X-2C2
- link kết thúc ở eth2, bản thân dịch vụ vẫn chạy bình thường
mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
Link is Up - 1Gbps/Full
ethtool eth2 không bao giờ liệt kê mode 2500baseX, tập supported và advertised dừng lại ở 1000baseX/Full, nên ngay từ đầu chẳng có gì để mà chọn.
Đã thử:
- reboot với stick đã cắm sẵn, và cold start với WAN đồng rút ra
flash set LAN_SDS_MODE 6bên trong module, rồi reboot cả hai phía, không đổi gì- đọc từng dòng output của ethtool tìm xem có gì ép được tốc độ không
Đây là module giấu khả năng 2.5G của nó, hay host từ chối đưa ra mode đó? Và có cách nào thoát khỏi chuyện này mà không phải kết thúc bằng việc tự viết lại stick không?
Comments 6
Đăng đầy đủ output của
ethtool eth2và các dòng sfp trong dmesg, không chỉ mỗi thông báo link. Phần đáng chú ý là host đã quyết định module có khả năng gì: nếu phylink chốt ở inband/1000base-x, nó lấy điều đó từ chính EEPROM của module, và không gì cấu hình trên router sẽ thêm được một mode mà driver chưa từng thấy.Cage trên Omnia vẫn ổn tới 2.5G, nên phần cứng không phải thứ đang giới hạn ở đây. Cũng nói luôn là gần đây có gì thay đổi trên host không, kể cả upgrade image.
dmesg, giống hệt nhau mỗi lần boot:
ethtool eth2cho ra 1000baseX/Full ở cả tập supported lẫn advertised, và Link detected: yes ở 1000Mb/s full duplex. Không có gì trên 1G xuất hiện ở bất kỳ đâu trong output.flash set LAN_SDS_MODE 6trên stick vẫn chạy qua được và sống sót qua một lần reboot module, nhưng phía host hoàn toàn không phản ứng gì: vẫn thông báo đó, vẫn 1G. Router vẫn ở đúng image này từ lúc lắp stick vào, nên chẳng có gì để roll back về.Đó là host tin lời module nói. Driver sfp đọc EEPROM, thấy một part khai báo 1000base-x, và ghim eth2 vào inband/1000base-x; phylink lúc đó không có mode 2.5G nào để đưa ra, đúng y như output ethtool bạn đã đăng. Cái bạn set bên trong RTL960x bằng LAN_SDS_MODE chạm vào serdes riêng của module, không phải thứ nó quảng bá cho router, nên nó chưa bao giờ có khả năng đổi được mode đã thương lượng.
Có hai lối thoát, và chỉ biết đúng hai cái đó thôi. Một là viết lại EEPROM của module để nó quảng bá 2.5G, đó là mẹo đã biết trên DFP-34X-2C3, nhưng của bạn là bản 2C2 và không nên giả định cùng offset. Hai là patch host: thêm một quirk cho module này vào sfp.c rồi chạy một kernel có nó, để nguyên stick không đụng tới.
Cân đối lại thì tôi sẽ chọn patch host. Một EEPROM bị brick trên một stick không dễ reflash là một buổi chiều tệ hơn nhiều so với một kernel có thể roll back được.
Thêm một lý do để nghi ngờ host hơn là module. Trên các bản snapshot của OpenWrt từng có giai đoạn code generic phylink validate được backport làm hỏng hẳn cage SFP của Omnia: ethtool vẫn quảng bá 2500baseX/Full nhưng port chỉ báo Link detected: no. Bisect ra đúng ngay commit kernel đó, bỏ bản backport thì link quay lại ở 2500Mb/s full duplex, và một bản fix theo sau đã đóng vấn đề này lại.
Triệu chứng khác của bạn, nhưng cùng một bài học. Trên board dùng mvneta và phylink, phần mềm host quyết định cage được phép làm gì, và nên giữ một image biết chắc là tốt để lùi về trước khi bắt đầu tự build của riêng mình.
Nếu đi theo hướng tự build kernel trên Turris OS, chụp snapshot trước đã:
schnapps create "Before new kernel", rồiopkg install --force-reinstall /srv/kernel_5.15.148-1_arm_cortex-a9_vfpv3-d16.ipkvà reboot. Nếu kernel có vấn đề gì thì roll back thay vì tháo tung router ra.Điều thứ hai không ai nhắc tới cho tới sau này: một link 2.5 Gbps không phải là 2.5 Gbps traffic. CPU Armada trên Omnia sẽ không đẩy được mức đó trên một queue duy nhất, nên hãy tính trước tới packet steering và tuning RPS trước khi con số trên dây biến thành throughput thật.
Bẫy không liên quan cho ai đọc bài này với một stick khác: một số module PON chạy hệ điều hành riêng của nó và cần khoảng một phút mới trả lời, nên lúc cold boot router probe cage quá sớm và rơi về magnetics đồng.
fw_setenv bootdelay 60trong U-Boot là cách chữa thường dùng. Không phải trường hợp của bạn, vì module của bạn được detect ngay lập tức.Chốt lại: hướng patch host thắng. Build một kernel với sfp.c đã sửa, chụp snapshot schnapps trước, cài ipk bằng
--force-reinstallrồi reboot.ethtool eth2giờ liệt kê 2500baseX/Full và link lên ở 2.5 Gbps.Cuối cùng không phải làm gì với module cả. LAN_SDS_MODE vẫn giữ nguyên như cũ và hóa ra chẳng liên quan gì, nên chưa bao giờ phải đụng tới EEPROM.
Throughput thì cần thêm lời khuyên thứ hai nữa. Ngay sau khi reboot, hộp máy chạy dưới hẳn tốc độ link trên một queue duy nhất; sau khi tune packet steering thì WAN cuối cùng cũng làm đúng việc mà con stick được mua để làm.