Dell DA200 USB-C adapter and USB autosuspend

Published: 2016-08-26
Updated: 2016-12-31

I recently purchased a Dell DA200 USB-C adapter to have Ethernet without needing to sacrifice one of the two regular USB 3 ports. Debian Testing picks it up just fine, according to dmesg:

[    2.167530] usb 4-1.4: new SuperSpeed USB device number 3 using xhci_hcd
[    2.184448] usb 4-1.4: New USB device found, idVendor=0bda, idProduct=8153
[    2.184452] usb 4-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[    2.184454] usb 4-1.4: Product: USB 10/100/1000 LAN
[    2.184456] usb 4-1.4: Manufacturer: Realtek

However, within minutes of hooking it up I noticed my Ethernet interface going down and coming up again every X seconds. I had read about early adopters experiencing all kinds of weirdness with USB-C adapters, so I wasn't too surprised, however, I expected USB-C support to be more mature (at this time Testing uses a 4.6 kernel). So I went looking under the hood.

Digging into the problem

Dmesg -l err quickly brought a possible culprit to light:

[    5.402198] usb 4-1.4: usb_reset_and_verify_device Failed to disable LTM

This error kept popping up - like every 15 seconds. Looking online you get all kinds of advice, from using a powered USB-C hub, to making sure the USB-C port doesn't get its power cut off. Digging deeper it turned out multiple people seemed to have this issue, which went away when they disabled the USB autosuspend functionality. Since disabling that hurts your battery life, that was not an option - at least, not completely.

TLP to the rescue

I rely on TLP for most of my powersaving measures, but I also use udev to implement some additional tidbits (among which a thorough USB autosuspend). I won't lie - I first tried writing udev rules to disable powersaving specifically on the the buses/devices the USB-C adapter uses, but that did not work out, so I turned to my old friend TLP. As luck would have it, TLP has a simple solution - called USB_BLACKLIST and readily configurable through /etc/default/tlp. It allows you to list the device IDs, which you get by consulting lsusb:

$ lsusb
Bus 004 Device 004: ID 0bda:8153 Realtek Semiconductor Corp. 
Bus 004 Device 002: ID 05e3:0617 Genesys Logic, Inc. 
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 0835:2a01 Action Star Enterprise Co., Ltd 
Bus 003 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0bda:5682 Realtek Semiconductor Corp. 
Bus 001 Device 002: ID 8087:0a2b Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

As you can see, the Realtek device is 0bda:8153, so that goes into the blacklist, a reboot (or a sudo udevadm control --reload-rules) and the Ethernet adapter should behave just fine, while your other USB devices still get put to sleep when they're not in use.

As an aside, I had a similar issue with my desktop - the LCD has 2 USB 2.0 ports, which I use to connect my keyboard and mouse; once I blacklisted the LCD's USB ID any responsiveness problems were gone. USB sticks plugged into the monitor got recognised as well after.