Sometimes I have found that auto negotiating causes issues. Sometimes you might have to set the speed a little lower. Sometimes I had to buy another brand of nic. This usually was due to incompatibility with the brand of the router opposed to the brand of nic. Sometimes a firmware update on the router helps. Then also there could be an issue with the module the nic uses. Networking can at times be a headache.
Aye.
I just checked their website. There are Windows/Mac/Linux drivers listed, so I’m trying the Mac drivers first to see if I can at least get it working on a computer I know is otherwise in fine working order.
This is the message the installer greets you with:
Welcome to Realtek USB NICs world…
So that seems encouraging. </ s>
@Darksky , I think I’ve figured out the problem. Maybe.
Some queries:
]$ dmesg | grep r8152 [ 1.446287] usbcore: registered new interface driver r8152 ]$ lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M |__ Port 2: Dev 4, If 0, Class=Communications, Driver=cdc_ncm, 5000M |__ Port 2: Dev 4, If 1, Class=CDC Data, Driver=cdc_ncm, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M ]$ lsusb Bus 002 Device 004: ID 0bda:8156 Realtek Semiconductor Corp. USB 10/100/1G/2.5G LAN Bus 002 Device 002: ID 152d:0583 JMicron Technology Corp. / JMicron USA Technology Corp. JMS583Gen 2 to PCIe Gen3x2 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 I successfully loaded the r8152 Realtek chipset driver. And it’s using something called cdc_ncm. I’m less clear what that is, but assume it’s part of the driver/network stack.
But! It is my understanding that this device, actually uses the Realtek r8156 chipset.
The AUR version, which does not want to install on ARM by default, specifically mentions supporting the RTL8156. I’m not sure if 2.14-1 is actually different than 2.14, but … maybe?
]$ pamac info r8152-dkms
Name : r8152-dkms
Version : 2.14-1
Description : A kernel module for Realtek RTL8152/RTL8153/RTL8154/RTL8156 Based USB Ethernet Adapters
URL : http://www.realtek.com
Licenses : GPL
Repository : AUR
Depends On : glibc dkms
Optional Dependencies : linux-headers [Installed]
linux-lts-headers
Conflicts With : r8152
Maintainer : wget
First Submitted : 09/17/2016
Last Modified : 10/23/2020
Votes : 8
Realtek themselves indicate their linux driver version 2.14 is only compatible with kernels up to 5.6: Realtek USB FE / GBE / 2.5G / Gaming Ethernet Family Controller Software - REALTEK
There’s a thread on OpenWRT’s forum about this, but it’s way over my head: 2.5G USB->Ethernet, kmod-usb-net-rtl8152? - Installing and Using OpenWrt - OpenWrt Forum
I’ve never in my life attempted to compile a kernel module, so I’m really lost where to. start with that, or how to even tell if there’s something useful to try there.
EDIT: I installed ethtool and asked it for driver info, and got this:
> ~]$ ethtool -i enp1s0u2c2
driver: cdc_ncm version: 5.11.0-3-MANJARO-ARM firmware-version: CDC NCM expansion-rom-version: bus-info: usb-0000:01:00.0-2 supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no
Is it even loading the right driver?
EDIT 2: One more bit of possibly useful troubleshooting info, here’s udevadm monitor when the NIC is plugged in:
KERNEL[5200.633854] add /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2 (usb)
KERNEL[5200.635540] add /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0 (usb)
KERNEL[5200.658000] add /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0/net/usb0 (net)
KERNEL[5200.658121] add /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0/net/usb0/queues/rx-0 (queues)
KERNEL[5200.658187] add /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0/net/usb0/queues/tx-0 (queues)
KERNEL[5200.658601] bind /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0 (usb)
KERNEL[5200.659050] add /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.1 (usb)
KERNEL[5200.659177] bind /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.1 (usb)
KERNEL[5200.659288] bind /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2 (usb)
UDEV [5201.328759] add /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2 (usb)
UDEV [5201.335527] add /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0 (usb)
UDEV [5201.339548] add /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.1 (usb)
KERNEL[5201.353403] move /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0/net/enp1s0u1u2c2 (net)
UDEV [5201.358415] bind /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.1 (usb)
UDEV [5201.421952] add /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0/net/enp1s0u1u2c2 (net)
UDEV [5201.445248] add /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0/net/usb0/queues/rx-0 (queues)
UDEV [5201.449428] add /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0/net/usb0/queues/tx-0 (queues)
UDEV [5201.454736] bind /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0 (usb)
UDEV [5201.490287] bind /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2 (usb)
UDEV [5201.498396] move /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:2.0/net/enp1s0u1u2c2 (net)Maybe you could try blacklisting the cdc_ncm driver to see if the r8152 then loads instead.
The r8152 module is being compiled, you just need to get it loaded. No need to compile a different one unless the kernel version does not work.
Something like this should work:
$ nano /etc/modprobe.d/blacklist.conf
blacklist cdc_ncm
The Arch Wiki has some more information.
I compiled the one from aur that says:
Description: A kernel module for Realtek RTL8152/RTL8153/RTL8154/RTL8156 Based USB Ethernet Adapters
And installed it and it looks a lot different.
The one in the kernel does not specify firmware for the 8156:
Summary
[ray@pi4 ~]$ modinfo r8152
name: r8152
filename: (builtin)
version: v1.11.11
license: GPL
file: drivers/net/usb/r8152
description: Realtek RTL8152/RTL8153 Based USB Ethernet Adapters
author: Realtek linux nic maintainers nic_swsd@realtek.com
firmware: rtl_nic/rtl8153b-2.fw
firmware: rtl_nic/rtl8153a-4.fw
firmware: rtl_nic/rtl8153a-3.fw
firmware: rtl_nic/rtl8153a-2.fw
The one from AUR:
Summary
[ray@vim3 r8152-dkms]$ modinfo /usr/lib/modules/5.11.1-1-MANJARO-ARM/updates/r8152.ko.gz
filename: /usr/lib/modules/5.11.1-1-MANJARO-ARM/updates/r8152.ko.gz
version: v2.14.0 (2020/09/24)
license: GPL
description: Realtek RTL8152/RTL8153 Based USB Ethernet Adapters
author: Realtek nic sw nic_swsd@realtek.com
srcversion: 76D1CDFA8C39E2E2C6F2D59
alias: usb:v13B1p0041ddcdscdpic02isc0Dip00in*
alias: usb:v13B1p0041ddcdscdpic02isc06ip00in*
alias: usb:v13B1p0041ddcdscdpicFFiscipin*
alias: usb:v0955p09FFddcdscdpic02isc0Dip00in*
alias: usb:v0955p09FFddcdscdpic02isc06ip00in*
alias: usb:v0955p09FFddcdscdpicFFiscipin*
alias: usb:v2357p0601ddcdscdpic02isc0Dip00in*
alias: usb:v2357p0601ddcdscdpic02isc06ip00in*
alias: usb:v2357p0601ddcdscdpicFFiscipin*
alias: usb:v17EFpA387ddcdscdpic02isc0Dip00in*
alias: usb:v17EFpA387ddcdscdpic02isc06ip00in*
alias: usb:v17EFpA387ddcdscdpicFFiscipin*
alias: usb:v17EFpA359ddcdscdpic02isc0Dip00in*
alias: usb:v17EFpA359ddcdscdpic02isc06ip00in*
alias: usb:v17EFpA359ddcdscdpicFFiscipin*
alias: usb:v17EFp8153ddcdscdpic02isc0Dip00in*
alias: usb:v17EFp8153ddcdscdpic02isc06ip00in*
alias: usb:v17EFp8153ddcdscdpicFFiscipin*
alias: usb:v17EFp721Eddcdscdpic02isc0Dip00in*
alias: usb:v17EFp721Eddcdscdpic02isc06ip00in*
alias: usb:v17EFp721EddcdscdpicFFiscipin*
alias: usb:v17EFp7214ddcdscdpic02isc0Dip00in*
alias: usb:v17EFp7214ddcdscdpic02isc06ip00in*
alias: usb:v17EFp7214ddcdscdpicFFiscipin*
alias: usb:v17EFp720Cddcdscdpic02isc0Dip00in*
alias: usb:v17EFp720Cddcdscdpic02isc06ip00in*
alias: usb:v17EFp720CddcdscdpicFFiscipin*
alias: usb:v17EFp720Bddcdscdpic02isc0Dip00in*
alias: usb:v17EFp720Bddcdscdpic02isc06ip00in*
alias: usb:v17EFp720BddcdscdpicFFiscipin*
alias: usb:v17EFp720Addcdscdpic02isc0Dip00in*
alias: usb:v17EFp720Addcdscdpic02isc06ip00in*
alias: usb:v17EFp720AddcdscdpicFFiscipin*
alias: usb:v17EFp7205ddcdscdpic02isc0Dip00in*
alias: usb:v17EFp7205ddcdscdpic02isc06ip00in*
alias: usb:v17EFp7205ddcdscdpicFFiscipin*
alias: usb:v17EFp3098ddcdscdpic02isc0Dip00in*
alias: usb:v17EFp3098ddcdscdpic02isc06ip00in*
alias: usb:v17EFp3098ddcdscdpicFFiscipin*
alias: usb:v17EFp3082ddcdscdpic02isc0Dip00in*
alias: usb:v17EFp3082ddcdscdpic02isc06ip00in*
alias: usb:v17EFp3082ddcdscdpicFFiscipin*
alias: usb:v17EFp3069ddcdscdpic02isc0Dip00in*
alias: usb:v17EFp3069ddcdscdpic02isc06ip00in*
alias: usb:v17EFp3069ddcdscdpicFFiscipin*
alias: usb:v17EFp3062ddcdscdpic02isc0Dip00in*
alias: usb:v17EFp3062ddcdscdpic02isc06ip00in*
alias: usb:v17EFp3062ddcdscdpicFFiscipin*
alias: usb:v17EFp3057ddcdscdpic02isc0Dip00in*
alias: usb:v17EFp3057ddcdscdpic02isc06ip00in*
alias: usb:v17EFp3057ddcdscdpicFFiscipin*
alias: usb:v17EFp3054ddcdscdpic02isc0Dip00in*
alias: usb:v17EFp3054ddcdscdpic02isc06ip00in*
alias: usb:v17EFp3054ddcdscdpicFFiscipin*
alias: usb:v17EFp3052ddcdscdpic02isc0Dip00in*
alias: usb:v17EFp3052ddcdscdpic02isc06ip00in*
alias: usb:v17EFp3052ddcdscdpicFFiscipin*
alias: usb:v17EFp304Fddcdscdpic02isc0Dip00in*
alias: usb:v17EFp304Fddcdscdpic02isc06ip00in*
alias: usb:v17EFp304FddcdscdpicFFiscipin*
alias: usb:v04E8pA101ddcdscdpic02isc0Dip00in*
alias: usb:v04E8pA101ddcdscdpic02isc06ip00in*
alias: usb:v04E8pA101ddcdscdpicFFiscipin*
alias: usb:v045Ep07C6ddcdscdpic02isc0Dip00in*
alias: usb:v045Ep07C6ddcdscdpic02isc06ip00in*
alias: usb:v045Ep07C6ddcdscdpicFFiscipin*
alias: usb:v045Ep07ABddcdscdpic02isc0Dip00in*
alias: usb:v045Ep07ABddcdscdpic02isc06ip00in*
alias: usb:v045Ep07ABddcdscdpicFFiscipin*
alias: usb:v0BDAp8156ddcdscdpic02isc0Dip00in*
alias: usb:v0BDAp8156ddcdscdpic02isc06ip00in*
alias: usb:v0BDAp8156ddcdscdpicFFiscipin*
alias: usb:v0BDAp8155ddcdscdpic02isc0Dip00in*
alias: usb:v0BDAp8155ddcdscdpic02isc06ip00in*
alias: usb:v0BDAp8155ddcdscdpicFFiscipin*
alias: usb:v0BDAp8153ddcdscdpic02isc0Dip00in*
alias: usb:v0BDAp8153ddcdscdpic02isc06ip00in*
alias: usb:v0BDAp8153ddcdscdpicFFiscipin*
alias: usb:v0BDAp8152ddcdscdpic02isc0Dip00in*
alias: usb:v0BDAp8152ddcdscdpic02isc06ip00in*
alias: usb:v0BDAp8152ddcdscdpicFFiscipin*
alias: usb:v0BDAp8050ddcdscdpic02isc0Dip00in*
alias: usb:v0BDAp8050ddcdscdpic02isc06ip00in*
alias: usb:v0BDAp8050ddcdscdpicFFiscipin*
depends:
name: r8152
vermagic: 5.11.1-1-MANJARO-ARM SMP mod_unload aarch64
The new modules from aur works with my 8152 device but it is not the one you have. Also I was getting spammed with cdc_ncm messages with the kernel module and it is not happening with the aur one.
The fly in the onitment is the kernel module is built in the kernel and I will have to recompile the kernel before you can test.
Here is the new kernel and the dkms package.
I installed it on my pi4 and discovered that it can not exist on the same USB 3.0 bridge as my usb SSD. I lost my SSD drive the second the 8152 dongle was plugged in. Seems like I may seen similar happening to you previously in your logs above. My previous test was on the vim3 using the internal eMMc.
I then plugged the 8152 dongle into my usb 2.0 port and it worked:
Summary
[ 9.350416] usbcore: registered new interface driver cdc_ether
[ 9.425567] usb 1-1.3.4: reset high-speed USB device number 4 using xhci_hcd
[ 9.611047] r8152 1-1.3.4:1.0 eth1: v2.14.0 (2020/09/24)
[ 9.611059] r8152 1-1.3.4: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.
[ 9.611397] usbcore: registered new interface driver r8152
[ 9.621814] r8152 1-1.3.4:1.0 enp1s0u1u3u4: renamed from eth1
[ 11.292813] IPv6: ADDRCONF(NETDEV_CHANGE): enp1s0u1u3u4: link becomes ready
[ 11.293627] r8152 1-1.3.4:1.0 enp1s0u1u3u4: carrier on
[ 11.329232] bcmgenet fd580000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[ 11.329273] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Procedure:
Download the tarball and unpack it
cd 8152
sudo pacman -U linux-rpi4-5.10.17-2-aarch64.pkg.tar.zst linux-rpi4-headers-5.10.17-2-aarch64.pkg.tar.zst
Unplug your 8152 usb dongle and reboot. Once rebooted install the dkms package from the 8152 directory:
sudo pacman -U r8152-dkms-2.14-1-aarch64.pkg.tar.zst
Plug in your 8152 dongle and cross your fingers.
This is amazing. Thanks for doing this, @Darksky . What a lovely birthday present. 
I’ll try this later tonight. I’m presently booting off a USB3 enclosed nvme drive, so I’m not sure this is going to be workable if I can’t have them both plugged in. On the USB2 bus, won’t the dongle always be slower than the 800 or so Mbps I get now?
@0n0w1c Thanks for this. I just discovered the modprobe stuff last night, but it was 2AM and I didn’t have a chance to do more than realize it existed. You saved me quite a lot of research time.
I ended up doing this:
]$ cat blacklist.conf install cdc_ncm /bin/true install cdc_wdm /bin/true install cdc_ether /bin/true install cdc_mbim /bin/true
According to the wiki page you linked, this not only unloads those modules at boot, but also keeps any other loaded module from calling them.
Without the driver @Darksky prepared, I’m still not getting anything useful off the adapter. It reports itself as using the usb-network driver via inxi -N, which isn’t a listed kernel module in lsmod. I’m not sure if that can even be turned off if there’s not another driver installed.
Where does usb-network get loaded from? Can I use the same blocklist on it even though it doesn’t show up in lsmod?
That sounds like your adapter is not supported by the current r8152 linux driver. I would undo the blacklisting, as it did not result in a functional adapter. And then follow what @Darksky has prepared.
Yeah. I figured that was probably the case.
I’m guessing the usb-network driver is some baseline, “we do USB Network Adapters” thing that other drivers sit on top of? That would make sense as to why it can’t be unloaded.
Hello!
I just got home and am getting ready to try this.
I noticed you’re using the 5.10.17-2 kernel. I’m currently running 5.11.0-3. Should I update the version number?
I see the 5.10 headers and the 5.10 (UDL) version of the kernel, but I don’t see the 5.10.x version of the kernel for download…
EDIT: Also, did you use these Udev rules provided by Realtek with the 2.14 version of their linux driver?
The NIC mode appears to relate to the fact that this thing has multiple operation modes. I’m not sure what they each do, yet. Regarding modes, here’s what usbview has to say:
USB 10/100/1G/2.5G LAN Manufacturer: Realtek Serial Number: 000000001 Speed: unknown USB Version: 3.20 Device Class: 00(>ifc ) Device Subclass: 00 Device Protocol: 00 Maximum Default Endpoint Size: 9 Number of Configurations: 3 Vendor Id: 0bda Product Id: 8156 Revision Number: 30.00 Config Number: 1 Number of Interfaces: 1 Attributes: a0 MaxPower Needed: 512mA Interface Number: 0 Name: (none) Alternate Number: 0 Class: ff(vend.) Sub Class: ff Protocol: 00 Number of Endpoints: 3 Endpoint Address: 81 Direction: in Attribute: 2 Type: Bulk Max Packet Size: 1024 Interval: 0ms Endpoint Address: 02 Direction: out Attribute: 2 Type: Bulk Max Packet Size: 1024 Interval: 0ms Endpoint Address: 83 Direction: in Attribute: 3 Type: Int. Max Packet Size: 2 Interval: 128ms Config Number: 2 Number of Interfaces: 2 Attributes: a0 MaxPower Needed: 512mA Interface Number: 0 Name: Alternate Number: 0 Class: 02(comm.) Sub Class: 0d Protocol: 00 Number of Endpoints: 1 Endpoint Address: 83 Direction: in Attribute: 3 Type: Int. Max Packet Size: 16 Interval: 16ms Interface Number: 1 Name: Alternate Number: 0 Class: 0a(data ) Sub Class: 00 Protocol: 01 Number of Endpoints: 0 Interface Number: 1 Name: Alternate Number: 1 Class: 0a(data ) Sub Class: 00 Protocol: 01 Number of Endpoints: 2 Endpoint Address: 81 Direction: in Attribute: 2 Type: Bulk Max Packet Size: 1024 Interval: 0ms Endpoint Address: 02 Direction: out Attribute: 2 Type: Bulk Max Packet Size: 1024 Interval: 0ms Config Number: 3 Number of Interfaces: 2 Attributes: a0 MaxPower Needed: 512mA Interface Number: 0 Name: Alternate Number: 0 Class: 02(comm.) Sub Class: 06 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 83 Direction: in Attribute: 3 Type: Int. Max Packet Size: 16 Interval: 16ms Interface Number: 1 Name: Alternate Number: 0 Class: 0a(data ) Sub Class: 00 Protocol: 00 Number of Endpoints: 0 Interface Number: 1 Name: Alternate Number: 1 Class: 0a(data ) Sub Class: 00 Protocol: 00 Number of Endpoints: 2 Endpoint Address: 81 Direction: in Attribute: 2 Type: Bulk Max Packet Size: 1024 Interval: 0ms Endpoint Address: 02 Direction: out Attribute: 2 Type: Bulk Max Packet Size: 1024 Interval: 0ms
Just install the packages in the tarball as explained above.
Thanks. I’m not going to deviate from the instructions. Just wanted to make sure my kernel was compatible.
I am curious about the NIC modes, but I need to go hunt down info on how this card works. Realtek does not really describe the nitty gritty of their cards very well.
It will be removed and replaced with this test kernel.
Oh! That makes sense. I suppose I can’t test a compiled kernel unless I’m … using … it.
When the test is over, how do I switch back?
sudo pacman -S linux-rpi4-mainline linux-rpi4-mainline-headers
You need to remove the dkms package first though. The 8152 module is built in the linux-rpi4-mainline kernel in the repo right now.
Module loaded:
~]$ lsmod | grep 81
r8152 225280 0
Driver loaded:
~]$ inxi -N
Network: Device-1: Realtek USB 10/100/1G/2.5G LAN type: USB driver: r8152
Interface down while no network cable is plugged in:
4: enp1s0u2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether $HW_MAC brd ff:ff:ff:ff:ff:ff
All the ethernet USB adapters I’ve seen have the most ridiculous interface names…
Progress: Proper activity lights on switch indicating a 2.5G connection and Blinky-Blinky on the adapter–both things I’d not seen before.
Network Cable In:
~]$ ip addr show enp1s0u2
4: enp1s0u2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether $HW_MAC brd ff:ff:ff:ff:ff:ff
Current Status:
- The adapter has never been UP before. This is new.
- It isn’t getting an IP, which is a problem. But I think that’s because the network adapter does not have the right name in NetworkManager. Going to try to fix that after I figure out why the system just crashed.
- After fixing the name of the adapter in
nmtui, it immediately plugged in the device’s MAC and grabbed an IP.
EDIT: It either crashed because the NVME drive and enclosure do not like being plugged into the USB 2 port (which I just realized I did…it’s dark over there), OR from static electricity discharge.
Known Issues:
- LightDM won’t start. Not clear why yet. I’m going to check the logs, but I’m guessing the current version is expecting the 5.11 kernel. It makes sense it’s not working if that’s the case.
Update: Xorg’s log says “no screen found,” which makes no sense. The dummy plug is still there. Let me try…jiggling it or something.
- If left connected long enough (hours?), eventually the adapter drops the connection, and takes a few minutes to reconnect. The Pi does not indicate any interruption in uptime. Again, I’m wondering if this might be an issue with the Pi not being able to deliver steady power to the USB 3 port over time. I’ve also seen similar reports of this behavior.
]$ journalctl | grep usb
Feb 28 00:30:16 teletraan1 kernel: usb 2-2: reset SuperSpeed Gen 1 USB device number 3 using xhci_hcd Feb 28 01:28:03 teletraan1 kernel: usb 2-2: reset SuperSpeed Gen 1 USB device number 3 using xhci_hcd Feb 28 09:05:58 teletraan1 NetworkManager[389]: <info> [1614524758.2949] dhcp4 (enp1s0u2): hostname 'teletraan1usb25g'
Looks like this is probably the issue: networking - USB ethernet adapter (Realtek r8153) keeps disconnecting - Ask Ubuntu
The USB port eventually enters a suspend mode, and the adapter chokes. There’s some instructions in that thread for using a Udev rule to keep that from happening, but I don’t understand the rule well enough yet to try it. EDIT: I’ve studied this a bit more and think I understand it well enough to add a Udev rule–make sure to set the idProduct to whatever lsusb says:
(This rule MAY work. Powertop does not appear to read the value as changed, but gave me the command to execute to check the value. See below.)
ACTION==“add|change”, SUBSYSTEM==“usb”, ATTR{idVendor}==“0bda”, ATTR{idProduct}==“8156”, TEST==“power/control”, ATTR{power/control}=“on”
cat /sys/bus/usb/devices/1-1/power/autosuspend
0
So it looks like the Udev rule worked, but I’ll need to try to let it run overnight to see.
- With the NVME drive plugged into the USB 2 port, max thoroughput is roughly equal to a high performance SD card on its best day. I wonder if the problem with putting the NVME and the adapter on the USB 3 bus is some sort of driver conflict (fixable?), too much load (less fixable?), or not enough power from the bus to run both at once (probably the easiest to fix).
The previous reply, which still has outstanding issues as I write this re: LightDM, is getting a little long.
So here’s a new reply with some speed test results from iperf3…
I ran this 5 times, and got basically the same results every time. For the record, this is about 2.07 times faster than what I was getting with the builtin 1Gbps adapter, and I could probably push it harder with jumbo frames, etc. Though, that would require me to learn a lot more about how to configure my switch/VLANs, etc.
[$USER@teletraan1 ~]$ iperf3 -c $HOST
Connecting to host $HOST, port 5201
[ 5] local ... port 56506 connected to $HOST port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 218 MBytes 1.83 Gbits/sec 0 691 KBytes
[ 5] 1.00-2.00 sec 216 MBytes 1.82 Gbits/sec 0 691 KBytes
[ 5] 2.00-3.00 sec 218 MBytes 1.82 Gbits/sec 0 731 KBytes
[ 5] 3.00-4.00 sec 215 MBytes 1.81 Gbits/sec 0 802 KBytes
[ 5] 4.00-5.00 sec 222 MBytes 1.87 Gbits/sec 0 802 KBytes
[ 5] 5.00-6.00 sec 214 MBytes 1.79 Gbits/sec 0 802 KBytes
[ 5] 6.00-7.00 sec 216 MBytes 1.81 Gbits/sec 0 802 KBytes
[ 5] 7.00-8.00 sec 215 MBytes 1.81 Gbits/sec 0 802 KBytes
[ 5] 8.00-9.00 sec 216 MBytes 1.81 Gbits/sec 0 802 KBytes
[ 5] 9.00-10.00 sec 221 MBytes 1.85 Gbits/sec 0 802 KBytes
Great success.
Congrats. I am curious, what is the CPU load when transmitting data at that speed?
I’ll grab that for you, @0n0w1c . What’s the best way?
cpu percent in top, or something else?
EDIT: iPerf3 maxes 1 core when it runs, and sometimes spikes a second core up to ~40 percent.
iperf3 -c serverIP -P 10
Sure, top or htop will work, just wanting a general idea. I would expect the CPUs to rather busy above 1.5 Gbps. But are they 80%, 100%? I am wondering if serving up NFS via SSD and 2.5Gbps, both on USB 3 is more than the RPi4 can handle.