M SHELL for TCRP 의 모듈로더방식 EUDEV / DDSML 의 고찰
몇일전 헤놀로지 포럼에 멜라녹스 10G 모듈이 ARPL 과 M SHELL 에서 동작이 안되지만
pocopico님의 모듈을 수동추가하면 동작이 되는 문제를 확인해 달라는 요청이 있었습니다.
ARPL 과 M SHELL 은 모듈을 통합팩으로 동일하게 사용하기 때문에 로딩방식이 동일합니다.
거기에 ARPL 이 사용하는 EUDEV 방식까지 M SHELL 에서 적용하면 완전히 동일한 로딩방식이 되며 모듈의 이상동작 현상까지도
아주 유사한 경향이 있었습니다.
리눅스 모듈이 로딩되는 방식을 어느정도 알아 두시면
왜 내 보드에서만 이 모듈(드라이버)들이 동작되지 않고 벽돌이 되는지 이해가 되실겁니다.
1. ARPL의 모듈 로딩 방식은 EUDEV입니다.
2. 오리지널 TCRP의 모듈 로딩 방식은 insmod 입니다. (모듈간 종속성은 고려하지 않음)
3. TCRP용 M SHELL의 모듈 로딩 방식은 EUDEV / DDSML(Detected Device Static Module Loading)를 선택해 사용합니다.
모듈 간 종속성을 처리하는 데 사용되는 주요 명령은 다음과 같습니다.
depmod -a (전체 모듈의 종속성 생성), [통합모듈팩을 설치한후 실행되는 명령어]
modprobe (모듈과 관련된 다른 모듈을 종속성으로 로드)
insmod (단일 모듈 로딩, 모듈간 종속성은 고려하지 않음)
리눅스 모듈인 ko 파일들은 단독모듈의 형태인 경우도 있지만,
여러개의 ko 파일들이 종속성을 가지며 서로 연결되어 있는 경우도 있습니다.
이런경우 종속성을 누락하지 않는 방법으로 모듈을 로딩하는것이 가장 좋습니다.
지금까지 ARPL 과 M SHELL 이 사용했던 EUDEV 는 이러한 종속성을 아주 스마트하게 잘 처리하는 방식으로만 생각했습니다.
ARPL fabio 님과 TCRP pocopico님 두분이 철썩같이 신뢰했던 EUDEV 가 결코 스마트 하지 않음을 최근 몇가지 사례에서 알게 되었습니다.
멜라녹스 ConnectX-3 dual sfp+ 랜카드는 mlx4_core.ko 와 mlx4_en.ko 2개 모듈을 종속관계를 가지고 사용되야 합니다.
그런데, EUDEV 에서는 이 두개 모듈의 종속관계 처리에 실패한 결과가 나왔습니다.
오히려 가장 원초적인 방식인 pocopico님의 TCRP 에서 insmod mlx4_core.ko, insmod mlx4_en.ko 으로 하나씩 모듈을 로딩처리를 하는 과정에서는 랜카드가 정상인식되고 동작되었습니다.
제가 이 멜라녹스 ConnectX-3 가 없는 관계로 문의를 주신 유저분께 종속관계처리를 하는 modprobe 를 사용하는
M SHELL 의 DDSML 방식으로 마지막 테스트를 요청드려놓은 상태입니다.
그리고, 오늘 바로 아래글인 현이들아빠님 리포팅으로 랜카드의 순서인 eth0, eth1 순서가 꼬이는 문제도 역시 EUDEV 에서만 발생하고 있음을 알았습니다. DDSML 에서는 문제가 없습니다.
EUDEV 가 어떤 이유에서인지 장치인식 이벤트에서 eth0/eth1 등의 인식순서를 뒤죽박죽 처리하고 있는듯 보였습니다.
내장랜인 r8169 eth0 + 외장랜 e1000e eth1 을 인식처리 시키는 과정에서 r8169 는 DHCP 에서 IP 를 부여받지 못하였습니다.
이 문제를 연구하는 과정에서 부수적으로 제가 누락하고 있었던 모듈 firmware가 있음을 인지했습니다.
/lib/firmware 디렉토리에 존재하며 모듈의 처리에 연관성이 있는 내용입니다.
이 펌웨어 들이 모든 모듈에 필요한것은 아니고 특정 브랜드에만 해당이 됩니다.
가장 대표적인것이 리얼텍 이 해당이 됩니다.
현재 M SHELL 의 최종 버전에서는 이 펌웨어를 포함시켜서 리얼텍 랜카드의 인식속도를 더 개선하고 오류메시지를 잡은 상태입니다.
https://github.com/PeterSuh-Q3/arpl-modules/tree/main/firmware/rtl_nic
https://github.com/PeterSuh-Q3/arpl-modules/tree/main/firmware/i915
최종적으로 M SHELL 이 가야하는 방향은 EUDEV 와 DDSML 의 하이브리드 처리가 되어야 할 것 같습니다.
DDSML 의 종속성을 고려한 modprobe 처리가 일단 EUDEV 보다 선행되고
그 이후에 EUDEV 가 미처 인식하지 못한 하드웨어들을 감지해내는 방식이 좋을것 같습니다.
위에서 ARPL 이 EUDEV 하나만 사용하고 있는것처럼 잘못 표현을 했는데,
내부적으로 어느 시점에 modprobe 처리가 되고 있는것을 ARPL 분석과정에서 최근에 알게 되었습니다.
https://github.com/fbelavenuto/arpl/search?q=modprobe
어쨌던 EUDEV 와 modprobe 를 적절히 사용을 해야 하는 부분이 관건이 될것 같구요.
위 멜라녹스 드라이버의 경우 ARPL 이 실패했다는것은 EUDEV 와 modprobe 의 처리 순서가 관계가 있지 않을까 싶습니다.
fabio 님이 2주넘게 복귀를 안하신 상태라 이부분은 돌아오시면 한번 확인해 보겠습니다.
일단 M SHELL 은 좀더 개선된 방향으로 전환을 해보겠습니다.
화정큐삼
아~ 완벽히 이해했어;
어찌 그리 잘 분석하시는지 신기하기만 합니다.
당췌 시간은 어디서 생기시는건지??
모쪼록 화이팅 입니다~
2등 오늘도 가마니 하나 늘어납니다
3등 항상 고생 많으십니다 큐삼님 저도 12000에 새로 920+ 설치했을때 eudev로 선택하고 빌드 끝나고. Dsm접속 10분 기다리는데요 처음 랜을 못잡아서 usb 초기화하고 다시 빌드하니까 랜이 50초 까지 랜을 못잡길래 뮈지 하고 아이피스케너 돌려보니 랜 잡혀길래
50초 남은거 그대로두고 크롬창 새로 뛰어서 192.168.0.39:5000치니까 dsm접속되더라구요 50초 남은건 시간다되도 dsm에 접속이 안되었고 크롬새창 뛰어서 아이피주소 5000치니까 dsm접속이 되더라구요
이후에는 재부팅해도 dsm에 접속 잘되구요
이것도 예전에는 이러지 않았던거 같은데요 이것도 관련 있을까요
12100에는 h610m-k d4 메인보드에 Realtek 8111H 사용중입니다
추가적으로 8100t 에서도 새로 설치 할떄 Realtek 8111H 사용중인데요 여기서는 그런 문제가 발생하지 않았습니다
최근에 AMD 라이젠 안정성 시험을 하면서 이보드에 r8169 칩셋이 사용된 내장랜카드가 유독 인식속도가 느리고 답답해서 안정화 방법을 계속 찾고 있었습니다. EUDEV 가 기본설정값으로 맨 앞에 노출이 되어 있어서 EUDEV 위주의 시험과 사용이 되어 왔었는데요.
조금전 M SHELL 을 수정해서 예전 사용되었던 방식인 DDSML 이 먼저 노출되도록 순서를 바꾸었습니다.
최종적인 모습은 두개를 선택하지 않게하고 하나로 병합할 생각입니다.
항상 수고가 많으십니다 큐삼님 그런 일단 DSM전부 접속잘되니 이대로 사용하다가
나중에 병합될때 까지 기다려야겠네요
펌웨어가 로딩되지 않는 경우 어떤 문제를 야기할지는 저도 잘 모르겠습니다.
찜찜하시면 로더에 현재상황 모니터링 하시고 한번 교체해 두시는것도 나쁘지 않을것 같습니다.
펌웨어가 파일 문제가 있는지 확인하는 방법은
시놀로지에 SSH로 접속하셔서 아래 커맨드로 로그를 확인해 보시기 바랍니다.
dmesg | grep -e 8168 -e 8169
펌웨어 파일이 누락된 상황에서는 아래와 같은 오류 메시지 들이 보이실겁니다.
[ 31.088425] r8169 0000:06:00.0: Direct firmware load for rtl_nic/rtl8168h-2.fw failed with error -2
[ 31.098418] r8169 0000:06:00.0: Falling back to user helper
[ 91.104401] r8169 0000:06:00.0 eth0: unable to load firmware patch rtl_nic/rtl8168h-2.fw (-11)
[ 250.731299] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
아래 로그를 보니 저도 8111H 를 사용하고 있었나 보네요.
[ 11.425100] r8169 0000:06:00.0 eth0: RTL8168h/8111h at 0xffffc900001ea000, 3c:7c:3f:24:52:45, XID 14100880 IRQ 52
이렇게 뜨네요 문제가 있는걸까요 EUDEV 빌드했습니다
이상한건 이번에 새로 설치 이후로
920+가 오늘 부팅해보니 랜 잡히고 DSM 들어가는게 예전에 비해서오래시간후에 잡히는 같네요 918+비슷한 속도 였는데요 918+는 빠릿빠릿 잡히는데 920+는 느리게 잡히는거 같네요
깔끔하게 일단 안된면 재설치 해봐야겠네요 920+는 ssd하나랑 n m.2 한개씩있어서 하드까지 전부 포멧하고 설치 해봐야겠네요
기존 920+ USb 만든거는 EUDEV 세팅하고 설치후부터 이상하게 자꾸 랜이 너무 느리게 잡혀서
화정큐삼님 말대로 초기화후에 새로 설치해보았습니다
USb 초기화후에 USB새로 920+ DDSML 빌드해서 설치후에 하드 초기화 안한상태에서 DSM접속후 복구하고 DSM에 접속해보니 설치시 랜잡히는 속도및 재부팅후 랜잡히는 속도가 진짜 빠르게 랜이잡혀서 DSM에 접속되네요 아이피:5000 해두면 거희 바로 잡힐정도로 DSM이 빠르게 잡히네요
918+ 경우는 전혀 문제가 없어서 이번에 새로운 USB에 918+ EUDEV 빌드해서 설치했는데 이것도 초기화 하고 새로 설치해야하는건지 고민중이네요
이번에 DDSML로 빌드해서 새로만든 USB는 화정큐삼님 말대로 SSH
접속해서 dmesg | grep -e 8168 -e 8169 해보니
이전에 설치했 EUDEV 설치했을떄와 다르게 DDSML 설치했더니 아래처럼 에러 하나도 안뜨고
잘설치 되었네요 감사합니다 화정큐삼님
네, r8168/r8169 에서 접속속도가 확실히 개선된것 같아 보입니다. ^^
로그에 보시면 31 ~ 250 사이에 타임아웃으로 잡히기 까지의 딜레이가 좀 있습니다.
이 과정이 랜카드 인식속도를 떨어뜨린것 같습니다.
[ 31.088425] r8169 0000:06:00.0: Direct firmware load for rtl_nic/rtl8168h-2.fw failed with error -2
[ 250.731299] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
항상 감사할 따름입니다.. :)
큐삼님은 직업이 it 관련이신지요?
늘 도움 받고있습니다. 감사합니다.
엇 그럼 랜포트 순서가 바뀌는 경우들이 말씀하신 종속처리에 문제가 있는 경우에 해당될수 있다고 봐야할까요? 사실 제 기기에서는 단순 랜포트 순서바뀐것만 그런게 아니라 종종 공유기 dhcp로 주소를 못받아 오거나 dsm에서 주소를 처리 못해서 접속이 불가능해져서 강제 재부팅을 해야하거든요;; (iptime nas200모델)
좀더 연구를 해봐야 알겠지만, 랜포트가 올라오는 로그를 보면 어떤 모듈방식을 적용하던간에
리눅스가 지가 정한 룰대로 포트번호를 지정하는것 같습니다.
로그상으로 보이는 현상으로는 딱 모듈명칭의 알파벳순(e1000e, r8169) 으로 올리는것 같아 보이던데요.
사실 DDSML 의 경우는 레드필에 개발된 별도의 모듈로딩 규칙이 있어서 이대로 동작되는데, 이게 딱 알파벳순서입니다.
EUDEV 의 경우는 지가 정한 룰대로 하는게 있다고는 하는데, 이 룰이 당췌 어떻게 돌아가는지는 모르겠지만
로그의 결과를 봐도 모듈명 알파벳 순서였습니다.
TC Linux 상에서는 r8169 (내장) eth0, e1000e (외장) eth1 으로 mac1, mac2 지정시 설정을 했는데,
시놀로지 DSM 설치단계에 진입해서는 마치 이게 뒤바뀌는듯한 현상이 확인이 되었습니다.
e1000e (외장) eth0, r8169 (내장) eth1
하지만 결국에는 TC 에서 맨처음 보였던 순서대로 다시 자리를 잡습니다.
DDSML 의 경우는 다시 제자리를 잡는 과정에서 IP 부여를 둘다 정확히 받아오는데,
EUDEV 의 경우는 그렇지 못했습니다. 내장랜인 r8169 가 IP를 못받습니다.
현재의 M SHELL for TCRP 는 DDSML+EUDEV 형태로 어제 재 배포 되었고
DDSML, EUDEV 자체도 레드필 안에서는 모듈처럼 로딩되기에 알파벳순서를 따릅니다.
그래서 DDSML 이 우선 로딩되고 그다음 EUDEV 처리가 들어갑니다.
cmt alert
신고
"님의 댓글"
이 댓글을 신고하시겠습니까?
