Original thread:
You may recall from there that @Darksky did a testing kernel for me to play with, pulling the version of the driver that ships compiled into the kernel and replacing it with the one at AUR (en) - r8125-dkms .
This worked at the time, on a Rev. 1.1 Raspberry Pi 4B (4 GB), but absolutely refused to work when an external USB NVME SSD was plugged in. The whole system locked up and crashed. @Darksky experienced the same issue.
I’ve got a Rev Raspberry Pi 4B Rev. 1.4 (8GB) now, installed in a DeskPi and booting off a 2.5" SATA SSD on some sort of board that’s included with the DeskPi. (The DeskPi includes boards to: move ports around, provide full sized HDMI, provide a USB-to-SATA link for SSDs, and some other stuff, and has its own power delivery system.)
tl;dr: Some combination of the updated Raspberry Pi 4b board revision, using a SATA SSD instead of an NVME (and a different bridge chip to connect the SATA disk to the USB 3 bus), and whatever the DeskPi’s power delivery system is, is allowing the Sabrent adapter to work now, using the testing kernel and kernel module @Darksky prepared.
I left it running overnight, and the system was doing just fine when I came back. I haven’t tested it more thoroughly than that, but this is further than I ever got before with it. There’s still an issue on reboot (see below).
Here’s what ethtool
says about it. It seems to be auto-negotiating full duplex 2.5G without a problem.
Settings for enp1s0u2:
Supported ports: [ MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 2500Mb/s
Duplex: Full
Auto-negotiation: on
Port: MII
PHYAD: 32
Transceiver: internal
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00007fff (32767)
drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol
Link detected: yes
Known Issues:
- The Pi can’t see the USB adapter on reboot. The link and activity lights on the adapter are both frozen in the on position, like it’s stuck doing something. Unplugging the adapter from its USB port and plugging it back in fixes the problem, then it seems rock solid: at the very least, it doesn’t randomly freeze the system after staying on overnight.
- The upstream version of the driver in the AUR has updated to 2.15.x. I’m not sure if there might be something useful in the latest version, as far as addressing the reboot issue. I haven’t found a changelog yet.
Here’s what happens when it’s unplugged and plugged back in, according to dmesg
:
[Sun Nov 21 14:41:33 2021] usb 1-1.4: USB disconnect, device number 3
[Sun Nov 21 14:41:50 2021] usb 2-2: USB disconnect, device number 3
[Sun Nov 21 14:41:55 2021] usb 2-2: new SuperSpeed Gen 1 USB device number 4 using xhci_hcd
[Sun Nov 21 14:41:55 2021] usb 2-2: New USB device found, idVendor=0bda, idProduct=8156, bcdDevice=30.00
[Sun Nov 21 14:41:55 2021] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[Sun Nov 21 14:41:55 2021] usb 2-2: Product: USB 10/100/1G/2.5G LAN
[Sun Nov 21 14:41:55 2021] usb 2-2: Manufacturer: Realtek
[Sun Nov 21 14:41:55 2021] usb 2-2: SerialNumber: 000000001
[Sun Nov 21 14:41:55 2021] usbcore: registered new interface driver cdc_ether
[Sun Nov 21 14:41:55 2021] usbcore: registered new interface driver cdc_ncm
[Sun Nov 21 14:41:55 2021] usbcore: registered new interface driver cdc_wdm
[Sun Nov 21 14:41:55 2021] usbcore: registered new interface driver cdc_mbim
[Sun Nov 21 14:41:55 2021] r8152: loading out-of-tree module taints kernel.
[Sun Nov 21 14:41:55 2021] usb 2-2: reset SuperSpeed Gen 1 USB device number 4 using xhci_hcd
[Sun Nov 21 14:41:56 2021] r8152 2-2:1.0 (unnamed net_device) (uninitialized): netif_napi_add() called with weight 256
[Sun Nov 21 14:41:56 2021] r8152 2-2:1.0 eth1: v2.14.0 (2020/09/24)
[Sun Nov 21 14:41:56 2021] r8152 2-2:1.0 eth1: This product is covered by one or more of the following patents:
US6,570,884, US6,115,776, and US6,327,625.
[Sun Nov 21 14:41:56 2021] usbcore: registered new interface driver r8152
[Sun Nov 21 14:41:56 2021] r8152 2-2:1.0 enp1s0u2: renamed from eth1
[Sun Nov 21 14:42:00 2021] IPv6: ADDRCONF(NETDEV_CHANGE): enp1s0u2: link becomes ready
[Sun Nov 21 14:42:00 2021] r8152 2-2:1.0 enp1s0u2: carrier on
Question: Is there any way to automate resetting the device in software, so I don’t have to manually unplug it every time?
EDIT: Here’s lsusb
output, on boot before unplugging it, and immediately after unplugging it and plugging it back in.
~]$ lsusb
Bus 002 Device 003: ID 0bda:8151 Realtek Semiconductor Corp. RTL8151 Adapteon Business Mobile Networks BV
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
~]$ lsusb
Bus 002 Device 004: ID 0bda:8156 Realtek Semiconductor Corp. USB 10/100/1G/2.5G LAN
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
So, it’s being improperly identified as an RTL8151 on boot. This seems similar to the issue here: [SOLVED] [RTL8151] Ethernet not working via multiport adapter
There’s a little bit of storage on device, that has drivers on it so you can enable the thing on Windows or a Mac. I’m guessing that is the root cause of the needs to be unplugged/re-plugged issue. There’s a proposed solution in the linked thread above involving udev
rules, but I barely understand those at this point, so I’ll need to do some testing.