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

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:


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

| improve this answer | |
  • This tip also solves the issue on UH3031GC Superspeed USB-C 4-Port Hub with Gigabit Ethernet, which comes with RT 8153. – Anibal Sanchez Mar 1 at 9:47

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

| improve this answer | |
  • 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! – Aspiring Dev May 4 at 21:17
  • Glad it helped @AspiringDev! – mcarans May 5 at 8:20

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.

| improve this answer | |

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.

| improve this answer | |

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.