[6.10 rc3 - 6.11.5] Realtek RTL8156 USB 2.5Gb NIC not working

Same problem for me after upgrading from 6.9.2 to 6.11.0 stable...

Best bet for now is to use this driver:

 

i too need to get 2.5gb working.

Not too happy to download from a random chinese website.
Surely unraid show to on top of this one as they are the ones we paid the money to.
listed in devises but not in network.
 

IOMMU group 4:[1022:1452] 00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge

[1022:15db] 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Internal PCIe GPP Bridge 0 to Bus A

[1022:145a] 08:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Zeppelin/Raven/Raven2 PCIe Dummy Function (rev c8)

[1022:15df] 08:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) Platform Security Processor

[1022:15e0] 08:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Raven USB 3.1

Bus 003 Device 001 Port 3-0 ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 003 Device 002 Port 3-3 ID 0bc2:ab44 Seagate RSS LLC Backup Plus Hub

Bus 004 Device 001 Port 4-0 ID 1d6b:0003 Linux Foundation 3.0 root hub

Bus 004 Device 002 Port 4-2 ID 0bda:8156 Realtek Semiconductor Corp. USB 10/100/1G/2.5G LAN

Bus 004 Device 003 Port 4-3 ID 0bc2:ab45 Seagate RSS LLC Backup+ Hub

Bus 004 Device 004 Port 4-3.1 ID 0bc2:ab38 Seagate RSS LLC Backup Plus Hub (Mass Storage)

[1022:15e1] 08:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Raven USB 3.1

Bus 005 Device 001 Port 5-0 ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 005 Device 002 Port 5-1 ID 0781:5567 SanDisk Corp. Cruzer Blade

Bus 006 Device 001 Port 6-0 ID 1d6b:0003 Linux Foundation 3.0 root hub

 

Really could do with help on this one. Makes have an NVME drive as cache useless with onlt 1gb connection.

 

Otherwise finding unrad a great platform.

I totally agree. We need an official unraid solution. A few posts above someone mentioned that at some point unraid will change how drivers are loaded and that could be a solution but I've been using unraid long enough to know that that time could be measured in years.

Issue still exists in 6.11.4.

I really hope this gets fixed soon.

Do you already know when a fix should or will come? in 6.11.5 there are not supported.

This bug exists for nearly a year.

Maybe it is now on the bottom of the priority debug list (or the bin😪)

 

Got my rtl8156b usb 2.5gb nic today... I assumed incorrectly that it would work. Updated to 6.11.5 and still no dice. 

Had to use this patch to get it to work: 

 

Scratch that, server goes down with: r8152 4-2:1.0 eth0: failed tx_urb -22

First month of 2023 is almost over and this still does not work.
At this point it´s just freaking ridiculous.

Obviously nobody cares about fixing it.
I used to be pretty enthusiastic aboout unraid and used it a lot.

That enthusiasm is now pretty much gone.
Important fixes like this are ignored, obviously nobody cares, other features like native zfs implementation, which people have requested for years, are still in the "maybe in a few years" category.

 

Just use an old OS version or download some stuff from a random chinese dude, because who the f cares anyways....

 

How is this still an issue after almost a year...

I‘m on it, plugin is coming today with the OOT drivers, give me a few hours… 😉

OMG, that's such good news.

I have now uploaded the plugin and it should appear in the next few hours in the CA App.

 

Please note that this plugin currently only supports Unraid version 6.11.5+ and you will only see it if you are at least on that version.

 

Here is the direct plugin link:

https://raw.githubusercontent.com/ich777/unraid-r8152-driver/master/unraid-r8152.plg

 

ATTENTION: You have to reboot after you've installed the plugin because I really don't like messing with such critical drivers when the system is running, as a side note if you ever upgrade to a newer Unraid version you have to reboot again after the upgrade because the updated package is only pulled on reboot for the new Unraid Kernel version.

13 minutes ago, ich777 said:

I have now uploaded the plugin and it should appear in the next few hours in the CA App.

 

ich777's Repository
    https://raw.githubusercontent.com/ich777/unraid-r8152-driver/master/unraid-r8152.plg:
        Fatal: Plugin URL on xml template does not match PluginURL in .plg (https://raw.githubusercontent.com/ich777/unraid-r8152-driver/master/unraid-r8152.plg vs https://github.com/ich777/unraid-r8152-driver/raw/master/r8152-driver.plg)

 

@Squid I have seen that and fixed it already...

1 hour ago, ich777 said:

@Squid I have seen that and fixed it already...

Fatal: Plugin URL on xml template does not match PluginURL in .plg (https://raw.githubusercontent.com/ich777/unraid-r8152-driver/master/unraid-r8152.plg vs https://raw.githubusercontent.com/ich777/unraid-r8152-driver/master/r8152-driver.plg)

 

3 hours ago, ich777 said:

@Squid

I very much appreciate your help with this. I have installed the plugin and have the interface up.

Currently it's negotiating at 1000base-T-FD
 

eth2: negotiated 1000baseT-FD flow-control, link ok
  product info: vendor 00:07:32, model 4 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
  link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control

Any thoughts?

Previously, with the failing driver, it was linking at 2.5Gbps before it failed a few minutes later.

 

EDIT:

Just noticed that it's detecting the USB RTL8156 as a "r8152'

 

Feb  7 16:02:16 Tower kernel: usb 9-1: new SuperSpeed USB device number 3 using xhci_hcd
Feb  7 16:02:16 Tower kernel: usb 9-1: reset SuperSpeed USB device number 3 using xhci_hcd
Feb  7 16:02:16 Tower kernel: r8152 9-1:1.0 eth2: v2.16.3 (2022/07/06)
Feb  7 16:02:16 Tower kernel: r8152 9-1:1.0 eth2: This product is covered by one or more of the following patents:
Feb  7 16:02:16 Tower kernel:           US6,570,884, US6,115,776, and US6,327,625.
Feb  7 16:02:16 Tower kernel:
Feb  7 16:03:16 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
Feb  7 16:03:16 Tower kernel: r8152 9-1:1.0 eth2: carrier on
Feb  7 16:03:18 Tower  avahi-daemon[3495]: Joining mDNS multicast group on interface eth2.IPv6 with address fe80::a2ce:c8ff:fe67:79b5.
Feb  7 16:03:18 Tower  avahi-daemon[3495]: New relevant interface eth2.IPv6 for mDNS.
Feb  7 16:03:18 Tower  avahi-daemon[3495]: Registering new address record for fe80::a2ce:c8ff:fe67:79b5 on eth2.*.
Feb  7 16:05:24 Tower  avahi-daemon[3495]: Interface eth2.IPv6 no longer relevant for mDNS.
Feb  7 16:05:24 Tower  avahi-daemon[3495]: Leaving mDNS multicast group on interface eth2.IPv6 with address fe80::a2ce:c8ff:fe67:79b5.

 

System Devices pages lists it as:
 

Bus 009 Device 004 Port 9-1	  ID 0bda:8156 Realtek Semiconductor Corp. USB 10/100/1G/2.5G LAN

 

Edited February 7, 2023 by bfeist

14 hours ago, bfeist said:

Just noticed that it's detecting the USB RTL8156 as a "r8152'

Exactly, this module is used for RTL8152/3/4/6 chipset like the in tree Kernel module.

 

Please add this line to your go file and reboot:

ethtool -s eth0 autoneg on advertise 0x80000000002f

(please customize eth0 in the above to the corresponding adapter in your system, I think in your case it's eth2)

r8152 is the driver and covers the 8156.

 

A lot of good information here on the different 8156 chips, vendors, and issues, in article and comments.

 

Fixing performance issues with Realtek RTL8156B USB dongle

 

Seems everything from getting a specific chip to using different USB ports, usb calbel can make all the difference.

Just a note.  GitHub is currently having some major issues which is affecting adding the plugin to CA.  A side effect of these issues is that if you've manually installed the plugin you will not ever be able to receive any updates to it if one becomes available in the future.

 

Once the plugin does show within CA, I'd suggest everyone uninstall and then reinstall the plugin so that the changes implemented in the plugin are reflected in the local copy on your server

7 hours ago, ich777 said:

Exactly, this module is used for RTL8152/3/4/6 chipset like the in tree Kernel module.

 

Please add this line to your go file and reboot:

ethtool -s eth0 autoneg on advertise 0x80000000002f

(please customize eth0 in the above to the corresponding adapter in your system, I think in your case it's eth2)

Thanks again for your help. I added the line (with eth2) to my go file, but the speed is still 1Gbps.
 

root@Tower:~# mii-tool -v eth2
eth2: negotiated 1000baseT-FD flow-control, link ok
  product info: vendor 00:07:32, model 4 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
  link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control

 

System Devices still shows:

Bus 009 Device 002 Port 9-2	  ID 0bda:8156 Realtek Semiconductor Corp. USB 10/100/1G/2.5G LAN

I tried making the device eth0.

I tried resetting the device with custom rules (as was suggested a long time ago in this thread) by adding the following to my go file:

cp /boot/config/rules.d/50-usb-realtek-net.rules /etc/udev/rules.d/50-usb-realtek-net.rules
chmod 644 /etc/udev/rules.d/50-usb-realtek-net.rules
udevadm control --reload-rules
usbreset 0bda:8156 #(get these numbers via running usbreset without any arguments - Number 003/002 ID >0bda:8156 USB 10/100/1G/2.5G LAN for me)
ethtool -s eth2 autoneg on advertise 0x80000000002f

No change.

Along the way, at one point syslog was being filled with:

Feb  8 10:09:23 Tower kernel: xhci_hcd 0000:00:10.1: WARN waiting for error on ep to be cleared
Feb  8 10:09:23 Tower kernel: r8152 9-2:1.0 eth0: failed tx_urb -22
Feb  8 10:09:24 Tower kernel: xhci_hcd 0000:00:10.1: WARN waiting for error on ep to be cleared
Feb  8 10:09:24 Tower kernel: r8152 9-2:1.0 eth0: failed tx_urb -22
Feb  8 10:09:25 Tower kernel: xhci_hcd 0000:00:10.1: WARN waiting for error on ep to be cleared
Feb  8 10:09:25 Tower kernel: r8152 9-2:1.0 eth0: failed tx_urb -22
Feb  8 10:09:25 Tower kernel: xhci_hcd 0000:00:10.1: WARN waiting for error on ep to be cleared
Feb  8 10:09:25 Tower kernel: r8152 9-2:1.0 eth0: failed tx_urb -22

 

Could this be a driver issue, or something to do with my troubleshooting?

 

Regardless. I have put it back on eth2, It's still only showing up as 1Gbps capable. But I'll let it run like this for a while to see if I get the console errors again.

1 hour ago, bfeist said:

Could this be a driver issue, or something to do with my troubleshooting?

Possibly a NIC issue, this is mine before adding the go line:

 

Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full 2500baseT/Full
Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full

 

After adding the go line:

Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full 2500baseT/Full
Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full 2500baseT/Full

 

Yours is doesn't mention 2.5GbE support, it's not just a advertising issue.

 

Mine appears as:

Bus 002 Device 003 Port 2-2 ID 0bda:8156 Realtek Semiconductor Corp. USB 10/100/1G/2.5G LAN

 

15 hours ago, bfeist said:

Bus 009 Device 002 Port 9-2	  ID 0bda:8156 Realtek Semiconductor Corp. USB 10/100/1G/2.5G LAN

 

Since @JorgeB and you have the exact same device "0bda:8156" (at least vendor and device ID) I assume it has something to do with your testing but that's only an assumption.

 

Have you yet tried to remove your network configuration entirely and revert everything back to default except for the line in the go file?

 

15 hours ago, bfeist said:

I tried making the device eth0.

That won't work if the USB adapter is not eth0 because you are basically forcing another adapter into a mode which it does not support.

@ich777 Thanks for the comments.

 

After leaving the device connected for a few minutes (maybe an hour or so), the log started to fill with

 

Feb  8 10:09:23 Tower kernel: xhci_hcd 0000:00:10.1: WARN waiting for error on ep to be cleared
Feb  8 10:09:23 Tower kernel: r8152 9-2:1.0 eth0: failed tx_urb -22
Feb  8 10:09:24 Tower kernel: xhci_hcd 0000:00:10.1: WARN waiting for error on ep to be cleared
Feb  8 10:09:24 Tower kernel: r8152 9-2:1.0 eth0: failed tx_urb -22

again.

 

I removed the USB NIC, the driver plugin, the go configuration changes and then spent 5 hours yesterday trying to figure out why my unraid box was unable to route to the internet. Thought it might be a mac address binding issue after switching eth0 to the USB NIC. Reset my router. Reset docker. Eventually tried using a dynamic DHCP IP and it worked. Looked carefully at the network settings after setting dynamic and discovered that unraid adds a default route when using DHCP. Somehow, unraid deleted the default route from eth0 to the internet when using a static IP. Fixed now, but it was a stark reminder of just how fragile UNRAID is and how shallow my understanding of linux networking is. I don't do any of this config management stuff often enough to actually learn any of it.

 

I'm going to take a breather from trying to get this to work. I think my whole idea of having a USB NIC be my primary NiC for unraid isn't a great one to begin with, even without the issues in this thread. I was hoping to free up a PCI-E slot for a GPU, but things will just have to stay as they are.

 

Thanks to the great unraid community for your help as always.
 

Edited February 9, 2023 by bfeist