On Sun, May 08, 2016 at 11:25:34AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=117811
> 
>             Bug ID: 117811
>            Summary: intermittent USB disconnection
>                     (sb_reset_and_verify_device Failed to disable LTM)
>            Product: Drivers
>            Version: 2.5
>     Kernel Version: 4.6.0-040600rc6

Please send to the linux-usb@vger.kernel.org mailing list.

Hi 

I can report exactly the same with kernel 4.6.3-1-default (Tumbleweed).

Additional information is the DA200 ethernet/HDMI works perfectly on Windows 10 (dual boot). I also have a Belkin USB C to Ethernet adapter that works perfectly (F2CU040) on Linux. The HDMI also does not work under Linux.

I have a similar problem and as a first cut I'll connect it here. My problem is that my USB 3.0 to ethernet adapter connection does not survive suspend/resume. The kernel version is 4.6x, and the relevant dmesg and lspci output follows. In the dmesg output, the resume entries are at 37-38 seconds. The entries at 114+ seconds are associated with a mechanical unplug/replug. The machine is a Samsung Ativ Book 9 laptop with pretty much all Intel components. I purchased the USB 3.0 to Ethernet adapter on eBay out of Hong Kong, listing no. 281805664341, and it's labeled IOCREST, ~$15.00. The adapter claims to use a Realtek RTL8153 chip and that's why I tried this particular one. The Samsung is a dual boot machine and the linux-problematic adapter suspend/resumes fine under Windows 10.

[    0.000000] Linux version 4.6.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 5.4.0 20160609 (Debian 5.4.0-6) ) #1 SMP Debian 4.6.4-1 (2016-07-18)
[    2.831169] usb 3-2: new SuperSpeed USB device number 3 using xhci_hcd
[    2.847709] usb 3-2: New USB device found, idVendor=0bda, idProduct=8153
[    2.847710] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[    2.847711] usb 3-2: Product: USB 10/100/1000 LAN
[    2.847712] usb 3-2: Manufacturer: Realtek
[    2.847712] usb 3-2: SerialNumber: 000001000000
[    2.979239] usb 3-2: reset SuperSpeed USB device number 3 using xhci_hcd
[    3.021331] r8152 3-2:1.0 eth0: v1.08.3
[    3.024897] r8152 3-2:1.0 enx00e04c68212b: renamed from eth0
[   37.628897] usb 3-2: usb_reset_and_verify_device Failed to disable LTM
[   38.020235] usb 3-2: USB disconnect, device number 3
[  114.625867] usb 3-2: new SuperSpeed USB device number 4 using xhci_hcd
[  114.642450] usb 3-2: New USB device found, idVendor=0bda, idProduct=8153
[  114.642457] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[  114.642461] usb 3-2: Product: USB 10/100/1000 LAN
[  114.642464] usb 3-2: Manufacturer: Realtek
[  114.642467] usb 3-2: SerialNumber: 000001000000
[  114.758143] usb 3-2: reset SuperSpeed USB device number 4 using xhci_hcd
[  114.800204] r8152 3-2:1.0 eth0: v1.08.3
[  114.824156] r8152 3-2:1.0 enx00e04c68212b: renamed from eth0

00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09)
00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09)
00:04.0 Signal processing controller: Intel Corporation Broadwell-U Camarillo Device (rev 09)
00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03)
00:16.0 Communication controller: Intel Corporation Wildcat Point-LP MEI Controller #1 (rev 03)
00:1b.0 Audio device: Intel Corporation Wildcat Point-LP High Definition Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #3 (rev e3)
00:1d.0 USB controller: Intel Corporation Wildcat Point-LP USB EHCI Controller (rev 03)
00:1f.0 ISA bridge: Intel Corporation Wildcat Point-LP LPC Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation Wildcat Point-LP SATA Controller [AHCI Mode] (rev 03)
00:1f.3 SMBus: Intel Corporation Wildcat Point-LP SMBus Controller (rev 03)
01:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 20)

I have just tested the behavior of my IOCREST USB ethernet adapter, previous comment for more details, against the v4.9 kernel. The ethernet connection which did not survive suspend/resume under kernel v4.6 survives suspend/resume using the v4.9 kernel. However, the USB device number assigned to the adapter now increases upon each resume. I don't know if this is kosher or not, but the behavior differs from the other three USB attached devices. I've used rtcwake to automate a number of suspend/resume cycles and nothing appears untoward other than the increase of the USB device number for the ethernet adapter. As far as I am concerned, my problem is fixed. However, I would appreciate a comment from someone who knows something about any potential downside of increasing the device number for a USB device upon each resume.

Well, since I was wondering about the increasing USB device number situation, I performed a few more tests. It turns out that if the IOCREST USB ethernet device is connected and the internal USB connected wireless device is connected, the machine hangs when entering the suspend state. This is a hard repeatable hang. This behavior is also new to the v4.9 kernel, it does not occur when using the v4.6 kernel. Of course the USB wired ethernet connection still does not survice resume when using the 4.6 kernel.

I can't say definitively because the machine is hanging on suspend and I can't isolate any particular kernel ring buffer message, but I'm pretty certain that the new v4.9 suspend hang issue is related to an interaction between the USB connected atheros10k wifi adapter and the USB connected rtl8153 wired ethernet adapter. In one sense the v4.9 situation is an improvement upon the v4.6 situation. As long as I make sure to disconnect the wireless connection when I connect the wired USB adapter I can suspend/resume successfully. And as long as I disconnect the USB ethernet adapter when I connect wirelessly I can also suspend/resume successfully. But I would still label this a significant issue. Also, in another sense this could be classified as a regression in that under the v4.6 kernel there was no possibility of a hard suspend hang.

I've just completed testing against the 4.9.0-2 kernel and I no longer see the increasing USB device number upon each suspend/resume cycle. Further, I've done some more testing against the suspend hand and I now think it likely that the hang upon suspend problem is connected to the ath10k wifi device rather than the IOCREST rtl8153 device. I'm going to monitor this issue for a while longer but I think it likely that the rtl8153 device is working reasonably well with the Debian 4.9.0-2 kernel.

I got the same issue with two rtl8153-based usb adapters. I disabled USB autosuspend in tlp
USB_AUTOSUSPEND=0
and now everything works fine.

Hello,

which file is used to configure this USB_AUTOSUSPEND=0 ?

Thanks

It is /etc/default/tlp if you have tlp installed. Or you can disable it from command line or using a custom script:
echo on | tee /sys/bus/usb/devices/*/power/control

This seems to solve the issue for me as well. Thank you!

I finally got around to looking at my issue a bit more and it turns out that my suspend hang and other related issues are definitely connected to the Atheros QCA6174 wireless adapter. At some point I'll file a bug against the Atheros driver and/or firmware. 

The USB rtl8153 device is working well with the Debian 4.0.0-2 and now 4.9.0-4 kernel. The increasing USB device number on each suspend resume cycle that I saw in the initial v4.9 kernels is no longer present.