7

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
mcarans
  • 1,155
  • 2
  • 9
  • 19
nhaesler
  • 613
  • 1
  • 5
  • 11
  • Still a problem 5 years later, wishful thinking I suppose that Realtek might fix their driver to avoid this problem somehow... – Earl Sven Feb 24 '23 at 10:11

5 Answers5

15

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.

nhaesler
  • 613
  • 1
  • 5
  • 11
  • 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 01 '20 at 09: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 '21 at 15:24
  • 1
    Note for anyone trying this: `tlp` has changed its config file location since v1.3. See [here](https://linrunner.de/tlp/settings/introduction.html#config-files). You can find out which version you are running with `tlp-stat -s`. – cyqsimon Sep 26 '21 at 07:31
  • This helped me connect my Lenovo T480 through my monitor's (Dell P2723DE) hub using a USB-C cable (Ubuntu 20.04). – aba Sep 25 '22 at 18:54
  • This worked for me with my D-Link USB-C hub with Ethernet, previously I had to restart networkmanager after connecting a cable ‍♂️ the usbcore.quirks kernel parameter solution didn't work for me, but maybe it would have if I'd also added the ID for the hub the RTL8152 is connected to. – Earl Sven Feb 24 '23 at 10:09
  • Is that now called USB_DENYLIST as I cannot find that anylonger in the docs? https://linrunner.de/tlp/faq/usb.html#usb-device-does-not-work – jaques-sam May 08 '23 at 10:07
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

mcarans
  • 1,155
  • 2
  • 9
  • 19
1

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.

thomasrutter
  • 36,068
  • 10
  • 86
  • 105
  • 1
    This worked for me: `usbcore.quirks=0bda:8153:k` and the same on the USB hub it was connected to. My final string was: `usbcore.quirks=0bda:8153:k,1a40:0101:gk` – Firefishy Sep 05 '22 at 23:23
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.

Toon
  • 1
  • 1
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.

alchemy
  • 744
  • 1
  • 9
  • 27