Turris Omnia фиксирует стик Luleey LL-XS2510 XPON на 1000baseX, и ethtool никогда не предлагает 2.5G
Мой волоконный WAN приходит в Turris Omnia, и я перешёл с бокса провайдера на стик XPON, чтобы убрать один хоп. Стик - деталь на 2.5G, клетка Omnia поддерживает 2.5G, а всё равно всё садится на 1G.
- Turris Omnia, Turris OS 7.0.2 HBS, ядро 5.15.148
- Luleey LL-XS2510 XPON SFP, на базе RTL960x, семейство DFP-34X-2C2
- линк заканчивается на eth2, сама услуга работает нормально
mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
Link is Up - 1Gbps/Fullethtool eth2 вообще не перечисляет режим 2500baseX, наборы supported и advertised останавливаются на 1000baseX/Full, так что мне и выбирать нечего.
Что пробовал:
- перезагрузку с уже установленным стиком и холодный старт с отключённым медным WAN
flash set LAN_SDS_MODE 6внутри модуля, затем перезагрузку обеих сторон - без изменений- построчно прочитал вывод ethtool в поисках чего-либо, что заставило бы скорость
Это модуль скрывает свою возможность 2.5G, или хост отказывается предложить этот режим? И есть ли выход, не заканчивающийся тем, что мне придётся перепрошивать сам стик?
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 6
Опубликуйте полный вывод
ethtool eth2и строки sfp из dmesg, а не только сообщение о линке. Интересная часть - что хост решил о возможностях модуля: если phylink остановился на inband/1000base-x, он взял это из собственного EEPROM модуля, и ничто из того, что вы настроите на роутере, не добавит режим, которого драйвер никогда не видел.Клетка на Omnia в порядке вплоть до 2.5G, так что железо здесь не является ограничением. Также скажите, менялось ли что-то недавно на хосте, включая обновление образа.
dmesg, одинаково при каждой загрузке:
ethtool eth2даёт 1000baseX/Full и как supported, и как advertised, и Link detected: yes на 1000 Мбит/с full duplex. Ничего выше 1G нигде в выводе не появляется.flash set LAN_SDS_MODE 6на стике действительно проходит и переживает перезагрузку модуля, но хостовая сторона на это вообще не реагирует: то же сообщение, тот же 1G. Роутер на этом образе с момента установки стика, так что откатываться некуда.Это хост принимает модуль на слово. Драйвер sfp читает EEPROM, видит деталь, объявляющую 1000base-x, и фиксирует eth2 на inband/1000base-x; у phylink после этого нет режима 2.5G, который можно было бы предложить, что ровно и есть тот вывод ethtool, который вы опубликовали. То, что вы настраиваете внутри RTL960x через LAN_SDS_MODE, затрагивает собственный serdes модуля, а не то, что он анонсирует роутеру, так что это никогда не могло изменить согласованный режим.
Есть только два известных мне выхода. Либо перепрошить EEPROM модуля так, чтобы он анонсировал 2.5G - это известный трюк на DFP-34X-2C3, но у вас 2C2, и я бы не стал предполагать те же смещения. Либо пропатчить хост: добавить исключение для этого модуля в sfp.c и запустить ядро с ним, оставив стик нетронутым.
В целом я бы патчил хост. Убитый EEPROM в стике, который непросто перепрошить заново, - куда худший вечер, чем ядро, которое можно откатить.
Ещё одна причина держать под подозрением хост, а не модуль. В снапшотах OpenWrt был период, когда бэкпортированный обобщённый код phylink validate напрямую ломал клетку SFP Omnia: ethtool всё ещё анонсировал 2500baseX/Full, а порт просто сообщал Link detected: no. Это чисто бисектировалось до конкретного коммита ядра, откат бэкпорта возвращал линк на 2500 Мбит/с full duplex, а последующий фикс закрыл проблему.
Симптом другой, чем у вас, урок тот же. На платах с mvneta и phylink именно хостовое ПО решает, что клетке разрешено делать, и стоит держать заведомо рабочий образ для отката, прежде чем начинать собирать свой собственный.
Если пойдёте по пути кастомного ядра на Turris OS, сначала сделайте снапшот:
schnapps create "Before new kernel", затемopkg install --force-reinstall /srv/kernel_5.15.148-1_arm_cortex-a9_vfpv3-d16.ipkи перезагрузка. Если ядро ведёт себя плохо, вы откатываетесь, а не разбираете роутер.Вторая вещь, которую никто не упоминает заранее: линк 2,5 Гбит/с - это ещё не 2,5 Гбит/с трафика. CPU Armada в Omnia не протолкнёт это на одной очереди, так что закладывайтесь на настройку packet steering и RPS, прежде чем цифра на проводе превратится в реальную пропускную способность.
Не относящаяся к делу ловушка для тех, кто читает это с другим стиком: некоторые модули PON запускают собственную операционную систему, и им нужна примерно минута, прежде чем они вообще ответят, так что при холодной загрузке роутер опрашивает клетку слишком рано и откатывается на медную магнитную часть.
fw_setenv bootdelay 60в U-Boot - обычное лекарство. Не ваш случай, поскольку ваш модуль распознаётся сразу же.Закрываю тему: победил пропатченный хост. Собрал ядро с изменённым sfp.c, сначала сделал снапшот schnapps, установил ipk с
--force-reinstallи перезагрузился.ethtool eth2теперь показывает 2500baseX/Full, и линк поднимается на 2,5 Гбит/с.С модулем в итоге ничего не делал. LAN_SDS_MODE остался как был и оказался неважен, так что EEPROM трогать вообще не пришлось.
Пропускной способности потребовался и второй совет. Сразу после перезагрузки устройство сидело заметно ниже скорости линка на одной очереди; после настройки packet steering WAN наконец делает то, ради чего покупался стик.