--- date: 2026-05-26 topic: NAS r8152 드라이버 v2.20.1-1 → v2.21.4-1 업그레이드 — LPM 재발 대응 + spk_su 설치 절차 함정 areas: [infra/data/nas-storage] tags: [history, nas, r8152, synology, usb, driver, lpm] --- # 2026-05-26 / NAS r8152 v2.21.4-1 업그레이드 ## 배경 5/20 NAS eth2 카드 물리 교체(rev 17 → 14) 후 4일 만에 LPM disconnect 재발 ([[../infra/data/nas-storage#nas-eth2-usb-nic-watchdog-2026-04-14|nas-storage]] 참조). 시간당 ~1회 빈도. watchdog가 자동 복구해 서비스 영향 0이지만 빈도가 높아 드라이버 업그레이드로 LPM 처리 개선 시도. | 항목 | Before | After | |---|---|---| | 드라이버 | r8152 v2.20.1 (2025-05-13) | **r8152 v2.21.4 (2025-10-28)** | | Synology 패키지 | r8152-braswell-2.20.1-1 | r8152-braswell-2.21.4-1_7.3 | | 출처 | bb-qq/r8152 (Synology community) | 동일 | ## 설치 절차의 함정 — spk_su bb-qq 패키지는 DSM 7 release에서 **첫 install이 의도적으로 실패**한다. postinst 스크립트가 `/opt/sbin/spk_su` (setuid root) 호출을 시도하는데, 이건 패키지가 자체 번들로 제공하면서 수동 install을 요구하는 부트스트랩 도구. README 명시: > The installation will fail the first time. After that, run the following command from the SSH terminal: > ``` > sudo install -m 4755 -o root -D /var/packages/r8152/target/r8152/spk_su /opt/sbin/spk_su > ``` 즉 표준 절차: 1. SPK install → postinst가 spk_su 부재로 fail → 패키지 broken 상태 2. SPK 내부의 spk_su를 `/opt/sbin/`으로 manual 설치 3. SPK 재install → 이번엔 postinst 성공 → 패키지 정상화 **처음에 우리가 spk_su 단계를 모르고 진행해서** 시간이 추가로 들었음. 첫 install 직후 eth2가 사라지고(모듈 unload), broken 상태에서 start도 불가. 임시 복구는 `insmod /volume1/@appstore/r8152/r8152/r8152.ko` 직접 호출 + `ifconfig eth2 ... up`로 가능. ## 실제 수행한 복구 + 정상화 순서 ```bash # 1. 첫 install 실패 후 긴급 복구 sudo insmod /volume1/@appstore/r8152/r8152/r8152.ko sudo ifconfig eth2 192.168.205.100 netmask 255.255.255.0 mtu 9000 up # 2. spk_su 설치 (bb-qq README) sudo install -m 4755 -o root -D /var/packages/r8152/target/r8152/spk_su /opt/sbin/spk_su # 3. SPK 재install curl -sSL -o /tmp/r8152.spk 'https://github.com/bb-qq/r8152/releases/download/2.21.4-1/r8152-braswell-2.21.4-1_7.3.spk' sudo rm -f /var/packages/r8152/startFailed /var/packages/r8152/installing sudo /usr/syno/bin/synopkg install /tmp/r8152.spk # 모든 script code=0 SUCCESS # 4. 우리가 수동 insmod한 모듈을 unload해야 패키지 start의 insmod가 충돌 안 함 sudo rmmod r8152 sudo /usr/syno/bin/synopkg start r8152 # status=running # 5. eth2 MTU 9000 재설정 (패키지 start는 DSM ifcfg-eth2 기준이라 MTU 1500으로 올라옴) sudo ifconfig eth2 mtu 9000 ``` ## 검증 ``` $ sudo /usr/syno/bin/synopkg status r8152 status: running $ ethtool -i eth2 driver: r8152 version: v2.21.4 (2025/10/28) $ ifconfig eth2 | head -4 eth2 UP BROADCAST RUNNING MULTICAST MTU:9000 inet addr:192.168.205.100 ... $ sudo ping -c 2 -M do -s 8972 -I eth2 192.168.205.135 2 packets transmitted, 2 received, 0% packet loss rtt avg = 0.458 ms # end-to-end JF 통과 ``` ## 새 드라이버에서 변경된 점 bb-qq 2.21.4-1 release notes: - Fix transmit queue timeout (PR #609) - Realtek base code 2.21.4 업데이트 - `tx-copybreak` ethtool 옵션 추가 - TX flow-control 개선 - 마이크로코드 minor 업데이트 LPM 관련 fix는 명시 안 됨. 다만 base code 갱신에 LPM 처리 변화가 포함됐을 가능성. **효과 검증은 LPM 발화 빈도로 며칠 관찰 필요.** ## 한계 - r8152 모듈 파라미터는 DSM 3.10 커널이 sysfs `/sys/module/r8152/parameters/`에 노출하지 않음 → LPM 옵션 modparam으로 제어 불가 - DSM의 `usbcore.autosuspend` 모듈 옵션도 커널 컴파일 옵션이라 비활성. `/usr/local/etc/rc.d/usb-no-suspend.sh` 스타트업 스크립트는 sysfs `power/control`, `power/autosuspend` 파일 부재로 실효 없음 (확인 2026-05-26) - 즉 LPM 제어는 드라이버 코드 내부에서만 가능하며, 호스트 측 회피 수단이 거의 봉쇄됨 ## 교훈 + 후속 작업 - **bb-qq r8152 SPK는 첫 install fail이 정상**. spk_su manual install이 표준 절차. 다음 업그레이드 시 시간 낭비 없도록 기억. - LPM 발화 빈도를 며칠(2~3일) 관찰. 줄지 않으면 다음 옵션: - 다른 칩셋 USB NIC (ASIX AX88179)로 교체 - Thunderbolt/PCIe 2.5G 어댑터로 전환 (DS916+ 확장 슬롯 검토) - spk_su `/opt/sbin/spk_su`는 영구 설치됨 — 다음 r8152 SPK 업그레이드부터는 첫 install이 바로 성공할 것 ## 참조 - [[../infra/data/nas-storage|nas-storage 정본]] - [[2026-04-14-nas-eth2-watchdog|watchdog 구축 — 2026-04-14]] (간접) - [[2026-05-20-nas-eth2-replacement|카드 물리 교체 — 2026-05-20]] - bb-qq 패키지: - 2.21.4-1 release: