[DSM 7.4] RTL8157 5GbE adapter disconnects after reboot/power-off and iPerf3 limited to 3.5Gbps on DS920+

[scatt6]

Environment

• NAS Model: Synology DS920+
• Architecture: Geminilake
• DSM Version: DSM 7.4
• Driver Version: r8152-geminilake-2.21.4-1_7.3.spk (running on DSM 7.4)
• Hardware/Chipset: Ubiquiti USB-C 5GbE Ethernet adapter (Realtek RTL8157)

Description of the Issue

I am experiencing two separate issues when using the RTL8157 5GbE adapter on DSM 7.4 with the current DSM 7.3 driver package:

1. Connection loss after Power-off / Reboot:
   Every time the NAS is powered off or rebooted, it completely loses the 5 Gbps connection (the adapter is dropped/not recognized by DSM 7.4 upon boot).

• Temporary Workaround: The connection can only be restored if I either restart the NAS again or physically unplug and replug the Ethernet cable from the adapter.

2. Performance Limitation:
   When the connection is active, iPerf3 tests consistently plateau at 3.53 Gbps instead of reaching closer to the 4.5 - 4.9 Gbps limit. It seems that the hardware offloading features might not be fully functional or utilized under the DSM 7.4 compatibility layer using the older 7.3 SPK architecture.

Steps to Reproduce

1. Install r8152-geminilake-2.21.4-1_7.3.spk on DSM 7.4.
2. Power off or reboot the Synology DS920+.
3. Observe that the 5GbE link is down after boot.
4. Re-plug the Ethernet cable -> Link comes back up.
5. Run iperf3 -c [IP] -P 4 (or -P 8) -> Bandwidth is capped at ~3.53 Gbits/sec.

Expected Behavior

• The RTL8157 adapter should remain persistent and automatically initialize upon system boot/reboot under DSM 7.4 without needing a physical cable reconnect.
• iPerf3 throughput should achieve higher speeds closer to the 5 Gbps line rate.

Are there plans to release a dedicated DSM 7.4 compiled .spk package for Geminilake to resolve these compatibility and performance limitations? Thank you for your amazing work on this driver!

[drego85]

Hi @scatt6, thanks for the detailed report.

We are currently reviewing the repository and the DSM 7.4 changes to understand whether a dedicated 7.4 build is possible and whether this is only a packaging/kernel-target issue or also a runtime initialization issue.

Could you please share a few additional diagnostics from the DS920+ running DSM 7.4?

uname -a
cat /etc/VERSION
cat /etc.defaults/VERSION
cat /proc/version
lsmod | grep -E 'r8152|usbnet|mii'
dmesg | grep -iE 'r8152|rtl|8157|usb|xhci|eth'
lsusb
ifconfig -a
ip link

After a reboot where the adapter does not come back automatically, please also collect:

sudo synosystemctl status pkgctl-r8152
sudo /var/packages/r8152/scripts/start-stop-status status
sudo tail -n 200 /var/packages/r8152/var/log/start-stop-status.log
dmesg | tail -n 200

The key thing we need to confirm is whether DSM 7.4 changed the kernel/module ABI for Geminilake, the package startup timing, or the USB/network initialization flow after reboot. If it is only a build-target mismatch, a DSM 7.4 SPK may be enough. If the device is enumerated but the interface is not brought up correctly, the fix may need to be in the package scripts rather than the driver itself.

[scatt6]

Hi, here are the requested diagnostics from my DS920+ running DSM 7.4 (Geminilake) with the RTL8157 adapter.

Part 1: Initial Diagnostics

=== SYSTEM DATA ===
Linux SubNas 4.4.302+ #90075 SMP Sun Jun 14 23:09:46 CST 2026 x86_64 GNU/Linux synology_geminilake_920+
buildnumber="90075"
productversion="7.4"

=== MODULES ===
r8152                 311739  0
usbcore               209065  11 uas,etxhci_hcd,r8152,usblp,uhci_hcd,usb_storage,ehci_hcd,ehci_pci,usbhid,xhci_hcd,xhci_pci

=== USB ===
|__usb2          1d6b:0003:0404 09  3.00 5000MBit/s 0mA 1IF  (Linux 4.4.302+ xhci-hcd xHCI Host Controller 0000:00:15.0) hub
  |__2-2         0bda:8157:3000 00  3.20 5000MBit/s 544mA 1IF  (UBIQUITI 5G Ethernet Adapter 000300242715CA1A)

=== NETWORK ===
eth2      Link encap:Ethernet  HWaddr 00:24:27:15:CA:1A
          inet addr:192.168.0.28  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1

Key finding in dmesg (Unbind behavior on DSM 7.4)

Looking at the boot logs, the kernel successfully enumerates the RTL8157 adapter as eth2 at timestamp [80.597]:

[   80.301130] r8152: module verification failed: signature and/or required key missing - tainting kernel
[   80.437478] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd
[   80.597056] r8152 2-2:1.0 eth2: v2.21.4 (2025/10/28)
[   80.620040] r8152 2-2:1.0 eth2: chip rev 17

However, right before that, DSM 7.4 executes a Starting unbind USB device... sequence at [53.965]:

[   53.395782] systemd[1]: Created slice r8152's slice.
[   53.405996] systemd[1]: Starting r8152's slice.
[   53.965605] systemd[1]: Starting unbind USB device...
[   54.143302] systemd[1]: Started unbind USB device.

Part 2: Package Status after Reboot (Link Down)

Note: synosystemctl status threw a usage help error because the syntax requires --status or similar in this version of DSM 7.4 toolset. Here is the manual package manager script output instead:

sudo /var/packages/r8152/scripts/start-stop-status status

Output showed the interface fails to persist automatically until a cable hotplug occurs.

It seems DSM 7.4 changed the initialization order or added an aggressive USB unbind rule during systemd loading that specifically targets non-storage external network devices before the 7.3 SPK architecture can lock the interface persistence.

Let me know if you need me to test a modified script or a fresh DSM 7.4 test build!

[drego85]

Hi @scatt6, thanks, this is very useful.

A first observation: the module itself appears to load on DSM 7.4, and the adapter is enumerated correctly:

Linux SubNas 4.4.302+ #90075 ... synology_geminilake_920+
r8152 2-2:1.0 eth2: v2.21.4
0bda:8157:3000 ... USB 3.20 5000MBit/s

So this does not currently look like a kernel ABI mismatch. It looks more like a boot/hotplug/network initialization problem.

The Starting unbind USB device... line is interesting, but since it happens at [53.x] and the r8152 driver binds successfully later at [80.x], we should not assume yet that this is the direct cause. We need to compare the exact failed
state before any cable replug or second reboot.

Could you please run these commands immediately after a boot where the adapter is not working, before unplugging/replugging anything?

  date
  dmesg | grep -iE 'r8152|8157|0bda|usb 2-2|unbind|eth2|link'
  lsusb
  lsmod | grep -E 'r8152|usbnet|mii'
  ifconfig -a
  ip link show eth2
  cat /sys/class/net/eth2/operstate
  cat /sys/class/net/eth2/carrier
  synonet --show
  ls -l /usr/lib/udev/rules.d/*r8152* /usr/lib/udev/rules.d/*realtek* 2>/dev/null
  tail -n 300 /var/packages/r8152/var/log/start-stop-status.log

Then, still without touching the cable, please test which software action recovers the adapter:

  sudo /var/packages/r8152/scripts/start-stop-status reload eth2

If that does not recover it:

  sudo ifconfig eth2 down
  sudo ifconfig eth2 up

If that still does not recover it:

  sudo rmmod r8152
  sudo /var/packages/r8152/scripts/start-stop-status start

Please report which one, if any, makes the adapter appear and work again.

This distinction matters:

• if start-stop-status reload eth2 fixes it, the likely fix is in the package startup/udev flow;
• if ifconfig down/up fixes it, the interface exists but is not being brought up correctly after DSM 7.4 boot;
• if only unloading/reloading r8152 fixes it, the issue is likely in driver bind/init timing;
• if only physical replug fixes it, then we need to look deeper at USB reset/configuration handling.

Thanks again. This already narrows the DSM 7.4 issue down quite a bit.

[scatt6]

Hi @bb-qq, thank you for the detailed breakdown!

I have an update regarding the reproduction of the issue. I realized that the automatic disconnection / drop after reboot only occurs under a very specific condition: when the built-in Gigabit LAN1/LAN2 ports of the DS920+ are completely unplugged (no cable connected).

Recently, I connected a permanent Ethernet cable to the built-in LAN1 port for Wake-on-LAN (WOL) purposes. Since doing this, the 5Gbps RTL8157 adapter initializes perfectly 100% of the time after every reboot or power-off. It is properly assigned to eth2 and never drops anymore.

It seems this is a timing/initialization race condition in DSM 7.4:

• If no built-in LAN cables are connected, the DSM network subsystem initialization flow likely struggles or times out before the USB r8152 driver finishes binding, leading to the failed state.
• If at least one built-in LAN link is active during boot, the network stack initializes successfully, allowing the USB 5GbE adapter to mount properly later in the boot sequence.

Since my link is currently stable due to the LAN1 cable workaround, I cannot easily collect the failed dmesg states right now without disabling my WOL setup. However, this clearly indicates that the issue lies within the package startup/udev timing flow rather than a driver kernel issue.

I hope this hint helps optimize the startup scripts for a future DSM 7.4 optimized build!