Home / ubuntu / Questions / 1044127
Accepted
nhaesler
Asked: 2018-06-07 03:47:03 +0800 CST

USB ethernet adapter (Realtek r8153) keeps disconnecting

  • 772

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
networking usb ethernet 18.04 tlp

5 Answers

  1. Best Answer

    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.

    • 12

  2. 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

    • 3

  3. 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.

    • 1

  4. 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

  5. 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