Turris Omnia가 Luleey LL-XS2510 XPON 스틱을 1000baseX에 고정, ethtool에 2.5G가 안 나옴
광 WAN이 Turris Omnia로 들어오는데, 홉을 하나 줄이려고 ISP 박스 대신 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전체 출력이랑 dmesg의 sfp 관련 줄도 올려주세요. 흥미로운 부분은 호스트가 이 모듈의 능력을 뭐라고 판단했느냐예요: phylink가 inband/1000base-x로 정착했다면 그건 모듈 자체 EEPROM에서 가져온 거고, 라우터에서 뭘 설정하든 드라이버가 한 번도 못 본 모드를 추가해주지는 않아요.Omnia의 케이지는 2.5G까지 멀쩡하니까, 여기서 제한을 거는 건 하드웨어가 아니에요. 최근 호스트 쪽에서 뭔가 바뀐 게 있는지도 말씀해주세요, 이미지 업그레이드 포함해서요.
dmesg는 부팅마다 똑같아요:
ethtool eth2는 supported랑 advertised 세트 둘 다 1000baseX/Full로 주고, Link detected: yes에 1000Mb/s 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에 이 모듈용 quirk를 추가하고 그걸 넣은 커널을 돌리면서 스틱은 그대로 두는 거예요.
저라면 전체적으로 호스트 패치 쪽을 택할 거예요. 쉽게 재플래시할 수 없는 스틱의 EEPROM을 벽돌로 만드는 것보다는 롤백 가능한 커널 쪽이 훨씬 덜 골치 아파요.
모듈보다 호스트를 의심해야 할 이유가 하나 더 있어요. OpenWrt 스냅샷에서는 한동안 백포트된 범용 phylink validate 코드가 Omnia SFP 케이지를 아예 망가뜨린 시기가 있었어요: ethtool은 여전히 2500baseX/Full을 광고하는데 포트는 그냥 Link detected: no만 나왔죠. 그 커널 커밋까지 깔끔하게 bisect됐고, 백포트를 빼니 링크가 2500Mb/s 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.5Gbps 링크가 곧 2.5Gbps 트래픽은 아니에요. Omnia의 Armada CPU는 단일 큐로는 그걸 못 밀어붙이니까, 회선상의 숫자가 실제 처리량이 되기 전에 패킷 스티어링이랑 RPS 튜닝을 계획해두세요.
다른 스틱으로 이 글 읽는 분들한테는 무관한 함정 하나: PON 모듈 일부는 자기만의 운영체제를 돌려서 응답하기까지 1분 정도 걸려요, 그래서 콜드부트에서는 라우터가 너무 일찍 케이지를 찔러보고 구리 마그네틱스로 폴백해버려요. U-Boot의
fw_setenv bootdelay 60이 보통 쓰는 해결책이에요. 이 경우는 아니시겠지만요, 모듈이 바로 인식되고 있으니까요.마무리 보고: 호스트 패치 쪽이 이겼어요. 수정된 sfp.c로 커널을 빌드하고, 먼저 schnapps 스냅샷을 뜨고,
--force-reinstall로 ipk를 설치하고 재부팅했어요. 이제ethtool eth2에 2500baseX/Full이 나오고 링크가 2.5Gbps로 올라와요.결국 모듈에는 아무것도 안 했어요. LAN_SDS_MODE는 그대로 뒀는데 상관없는 걸로 밝혀졌고, 그래서 EEPROM은 건드릴 필요가 없었어요.
처리량 쪽은 두 번째 조언도 필요했어요. 재부팅 직후에는 단일 큐 때문에 링크 속도보다 한참 아래였는데, 패킷 스티어링을 튜닝하니까 드디어 WAN이 스틱을 산 목적대로 동작해요.