Update kmod-usb-net-rtl8152 Driver to avoid USB 3.0 to Gigabit LAN issues?

I have problem using OpenWRT on raspberry pi 4 where I use USB 3.0 To Gigabit Ethernet Adapter which use realtek RTL 8153 chipset, and apparantly there are problem with this chip (both 8152 and 8153) involving USB autosuspend which plague both windows and linux version, I've tried disabling power save feature in windows and the problem only reduced but still exist, then I update the driver with the latest 2020 from realtek website (windows) and the problem dissapear.

Since there are also 2020 driver for linux in realtek website, can this thing implemented too in kmod-usb-net-rtl8152? thanks.

I've not had any problems with my RPi4 and a UE300 adapter (RTL8153 chipset). What is the issue you've been seeing in OpenWRT?

1 Like

After openwrt boot on RPi4 (lan on native ethernet port, wan on usb lan adapter plugged in to usb 3.0 port), tried to get speedtest (at dslreports.com/speedtest) which during the test the connection interrupted (error) and login to LuCI -> interfaces I saw "device is not ready" on wan and wan6 interface.
Tried directly connecting the usb lan adapter from laptop to ISP modem (using usb 3.0 port also) got similar result after trying speedtest or any activity which stress bandwidth. the network adapter became dissapear before reappearing again few times. At first I thought faulty USB adapter, but after some browsing and found several similar case with this chipset which probable cause is usb autosuspend on USB 3.0 port and one of the solution is by disabling it in linux or windows, I first tried disabling USB autosuspend in device managers. It helps a little now device only dissapear and reappear during upload test.

Then I try downloading RTL8153 latest drivers (windows 10) in realtek website, enable the USB autosuspend again, and try speedtest... no error or whatsoever after long usage.

I also tried using the USB 2.0 port on Rpi4 and test it again, also no error, but since the USB LAN Adapter is USB 3.0 Gigabit LAN so the speed drops considerably when using USB 2.0 port.

1 Like

Hey, @Ark,

QQ, are you compiling your own distro? If this is the case I can send you a patch with latest RTL8153 drivers, I am testing it, but I will like somebody else confirming me it is working as expected.

Here goes my dmesg:

[1049117.938607] usbcore: registered new interface driver r8152
[1049165.869005] usb 2-1: new SuperSpeed Gen 1 USB device number 4 using xhci_hcd
[1049165.894069] usb 2-1: New USB device found, idVendor=2357, idProduct=0601, bcdDevice=30.00
[1049165.902451] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[1049165.909814] usb 2-1: Product: USB 10/100/1000 LAN
[1049165.914708] usb 2-1: Manufacturer: TP-LINK
[1049165.918992] usb 2-1: SerialNumber: 000001000000
[1049166.057359] usb 2-1: reset SuperSpeed Gen 1 USB device number 4 using xhci_hcd
[1049166.154609] r8152 2-1:1.0 eth2: v2.13.0 (2020/04/20)
[1049166.159837] r8152 2-1:1.0 eth2: This product is covered by one or more of the following patents:
[1049166.159837] 		US6,570,884, US6,115,776, and US6,327,625.
[1049166.159837] 
[1049166.184249] br-lan: port 2(eth2) entered blocking state
[1049166.189670] br-lan: port 2(eth2) entered disabled state
[1049166.195232] device eth2 entered promiscuous mode
[1049166.200150] br-lan: port 2(eth2) entered blocking state
[1049166.205560] br-lan: port 2(eth2) entered forwarding state
[1049166.211372] br-lan: port 2(eth2) entered disabled state

If there is anybody else willing to try, please, let me know.

Kind regards.

1 Like

maybe because it's not USB 3.0 to ethernet based variant?

nope, I'm currently using imagebuilder because lack of space in my hosting at the time, but since windows 10 update 2004 maybe I'll try building one with wsl2, can you show me the instruction? thank you.

edit : can I use patch using imagebuilder?

I don't think so, it's a bit late for me here, but if you paste here your /etc/openwrt_version file I'll compile an IPK file for you by tomorrow.

1 Like

thanks, here's my openwrt_version file r13565-373f446049

As promised, here you go: kmod-usb-net-rtl8152_5.4.45-1_v2.13_aarch64_cortex-a72.ipk

To install it:

opkg --force-reinstall install kmod-usb-net-rtl8152_5.4.45-1_v2.13_aarch64_cortex-a72.ipk

Please, let us know how your testing goes.

I've ordered my UE300 adaptor now too, so I'll be interested to see how this works out.

Ok, I have installed the new driver files and the error still occured, here's the snippet of the system log

Mon Jun 29 19:25:54 2020 kern.err kernel: [   87.186668] r8152 2-1:1.0 eth1: get_registers -71
Mon Jun 29 19:25:54 2020 kern.err kernel: [   87.191982] r8152 2-1:1.0 eth1: get_registers -71
Mon Jun 29 19:25:54 2020 kern.err kernel: [   87.197297] r8152 2-1:1.0 eth1: get_registers -71
Mon Jun 29 19:25:54 2020 kern.err kernel: [   87.202613] r8152 2-1:1.0 eth1: get_registers -71
Mon Jun 29 19:25:54 2020 kern.err kernel: [   87.207929] r8152 2-1:1.0 eth1: get_registers -71
Mon Jun 29 19:25:54 2020 kern.err kernel: [   87.213239] r8152 2-1:1.0 eth1: get_registers -71
Mon Jun 29 19:25:54 2020 kern.err kernel: [   87.218553] r8152 2-1:1.0 eth1: get_registers -71

for quite long followed by error like this :

Mon Jun 29 19:25:57 2020 daemon.err uwsgi[1244]: Mon Jun 29 19:25:57 2020 - [emperor] vassal /etc/uwsgi/vassals/luci-cgi_io.ini is now loyal
Mon Jun 29 19:26:01 2020 kern.warn kernel: [   94.928880] r8152 2-1:1.0 eth1: Tx timeout
Mon Jun 29 19:26:02 2020 kern.warn kernel: [   95.441010] xhci_hcd 0000:01:00.0: Timeout while waiting for setup device command
Mon Jun 29 19:26:06 2020 kern.warn kernel: [   99.792513] r8152 2-1:1.0 eth1: Tx timeout
Mon Jun 29 19:26:07 2020 kern.warn kernel: [  100.816550] xhci_hcd 0000:01:00.0: Timeout while waiting for setup device command
Mon Jun 29 19:26:08 2020 kern.err kernel: [  101.028403] usb 2-1: device not accepting address 2, error -62
Mon Jun 29 19:26:11 2020 kern.warn kernel: [  104.912138] r8152 2-1:1.0 eth1: Tx timeout
Mon Jun 29 19:26:12 2020 kern.err kernel: [  105.128188] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
Mon Jun 29 19:26:12 2020 kern.err kernel: [  105.892438] r8152 2-1:1.0 eth1: get_registers -19
Mon Jun 29 19:26:12 2020 kern.info kernel: [  105.892467] usb 2-1: USB disconnect, device number 2
Mon Jun 29 19:26:12 2020 kern.err kernel: [  105.897163] r8152 2-1:1.0 eth1: Get ether addr fail

here's similar problem in ubuntu in this thread, although disabling power management doesn't make the problem go away totally (it still occured but not often). Similar symptom of problem also in windows 10.

What is the adaptor you're using?

1 Like

The usb 3.0 to gigabit lan adapter is not so known brand called "m-tech" exactly like this picture :


Interestingly, I bought second usb 3.0 to gigabit lan (no-name brand), it has exactly the same look without the M-Tech naming, but the chipset is using Asix AX88179, this adapter works without problem (that I know of) in raspberry pi 4.

I would suggest the issue is with the adaptor, rather than the chipset. Other brands using the rtl chips seem to work fine with the RPi4. I've had no issues with the TP-Link UE300. Maybe try a different brand, see if it solves it?

3 Likes

That was my thought at first, but after updating the driver from realtek website solve the problem completely (not to mention similar older problems in other forums).

Also without updating the drivers but using usb 2.0 port the device works flawlessly (well except it won't give full gigabit speed since bottleneck in usb 2.0 interface).

@Ark, after all your problems and seeing that people is not having problems with UE300 adaptors and 2013 drivers and, I do not have problems with same adaptor and 2020 drivers. May I suggest you get a new one? In the end, even with same chipset, adaptors are not build the same and they differ in quality.

I guess for this time I'll use my other USB 3.0 to gigabit adapter which is AX88179 based, or putting the RTL8153 adaptor in USB 2.0 slot. I do plan to use the realtek on raspberry pi but using dietpi, nftable and updated linux driver as another router / gateway, and testing if the adapter works normally like in windows. But I don't have spare unit because it's now used as my main router right now so maybe in the future.

1 Like

@xiaobo, as you can see it got rejected, probably because how I committed it. Let me see if I can follow up on how to properly do the pull request for a new version of a kernel driver.

1 Like

Ok, finally I bought UE-300 and plugged it in usb 3.0 port, works normal unlike previous adapter. although a bit curious lsusb shows rtl8152 even though google said it's rtl8153 chipset. And I vaguely remember my previous adapter shows as rtl8153...

This is not a driver problem. The USB core is also unable to communicate with the device. That's most likely a hardware and/or firmware issue with the device. I'd just throw it in the garbage.

This doesn't mean that I don't believe you are right about the bug being related to autosuspend or other parts of device power management. It might very well be related. But it's still a bug. And there might be more. Which is why I believe implementing any workaround is a waste of time.

But disabling autosuspend is simple in Linux. You don't need anythong special for that. You can

  1. boot with usbcore.autosuspend=-1 on the kernel command line, or
  2. echo -1 >/sys/module/usbcore/parameters/autosuspend, or
  3. echo -1 >/sys/bus/usb/devices/x-y/power/autosuspend (where x-y must be replaced)

This is documented e.g in https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-bus-usb