6

Since upgrading to Ubuntu 18.04 from 17.10 my usb ethernet adapter keeps disconnecting. It used to work perfectly with 17.10.

dmesg shows the following output upon a connection drop:

[  273.462732] usb 4-1.4: usb_reset_and_verify_device Failed to disable LTM
               .
[  273.643622] usb 4-1.4: USB disconnect, device number 11
[  273.795468] usb 4-1.4: new SuperSpeed USB device number 12 using xhci_hcd
[  273.816520] usb 4-1.4: New USB device found, idVendor=0bda, idProduct=8153
[  273.816522] usb 4-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[  273.816523] usb 4-1.4: Product: USB 10/100/1000 LAN
[  273.816524] usb 4-1.4: Manufacturer: Realtek
[  273.816525] usb 4-1.4: SerialNumber: 0000A5
[  273.896167] usb 4-1.4: reset SuperSpeed USB device number 12 using xhci_hcd
[  273.948778] r8152 4-1.4:1.0 eth0: v1.09.9
[  274.503001] r8152 4-1.4:1.0 enx144fd7d04a3c: renamed from eth0
[  274.539481] IPv6: ADDRCONF(NETDEV_UP): enx144fd7d04a3c: link is not ready
[  274.543857] IPv6: ADDRCONF(NETDEV_UP): enx144fd7d04a3c: link is not ready
[  276.431243] r8152 4-1.4:1.0 enx144fd7d04a3c: carrier on
[  276.431258] IPv6: ADDRCONF(NETDEV_CHANGE): enx144fd7d04a3c: link becomes ready

5 Answers 5

12

While writing the question I found the source of the bug on the kernel mailing list. The r8152 driver which is responsible for managing my r8153 adapter cannot handle the usb autosuspend (done for power saving reasons). Blacklisting the device for usb autosuspend solves the disconnects and is done like so:

Find out the usb id of your device (0bda:8153 in my case) by using lsusb, which gives me:

Bus 004 Device 003: ID 0bda:8153 Realtek Semiconductor Corp.

Now you open /etc/default/tlp and search for USB_BLACKLIST and add an entry for your device:

USB_BLACKLIST="0bda:8153"

You may need to reboot, after which your ethernet connection should be stable again.

3
  • This tip also solves the issue on UH3031GC Superspeed USB-C 4-Port Hub with Gigabit Ethernet, which comes with RT 8153. Mar 1, 2020 at 9:47
  • I tried this on my device (same VID/PID as example; ubuntu 20.04.1) and instead of reconnecting system started freezing :(
    – Barnaba
    Jan 18, 2021 at 15:24
  • Note for anyone trying this: tlp has changed its config file location since v1.3. See here. You can find out which version you are running with tlp-stat -s.
    – cyqsimon
    Sep 26, 2021 at 7:31
3

You can also do this using kernel udev rules. I created udev rules both to turn off usb autosuspend for the device and also turn off Turbo Mode of the CPU (which may help too):

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0bda", ATTR{idProduct}=="8153", TEST=="power/control", ATTR{power/control}="on"
KERNEL=="cpu",RUN+="/bin/sh -c 'echo -n 1 > /sys/devices/system/cpu/intel_pstate/no_turbo'"

Put the above in a file: /etc/udev/rules.d/50-cpu-custom.rules

2
  • The gigabit ethernet adapter was not working at all under USB3.0 (but it was for USB2/0) and this seemingly fixed it for me in Fedora 32. Thank you! May 4, 2020 at 21:17
  • Glad it helped @AspiringDev!
    – mcarans
    May 5, 2020 at 8:20
0

I stumbled on this issue as well, but for me the problem was that the r1852 LAN driver's faulty ability to auto-suspend was the culprit for my random freezes.

I solved it using powertop, which is nice because you don't have to find out the usb id of the device.

0

Im a bit confused, but thought this bit of info might help. In a linked question I asked about a similar problem I had that was not resolved by the solutions here. Though I fixed it shortly after, and after ordering another adapter, by changing the config in /etc/networking/interfaces, an answer was just posted pointing out there are two similar numbers used in my dmesg. BTW, use dmesg -T for human readable timestamps!

So the adapter was reporting as usb 3-4: New USB device found, idVendor=0bda, idProduct=8153 but then the r8152 driver(?) r8152 3-4:1.0 eth0: v1.09.9 was using it. So which to number to use in the blacklist 8153 or 8152? It would be 8153 I assume because this is the number of the device being blacklisted. But just be aware here of the two similar numbers when troubleshooting.

0

There is a bugzilla entry at kernel.org about what seems to be this issue (though, it may be two separate issues).

https://bugzilla.kernel.org/show_bug.cgi?id=198931

The TLP workaround here did not solve my issue but I have been able to solve the issue based on some of the advice in that bug discussion. I did however make multiple fixes at once and do not know which fix actually solved it.

  1. I added usbcore.quirks=0bda:8153:k to my kernel boot command line
  2. I installed the latest firmware-realtek package (this one was Debian specific I see, you probably already have this in Ubuntu in one of the other firmware packages)
  3. In the network manager interface I switched the connection autonegotiation for the ethernet connection from "ignore" to "automatic".

Anyway, that discussion has all these and more different fixes and workarounds and I hope some combination works for anyone experiencing this.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.