OpenWrt에서 Dell M14MK SFP28은 no common interface modes로 거부되는데 QSFPTEK SFP+는 링크됨
작은 홈랩이에요. 순정 웹 인터페이스에서 벗어나려고 Linksys LGS328C를 OpenWrt SNAPSHOT으로 플래시했어요. 예전엔 완전히 멀쩡하게 잘 되던 SFP28 포트 하나만 빼고 나머지는 다 무사히 넘어갔어요.
- 스위치: Linksys LGS328C (Realtek rtl930x), OpenWrt SNAPSHOT
- 모듈: Dell S28-10G-25G-SR-85C, 10G/25G 듀얼레이트, EEPROM에는 DELL M14MK rev A1로 나옴
- 같은 케이지에 넣어본 비교 모듈: QSFPTEK QT-SFP+-SR
- 두 테스트 다 같은 광케이블, 같은 반대편 장비
Dell 모듈은 인식은 되는데 바로 튕겨나가요:
sfp sfp-p49: module DELL M14MK rev A1
rtl83xx-switch ...: unsupported SFP module: no common interface modes
# ethtool lan28
Advertised link modes: 10000baseCR/Full
Link detected: no이미 확인해본 것:
- 같은 케이지에 QSFPTEK SFP+로 바꿔 꽂아봤어요: 로그에는 포트가 inband/10gbase-r을 고르는 걸로 나오고, 깨끗하게 10Gbps 링크가 떠요
- 같은 Dell 모듈이 순정 펌웨어에서는 이 스위치에서 멀쩡하게 됐으니까 광부품이 죽은 건 아니에요
- 다시 꽂고 커넥터도 청소해봤는데 로그에 변화 없어요
이 모듈이 실제로 잘못 프로그래밍된 걸까요, 아니면 스위치 드라이버가 25G 지원 부품에 유난히 까다로운 걸까요? 그냥 다른 광모듈을 사기보다는 이걸 제대로 이해하고 싶어요.
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 5
그 덤프가 전부 설명해주네요. 커널의 sfp 레이어가 모듈이 어떤 인터페이스 모드를 쓸 수 있는지 판단할 때 보는 입력값은 딱 하나, 그 compliance 바이트들이에요. 그게 하나도 세팅 안 돼 있으면 빈 집합이 나오고, 그걸 MAC이 제공하는 모드랑 교집합을 내면 공통점이 하나도 없어서, 지금 보시는 그 메시지가 정확히 그대로 찍히는 거예요. ethtool의 10000baseCR/Full은 모듈이 요청한 게 아니라 포트 쪽에 남아 있던 값이고요. 순정 벤더 펌웨어는 이런 걸 신경 안 쓰는데, 그런 이미지들은 보통 compliance 바이트를 아예 건너뛰고 대신 벤더/파트 문자열을 하드코딩된 목록이랑 대조하기 때문이에요 - 그래서 플래시하기 전에는 그 광모듈이 잘 됐던 거고요.
실제로 유효한 해법은 module quirk예요. drivers/net/phy/sfp.c에 vendor DELL, part M14MK에 매칭되는 SFP_QUIRK_S 항목을 추가해서 ETHTOOL_LINK_MODE_10000baseSR_Full이랑 PHY_INTERFACE_MODE_10GBASER를 강제로 세팅하고, 이미지를 다시 빌드하세요. 그러면 포트가 10000baseSR/Full로 나오는 평범한 10G 링크로 올라오고, 로그에서 unsupported-module 줄도 사라져요.
주의할 점 두 가지요. 패치는 다운스트림에 그냥 묻어두지 말고 netdev에 보낼 수 있는 형태로 만들어두세요. EEPROM이 저절로 고쳐지는 것도 아니고, 같은 Dell 부품을 쓰는 다른 사람들도 있으니까요. 그리고 커널 빌드를 아예 유지보수하고 싶지 않으면, 지금 갖고 계신 QSFPTEK SFP+를 쓰는 게 무난한 대안이에요 - 어차피 이 포트에서 나오는 건 10G가 전부니까요.
스위치 드라이버 탓하기 전에, EEPROM을 덤프해서 모듈이 뭘 선언하는지 보세요:
ethtool --module-info lan28. hex 덤프 앞부분이랑 전체ethtool lan28출력을 올려주세요. "no common interface modes"는 커널이 모듈에서 쓸 수 있는 모드를 단 하나도 끌어내지 못했다는 뜻이니까, 여기서는 그 바이트들의 내용이 얘기의 전부예요.하나 더 확인할 게, QSFPTEK가 정말 같은 케이지에 있나요, 옆 케이지가 아니라요? 로그에는 p49라고 나오는데 ethtool 출력은 lan28이라서요, 이런 테스트에서 포트를 헷갈리면 시간을 많이 날리거든요.
덤프해봤어요. 짧게 말하면: 10G compliance 코드가 아예 하나도 세팅이 안 돼 있어요 - 그 바이트들은 그냥 비어 있고, vendor랑 part 문자열은 DELL M14MK rev A1에서 기대하는 그대로 채워져 있어요.
ethtool lan28은 여전히Advertised link modes: 10000baseCR/Full이랑Link detected: no로 나오고,dmesg | grep lan25도 제가 처음 올린 글의 두 줄 말고는 아무것도 안 나와요.그러니까 이 모듈은 자기가 실제로 뭘 할 수 있는지 호스트한테 거의 아무것도 안 알려주는 거고, 같은 케이지의 QSFPTEK는 여전히 10Gbps로 링크되고 있어요.
기록해둘 만한 게, 이 정확히 같은 조합에 대한 예전 버그 리포트는 다르게 추측했었거든요. 거기서는 듀얼레이트 모듈이 25gbase-r을 광고하는데 rtl930x 드라이버가 그 모드를 구현 안 해서 교집합이 비게 되고, 모듈 자체는 아무 문제 없다는 이론이었어요. 그런데 hex 덤프가 그 설명을 깨버리네요: 모듈은 25G가 아니라 아무것도 광고를 안 하고 있어요. 커널 메시지는 똑같은데 원인은 다르고, 덤프를 봐야만 둘을 구분할 수 있어요.
이건 벤더 정품 광모듈이라고 자동으로 코딩이 맞다는 보장은 없다는 것도 다시 한번 보여줘요. Dell의 OS10 자체도 정품 Q28-128GFC-SW4(part KP0VM)를 QSFP28 100GBASE-SR4로 보여주면서 Qualified false라고 표시하는 경우가 있는데, 일부 배치는 자체 media qualification이 인식 못 하는 EEPROM 코딩을 담고 있어서고, unsupported transceiver를 손으로 허용해줄 때까지 FC 링크는 계속 안 올라와요.
DELL / M14MK용 SFP_QUIRK_S 항목을 넣어서 이미지를 빌드했더니 말씀하신 그대로 되네요. 포트는 10Gbps로 링크되고,
ethtool lan28도 이제 10000baseSR/Full에 링크 업으로 나오고, 로그도 깨끗해요 - unsupported-module 줄이 어디에도 없어요. 장비 다른 부분은 건드리지 않고 실제 트래픽으로 며칠 돌려봤는데 flap도 없었어요.이제 netdev에 보내려고 패치를 정리하는 중이에요, 제 트리에만 갖고 있어봐야 아무한테도 도움이 안 되니까요. module-info 덤프부터 먼저 보라고 밀어주셔서 감사해요, 저는 이틀 저녁 내내 드라이버 모드 테이블만 읽고 있었거든요.