USB over thunderbolt turns off every once in a while

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1766076

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.16 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17-rc2

I had this issue previously under Zesty and I think it was gone under Artful (though I'm not sure - the dock started having hardware issues at that point). I just upgraded to Bionic *and* got a new dock, and almost immediately started having these issues.

I'll try the mainline build tomorrow.

I can confirm this is a regression between Artful and Bionic.

I downloaded the 4.17-rc3 kernel yesterday afternoon, and it seems to be stable for me.

I'm going to try to make time to bisect which commit contains the fix, which will likely take a couple of weeks. Since the dock is at work I'll be able to test at most one build each evening before I go home, and probably no builds on some nights.

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

@Branan any luck?

This should be fixed in latest Bionic kernel.

I've been running a few days now with the main line kernel 4.18.3 (from Ubuntu's main line kernel downloads), and I just got this again:

[72740.609531] xhci_hcd 0000:0e:00.0: xHCI host not responding to stop endpoint command.
[72740.609850] xhci_hcd 0000:0e:00.0: xHCI host controller not responding, assume dead
[72740.609882] usb 4-1.1.1: Failed to suspend device, error -22
[72740.609882] xhci_hcd 0000:0e:00.0: HC died; cleaning up
[72740.609926] usb 3-1: USB disconnect, device number 2
[72740.609930] usb 3-1.1: USB disconnect, device number 3
[72740.609932] usb 3-1.1.1: USB disconnect, device number 5
[72740.609935] usb 3-1.1.1.1: USB disconnect, device number 7
[72740.609938] usb 3-1.1.1.1.4: USB disconnect, device number 9
[72740.609994] usb 4-1: USB disconnect, device number 2
[72740.609996] usb 4-1.1: USB disconnect, device number 3
[72740.609997] usb 4-1.1.1: USB disconnect, device number 5
[72740.610718] usb 4-1.2: USB disconnect, device number 4
[72740.846065] usb 3-1.1.1.3: USB disconnect, device number 11
[72740.910812] usb 3-1.1.1.5: USB disconnect, device number 10
[72740.911322] usb 3-1.1.5: USB disconnect, device number 6
[72740.912038] usb 3-1.5: USB disconnect, device number 4

I'll change to the latest Bionic kernel and let you know if I can repro that.

Sorry, I missed the important line from the dmesg log. It should be:

[72735.678702] xhci_hcd 0000:0e:00.0: ERROR unknown event type 15
[72740.609531] xhci_hcd 0000:0e:00.0: xHCI host not responding to stop endpoint command.
[72740.609850] xhci_hcd 0000:0e:00.0: xHCI host controller not responding, assume dead
[72740.609882] usb 4-1.1.1: Failed to suspend device, error -22
[72740.609882] xhci_hcd 0000:0e:00.0: HC died; cleaning up
[72740.609926] usb 3-1: USB disconnect, device number 2
[72740.609930] usb 3-1.1: USB disconnect, device number 3
[72740.609932] usb 3-1.1.1: USB disconnect, device number 5
[72740.609935] usb 3-1.1.1.1: USB disconnect, device number 7
[72740.609938] usb 3-1.1.1.1.4: USB disconnect, device number 9
[72740.609994] usb 4-1: USB disconnect, device number 2
[72740.609996] usb 4-1.1: USB disconnect, device number 3
[72740.609997] usb 4-1.1.1: USB disconnect, device number 5
[72740.610718] usb 4-1.2: USB disconnect, device number 4
[72740.846065] usb 3-1.1.1.3: USB disconnect, device number 11
[72740.910812] usb 3-1.1.1.5: USB disconnect, device number 10
[72740.911322] usb 3-1.1.5: USB disconnect, device number 6
[72740.912038] usb 3-1.5: USB disconnect, device number 4

Do all of you use Precision 5520 + TB16?

Just got the issue again with latest Bionic kernel (Precision 5520 + TB16):

[253938.395439] xhci_hcd 0000:0e:00.0: ERROR unknown event type 15
[253943.344375] xhci_hcd 0000:0e:00.0: xHCI host not responding to stop endpoint command.
[253943.344704] xhci_hcd 0000:0e:00.0: xHCI host controller not responding, assume dead
[253943.344865] xhci_hcd 0000:0e:00.0: HC died; cleaning up
[253943.344953] usb 3-1: USB disconnect, device number 2
[253943.344955] usb 3-1.1: USB disconnect, device number 3
[253943.344957] usb 3-1.1.1: USB disconnect, device number 6
[253943.344960] usb 3-1.1.1.1: USB disconnect, device number 8
[253943.344963] usb 3-1.1.1.1.4: USB disconnect, device number 10
[253943.345081] usb 4-1: USB disconnect, device number 2
[253943.345083] usb 4-1.1: USB disconnect, device number 3
[253943.345086] usb 4-1.1.1: USB disconnect, device number 5
[253943.346372] usb 4-1.2: USB disconnect, device number 4
[253943.489086] usb 3-1.1.1.3: USB disconnect, device number 13
[253943.556882] usb 3-1.1.1.5: USB disconnect, device number 12
[253943.557415] usb 3-1.1.2: USB disconnect, device number 11
[253943.557687] usb 3-1.1.5: USB disconnect, device number 7
[253943.558220] usb 3-1.3: USB disconnect, device number 4
[253943.558465] usb 3-1.5: USB disconnect, device number 5

uname:

Linux vesho 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Ok, please make sure both BIOS and TBT are up-to-date.
You can update them by doing the following:
$ fwupdmgr refresh
$ fwupdmgr update
$ sudo reboot

Apparently there's a firmware update (I was running 1.10, which is about a month old - I've updated the firmware several times during the life time of this bug). I'll update and wait for it to happen again.

BTW - the behavior is usually that after this disconnect happens once, I can reset the USB controller (using sysfs API to unbind and re-bind xhci_hcd), but then it will get the problem again and again, several times an hour (its not very predictable, sometimes I get 2 in a row and sometimes half an hour can pass before it breaks again). I thought this can be temperature related, so I pushed the computer to low power mode after the first event of the day, and reset the bus, but it happened again.

I had to downgrade the BIOS back to 1.10.1 (fwupdmgr installed 1.11) as under the new firmware suspend to RAM caused the system to completely power off (i.e. boot from scratch when powering on). I'll try to update again when the new update is released on Dell's website (the current version on the website is 1.10.1, so I can't even report an bug about the firmware update).

But I doubt this issue will be resolved by a firmware update - as mentioned in my previous comment, this bug has survived numerous firmware update: the original bug report was using BIOS 1.7 and it still happens in 1.10.1.

Thank for the info! This is something Dell should know.

Other than BIOS, is the Thunderbolt firmware up-to-date?

The last TB firmware was released 2018-04, and it is up to date (also according to fwupdmgr).

Sorry for the late reply, I'll start look into this issue.

Does your laptop draw the power from TB16 or from power adapter?

I have also experienced this issue on both a 5520 and 7720.

Currently running `apport-collect 1766076` and updating firmware. Will monitor and see if the issue continues & update the bug accordingly.

ProblemType: Bug
ApportVersion: 2.20.9-0ubuntu7.4
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: katamo 12313 F.... pulseaudio
 /dev/snd/controlC3: katamo 12313 F.... pulseaudio
 /dev/snd/controlC0: katamo 12313 F.... pulseaudio
CurrentDesktop: GNOME
DistroRelease: Ubuntu 18.04
HibernationDevice: RESUME=UUID=639e9a98-76fc-4156-9d01-fe50f93ad7bd
InstallationDate: Installed on 2018-07-07 (109 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
MachineType: Dell Inc. Precision 7720
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
Package: linux (not installed)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic root=/dev/mapper/ubuntu--vg-root ro debug intel_iommu=on kvm.ignore_msrs=1 default_hugepagesz=2M hugepagesz=2M hugepages=4096 transparent_hugepage=never
ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
RelatedPackageVersions:
 linux-restricted-modules-4.15.0-38-generic N/A
 linux-backports-modules-4.15.0-38-generic N/A
 linux-firmware 1.173.1
Tags: bionic
Uname: Linux 4.15.0-38-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip libvirt lpadmin lxd plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 04/14/2017
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.3.2
dmi.board.name: 017JKT
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 10
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr1.3.2:bd04/14/2017:svnDellInc.:pnPrecision7720:pvr:rvnDellInc.:rn017JKT:rvrA00:cvnDellInc.:ct10:cvr:
dmi.product.family: Precision
dmi.product.name: Precision 7720
dmi.sys.vendor: Dell Inc.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

I've been running disco for a while with `generic` Ubuntu kernel 5.0.0 (currently 5.0.0-8), and I haven't experienced that problem for a while.

I still get some USB issues from time to time with the Dell dock - where the USB does not connect when I plug the dock to the laptop, at which point I pull the TB plug out and connect it again and it is usually OK (sometimes it takes a couple of tries), but I no longer see "unknown event" errors and the USB no longer dies in the middle of a work day.

I never booted into Windows at any point - neither for a firmware upgrade nor for the "reset workaround". I'm updating firmware using the BIOS update facility and I'm currently running Firmware version 1.12.0 which comes with TB controller firmware version 26.01.

Still seeing this on 5.0.6. PPA mainline. Booting windows prior to linux is WAR for me. Dell 5530 w/TB16. Don't think it is fixed in 5.

Still seeing this on 5.0.8 mainline. Connecting a USB device after a few hours results in this:

[17093.624705] usb 3-1.1: USB disconnect, device number 7
[17144.801167] usb 3-1.1: new high-speed USB device number 8 using xhci_hcd
[17145.201116] usb 3-1.1: New USB device found, idVendor=04e8, idProduct=6860, bcdDevice= 4.00
[17145.201119] usb 3-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[17145.201121] usb 3-1.1: Product: SAMSUNG_Android
[17145.201123] usb 3-1.1: Manufacturer: SAMSUNG
[17145.201124] usb 3-1.1: SerialNumber: REDACTED
[17147.966175] usb 3-1.1: USB disconnect, device number 8
[17153.161110] xhci_hcd 0000:0e:00.0: xHCI host not responding to stop endpoint command.
[17153.169934] xhci_hcd 0000:0e:00.0: xHCI host controller not responding, assume dead
[17153.169953] r8152 4-1.2:1.0 eth0: Tx status -108
[17153.169954] r8152 4-1.2:1.0 eth0: Tx status -108
[17153.169955] r8152 4-1.2:1.0 eth0: Tx status -108
[17153.169957] r8152 4-1.2:1.0 eth0: Tx status -108
[17153.169980] xhci_hcd 0000:0e:00.0: HC died; cleaning up
[17153.170181] usb 3-1: USB disconnect, device number 2
[17153.170187] usb 4-1: USB disconnect, device number 2
[17153.170189] usb 4-1.2: USB disconnect, device number 3
[17153.170760] usb 3-1.4: USB disconnect, device number 5
[17153.193302] bridge-eth0: disabling the bridge on dev down
[17153.193426] bridge-eth0: down
[17153.194899] bridge-eth0: detached
[17153.194939] /dev/vmnet: open called by PID 1961 (vmnet-bridge)
[17153.194944] /dev/vmnet: hub 0 does not exist, allocating memory.
[17153.194956] /dev/vmnet: port on hub 0 successfully opened
[17153.194962] bridge-wlan0: device is wireless, enabling SMAC
[17153.194964] bridge-wlan0: up
[17153.194965] bridge-wlan0: attached
[17153.277696] usb 3-1.5: USB disconnect, device number 3
[17153.278118] usb 3-1.6: USB disconnect, device number 4
[17153.393326] userif-3: sent link down event.
[17153.393328] userif-3: sent link up event.

Daisy-chained DP monitors connected to the dock still work, reconnecting the dock fixes it.

Dell 5530 fw1.8.1 w/TB16 fw 1.0.2. Tested on 5.0.9-200.fc29.x86_64.

Can confirm that my WAR still works. If I reboot Win10 prior to booting Linux, it is stable. Even if I undock and dock it through the day.

If I reboot Linux twice, it fails after minutes, definitely within 15min. Haven't tested yet on Ubuntu 19.04 with 5.0.9-050009-generic mainline (PPA) yet, but I expect it will be the same.

Things were pretty stable on 1.0.0 fw and kernels upto 4.18.18.

Is it a xhci_hcd return code that is not handled properly from Dell TB16 (and some other thunderbolt) docks?

I haven't had that issue for a while, since kernel 4.20, I think, but I just had this issue again, on up to date 19.04 with kernel 5.0.0-13:

[376539.800632] xhci_hcd 0000:0e:00.0: ERROR unknown event type 15
[376544.914548] xhci_hcd 0000:0e:00.0: xHCI host not responding to stop endpoint command.
[376544.914869] xhci_hcd 0000:0e:00.0: xHCI host controller not responding, assume dead
[376544.914937] xhci_hcd 0000:0e:00.0: HC died; cleaning up
[376544.914941] usb 3-1.5: Failed to suspend device, error -22
[376544.914948] usb 4-1.1.1: Failed to suspend device, error -22
[376544.914956] usb 3-1: USB disconnect, device number 2
[376544.914957] usb 3-1.1: USB disconnect, device number 3
[376544.914958] usb 3-1.1.1: USB disconnect, device number 5
[376544.914959] usb 3-1.1.1.4: USB disconnect, device number 8
[376544.915173] usb 4-1: USB disconnect, device number 2
[376544.915174] usb 4-1.1: USB disconnect, device number 3
[376544.915175] usb 4-1.1.1: USB disconnect, device number 5
[376544.915595] usb 4-1.2: USB disconnect, device number 4
[376544.958908] usb 3-1.1.1.5: USB disconnect, device number 11
[376544.959744] usb 3-1.1.2: USB disconnect, device number 7
[376544.959746] usb 3-1.1.2.4: USB disconnect, device number 10
[376545.175240] usb 3-1.1.5: USB disconnect, device number 9
[376545.175890] usb 3-1.5: USB disconnect, device number 6
[376545.176578] usb 3-1.6: USB disconnect, device number 12

Then the USB hub died while DP over Thunderbolt monitors continue to work.

Firmware versions:
Precision M5520 Thunderbolt Controller: 26.01
Dell Thunderbolt Dock: 16.00
Precision 5520 System Firmware: 0.1.13.0

This has happened a few times already - as I was writing up this report - and I worked around them by either power cycling the dock (pulling the power cable - the power button on the dock powers down the laptop), or running the XHCI reset script I'm pasting below.

Regarding other workarounds - at no point did I boot to MS-Windows (or at least not in the last half a year).

This is the XHCI reset script I'm using - it lists XHCI devices and runs the unbind-rebind process specified in the original bug report. The next step would be a SystemD service that monitors the kernel log for the "xHCI assume dead" line and triggers the rebind automatically :-/

```
#!/bin/bash
tbtid="$(ls /sys/bus/pci/drivers/xhci_hcd/ | grep '[0-9]')"
echo "Resetting thunderbolt bus">&2
for id in $tbtid; do
  echo -n $id > /sys/bus/pci/drivers/xhci_hcd/unbind
done
sleep 1
for id in $tbtid; do
  echo -n $id > /sys/bus/pci/drivers/xhci_hcd/bind
done
echo "Done resetting thunderbolt bus">&2
```

I'm running into a similar issue with an HP Zbook Studio G4 running Ubuntu 18.04, HP Thunderbolt 3 dock and an IOGEAR 3.0/4 Port Peripheral Sharing Switch (GUS434). Often shortly after I switch back to the HP using the USB switch I get the xHCI host controller not responding, assume dead message. Based on Oded's input above I created the following service to fix it for me:

/lib/systemd/system/xhci-watch.service
```
[Unit]
Description=Restart xhci when it dies

[Service]
ExecStart=/path/to/restart-xhci.sh

[Install]
WantedBy=multi-user.target
```

script:
```
#!/bin/bash
dmesg -l err -w -T | awk -F " " '
        /xhci_hcd.*dead/ {
                system("sleep 1");
                device=substr($7, 1, length($7)-1);

                cmd="echo -n \""device"\" | tee /sys/bus/pci/drivers/xhci_hcd/unbind";
                system(cmd);

                system("sleep 1");

                cmd="echo -n \""device"\" | tee /sys/bus/pci/drivers/xhci_hcd/bind";
                system(cmd);

                notify="notify-send \"restarting "device" \" \""$0"\" -u critical -i face-worried";
                system(notify);
         }'

```

obviously this is an ugly hack, but it might help some while a better fix is developed. My bash/awk skills are not the best, so please feel free to offer suggestions for improvement

My current complete workaround is documented here: https://gist.github.com/guss77/1356e5f3be4f2acbc73053cc6d3c0b1c

In case this is useful: updating the Dell XPS 15 9560 BIOS to 0.1.14.2 and Dell TB16 dock and component firmware (packaged as version 1.0.2) seems to have resolved this for me. It's been a week and I haven't seen the issue since: previously, I was seeing it around once per day. I've been unable to trigger it by e.g. connecting various USB devices (USB-A storage &/or network adaptor, USB-C HDMI adaptor) to every port on the dock and laptop. I have two Dell U2715H monitors connected via one mini-DP to DP cable, daisy chained to the second monitor, and a few USB storage devices occasionally connected to the docking station's USB-A ports.

I'm running on Linux kernel version 5.0.10 under Arch Linux (5.0.10-arch1-1-ARCH). I had to boot into Windows and run the update several (6?) times to successfully update all the various components shown on the docking station. I *think* the Multi Stream Transport (MST) firmware 3.12.002 is the fix. This firmware is still marked as "State: testing" on the Linux Vendor Firmware Service (https://fwupd.org/lvfs/device/com.dell.mst0a52c8c7.firmware).

Laptop BIOS 0.1.14.2 is not on LVFS and was also not offered via Dell Command Update: I had to visit Dell's support site to download it. However, that download now seems to have been removed from their site: https://www.dell.com/support/home/uk/en/ukbsdt1/product-support/product/xps-15-9560-laptop/drivers

```
~
➜ fwupdmgr get-topology○├─ XPS 9560 Thunderbolt Controller 3695fe182ca17c53702255daf8b4f73612bd0d2b
├─ XPS 15 9560 System Firmware f49999b6e3af5b4bf8ad1f2ed2922b76df457271
├─ Dell TB16 84edf044a6b53037732cfc7591b65a8d36384cc9
│ ├─ Dell Thunderbolt Cable b75fc95a2b3a77f2fc6895c651a92fd9c0a23be3
│ ├─ Dell Thunderbolt Dock 8a0e9a12b51f3e5f328df1feb145d18f88aebccf
│ ├─ Dell TB16 Thunderbolt Cable f8194a42320518472a2e67c1d89018c7a5219841
│ ├─ Dell TB16 Port Controller 1 b3fa3dc04e3450450bb17910417562e5b6cf69d0
│ └─ Dell TB16 Port Controller 2 4bcf1477575b55912993240dd1edd8b0ebb6d491
├─ Unifying Receiver fb1a5fd6e7d8cbf5d5a2ba7df68aee106ce41027
└─ PM961 NVMe SAMSUNG 1024GB 04e17fcf7d3de91da49a163ffe4907855c3648be

~
➜ fwupdmgr update -v
No upgrades for XPS 9560 Thunderbolt Controller, current is 21.00: 21.00=same
No upgrades for XPS 15 9560 System Firmware, current is 0.1.14.2: 0.1.12.1=older, 0.1.11.0=older, 0.1.10.1=older, 0.1.9.4=older, 0.1.7.1=older, 0.1.6.2=older, 0.1.5.0=older, 0.1.4.0=older, 0.1.3.4=older, 0.1.3.3=older, 0.1.2.4=older, 0.1.1.3=older, 0.1.0.3=older
ignoring XPS 15 9560 TPM 2.0 [cc2b222929056ab3e9a208df9f86b7d9a74ae514] as not updatable
No upgrades for Unifying Receiver, current is RQR12.08_B0030: RQR12.08_B0030=same, RQR12.07_B0029=older

~
➜
```

I have a similar problem with a USB mouse, except in my case:
* Unplugging the mouse from the dock and replugging it fixes the problem.
* If I do nothing, the kernel appears to disconnect and reconnect the mouse with a new device number, and it works again until the next hang.

Dell Precision 5530
Ubuntu 18.04 with latest HWE kernel (5.0.0-32-generic)
Latest 5530 BIOS (1.13.0)
Latest TB16 Firmware

I have dual-boot linux/windows and all PC / dock drivers are up to date according to the Dell Command Update running in Windows 10.

dmesg from one disconnect / reconnect cycle - mouse froze around 60 seconds before this was logged

Oct 27 14:26:00 bart kernel: [ 812.823105] usb 5-1.7: USB disconnect, device number 9
Oct 27 14:26:00 bart upowerd[1431]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:1b.0/0000:02:00.0/0000:03:01.0/0000:05:00.0/0000:06:04.0/0000:08:00.0/0000:09:01.0/0000:0a:00.0/usb5/5-1/5-1.7/5-1.7:1.0/0003:045E:00CB.000C
Oct 27 14:26:00 bart upowerd[1431]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:1b.0/0000:02:00.0/0000:03:01.0/0000:05:00.0/0000:06:04.0/0000:08:00.0/0000:09:01.0/0000:0a:00.0/usb5/5-1/5-1.7/5-1.7:1.0
Oct 27 14:26:00 bart upowerd[1431]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:1b.0/0000:02:00.0/0000:03:01.0/0000:05:00.0/0000:06:04.0/0000:08:00.0/0000:09:01.0/0000:0a:00.0/usb5/5-1/5-1.7
Oct 27 14:26:02 bart kernel: [ 814.327542] usb 5-1.7: new low-speed USB device number 10 using xhci_hcd
Oct 27 14:26:02 bart kernel: [ 814.488191] usb 5-1.7: New USB device found, idVendor=045e, idProduct=00cb, bcdDevice= 1.00
Oct 27 14:26:02 bart kernel: [ 814.488196] usb 5-1.7: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Oct 27 14:26:02 bart kernel: [ 814.488200] usb 5-1.7: Product: Microsoft USB Optical Mouse
Oct 27 14:26:02 bart kernel: [ 814.488202] usb 5-1.7: Manufacturer: PixArt
Oct 27 14:26:02 bart kernel: [ 814.549584] input: PixArt Microsoft USB Optical Mouse as /devices/pci0000:00/0000:00:1b.0/0000:02:00.0/0000:03:01.0/0000:05:00.0/0000:06:04.0/0000:08:00.0/0000:09:01.0/0000:0a:00.0/usb5/5-1/5-1.7/5-1.7:1.0/0003:045E:00CB.000D/input/input39
Oct 27 14:26:02 bart kernel: [ 814.550251] hid-generic 0003:045E:00CB.000D: input,hidraw5: USB HID v1.11 Mouse [PixArt Microsoft USB Optical Mouse] on usb-0000:0a:00.0-1.7/input0
Oct 27 14:26:02 bart mtp-probe: checking bus 5, device 10: "/sys/devices/pci0000:00/0000:00:1b.0/0000:02:00.0/0000:03:01.0/0000:05:00.0/0000:06:04.0/0000:08:00.0/0000:09:01.0/0000:0a:00.0/usb5/5-1/5-1.7"
Oct 27 14:26:02 bart mtp-probe: bus: 5, device: 10 was not an MTP device
Oct 27 14:26:02 bart boltd[1049]: probing: started [1000]
Oct 27 14:26:02 bart upowerd[1431]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:1b.0/0000:02:00.0/0000:03:01.0/0000:05:00.0/0000:06:04.0/0000:08:00.0/0000:09:01.0/0000:0a:00.0/usb5/5-1/5-1.7/5-1.7:1.0/0003:045E:00CB.000D
Oct 27 14:26:02 bart upowerd[1431]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:1b.0/0000:02:00.0/0000:03:01.0/0000:05:00.0/0000:06:04.0/0000:08:00.0/0000:09:01.0/0000:0a:00.0/usb5/5-1/5-1.7/5-1.7:1.0
Oct 27 14:26:02 bart upowerd[1431]: unhandled action 'bind' on /sy...

Dell Precision 5530
Latest 5530 BIOS (1.13.0)
ikling usb-c hub
5.0.0-32-generic

I dont think this has anything to do with the Dell HUB as noted above Im not using it but some off brand. Using ethernet, hdmi and one usb 3.0 port. I see the screen attached every 30 minutes or so go blank then become active within a second or two. At this time I also lose network and the USB. All devices come back but it disrupts vpn connections. Its extremely problematic. This is also connected to a usb kvm switch which I use to flip between the two systems. I have not noticed this bouncing back and forth to be related so I dont think disconnects of usb devices impact it. I see similar logs as those posting above.

The lastest journal log I saw right when I lost connectivity to HDMI and ethernet follows. There was no other logs associated. No clue if this is relevant.

Nov 14 14:52:32 deimos kernel: perf: interrupt took too long (4998 > 4990), lowering kernel.perf_event_max_sample_rate to 40000

I just went back to using my Precision 5520 with the TB16 dock, after that duo was benched for a few months while I waited for a replacement battery to be shipped, and now the situation is similar but worse:

Every time I connect the dock cable, Linux tries to attached the USB hub, fails and disconnects the XHcI bus. Running the reset script details above (basically running "unbind" and the "bind" with the dock's bus address) allows the bus to be usable, though often it takes a couple of tries.

Attached is the dmesg log from connection through the error and the reset (timepoint documented in the log itself).

Interesting things that may or may not be related:
1. it takes a *very*long*time* for the system to connect the USB devices: the reset command occurred at 455, all the devices except the mouse got connected by 458 (13 seconds), with the mouse waiting until 471 (there were a few errors in the log specific to the logitech-hidpp-device, probably related).
2. I see a lot of `BAR 13: no space for [io size 0xXXXX]` in dmesg, followed by `BAR 13: failed to assign [io size 0xXXXX]`.

I'm running eoan full updated with kernel 5.3.0-24-generic. I have ran all the BIOS firmware updates and the MS-Windows "Dell Precision Optimizer" system updates including the Thunderbolt controller driver update.

Here's the fwupdmgr report:

```
Precision M5520 Thunderbolt Controller
  DeviceId: 51d36e5f8f25bea1d8707a72ab7b9386a98527ee
  Guid: c5364422-2ec3-5092-b30e-03bdb1a53e4a
  Summary: Unmatched performance for high-speed I/O
  Plugin: thunderbolt
  Flags: internal|updatable|require-ac|registered
  Vendor: Dell
  VendorId: TBT:0x00D4
  Version: 26.01
  VersionFormat: pair
  Icon: computer
  Created: 2019-12-09

Dell Thunderbolt Cable
  DeviceId: aa4dfab63945b6e8ad913550d241978e3562f8bf
  ParentDeviceId: 84edf044a6b53037732cfc7591b65a8d36384cc9
  Guid: b4fd3cdf-4e3a-5090-a583-45367cfd6421
  Plugin: thunderbolt
  Flags: updatable|require-ac|registered
  Vendor: Dell
  VendorId: TBT:0x00D4
  Version: 16.00
  VersionFormat: pair
  Icon: audio-card
  Created: 2019-12-09

Dell Thunderbolt Dock
  DeviceId: 64575ad9f31dbe3959942f4b2275c1c4d0ac2ac5
  ParentDeviceId: 84edf044a6b53037732cfc7591b65a8d36384cc9
  Guid: 76cc74d4-f062-5b93-a11c-8d2a58a25848
  Plugin: thunderbolt
  Flags: updatable|require-ac|registered
  Vendor: Dell
  VendorId: TBT:0x00D4
  Version: 16.00
  VersionFormat: pair
  Icon: audio-card
  Created: 2019-12-09

Precision 5520 System Firmware
  DeviceId: f49999b6e3af5b4bf8ad1f2ed2922b76df457271
  Guid: 34578c72-11dc-4378-bc7f-b643866f598c
  Plugin: uefi
  Flags: internal|updatable|require-ac|supported|registered|needs-reboot
  Checksum: SHA1(de646f75ada7857150e2c6263d...

The delay to connect the USB devices seems to be a feature of the new firmware or something - on MS-Windows it takes even longer, about 30 seconds for all the devices to finish connecting. Could it be that the xhci_hcd failure is caused by the fact that the dock is now so slow to respond?

Anyway, that problem doesn't seem related to the "unknown event type 15" issue that this ticket is probably about, even though they both show "xHCI host not responding to stop endpoint command" - which is probably a symptom and not a cause. I'll be opening a new report for the thunderbolt connection issue.

For those who don't use Ubuntu, please see if reverting this helps:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9da5a1092b13468839b1a864b126cacfb72ad016

For Ubuntu users please test the following kernel:
https://people.canonical.com/~khfeng/lp1766076/

Just had the "unknown event type 15" error happen again, with the lp1766076 kernel and current firmware:

---8<---
Dec 25 11:19:34 vesho kernel: xhci_hcd 0000:0e:00.0: ERROR unknown event type 15
Dec 25 11:19:39 vesho kernel: xhci_hcd 0000:0e:00.0: xHCI host not responding to stop endpoint command.
Dec 25 11:19:39 vesho kernel: xhci_hcd 0000:0e:00.0: xHCI host controller not responding, assume dead
Dec 25 11:19:39 vesho kernel: xhci_hcd 0000:0e:00.0: HC died; cleaning up
Dec 25 11:19:39 vesho kernel: usb 4-1.3.1: Failed to suspend device, error -22
Dec 25 11:19:39 vesho kernel: usb 3-1: USB disconnect, device number 2
Dec 25 11:19:39 vesho kernel: usb 3-1.3: USB disconnect, device number 4
Dec 25 11:19:39 vesho kernel: usb 3-1.3.1: USB disconnect, device number 5
Dec 25 11:19:39 vesho kernel: usb 3-1.3.1.4: USB disconnect, device number 9
Dec 25 11:19:39 vesho kernel: usb 4-1: USB disconnect, device number 2
Dec 25 11:19:39 vesho kernel: usb 4-1.2: USB disconnect, device number 3
Dec 25 11:19:39 vesho kernel: usb 3-1.3.1.5: USB disconnect, device number 11
Dec 25 11:19:39 vesho kernel: usb 3-1.3.2: USB disconnect, device number 6
Dec 25 11:19:39 vesho kernel: usb 3-1.3.2.4: USB disconnect, device number 8
Dec 25 11:19:39 vesho kernel: usb 4-1.3: USB disconnect, device number 4
Dec 25 11:19:39 vesho kernel: usb 4-1.3.1: USB disconnect, device number 5
Dec 25 11:19:39 vesho kernel: usb 3-1.3.4: USB disconnect, device number 7
Dec 25 11:19:39 vesho kernel: usb 3-1.3.5: USB disconnect, device number 10
Dec 25 11:19:39 vesho kernel: usb 3-1.5: USB disconnect, device number 3
---8<---

Firmware versions:
[Dell] Precision 5520 System Firmware: 0.1.16.0
[Dell] Precision M5520 Thunderbolt Controller: 26.01
[Dell] Dell TB16 Thunderbolt Cable: 0.0.3.18
[Dell] Dell TB16 Port Controller 1: 0.1.2.17
[Dell] Dell TB16 Port Controller 2: 0.1.2.50
[Synaptics] Synaptics VMM3320 inside Dell WD15/TB16/TB18 wired Dock: 3.10.002
[Dell] Dell Thunderbolt Dock: 16.00
[Dell] Dell Thunderbolt Cable: 16.00
[Dell] Dell TB16: 0.0.0.0

I have the same issue with a i-tec displaylink docking station. My OS is the ubuntu based linux mint 19.2 with kernel version 5.3.0-46-generic.

Here is the output from dmesg:

2020-04-09T08:49:10,389752+0200 evdi: [D] evdi_detect:92 (dev=2) poll connector state: connected
2020-04-09T08:49:10,389754+0200 evdi: [D] evdi_painter_get_edid_copy:230 (dev=2) EDID valid
2020-04-09T08:49:10,390033+0200 evdi: [D] evdi_detect:92 (dev=1) poll connector state: connected
2020-04-09T08:49:10,390034+0200 evdi: [D] evdi_painter_get_edid_copy:230 (dev=1) EDID valid
2020-04-09T08:49:40,559834+0200 evdi: [D] evdi_detect:92 (dev=2) poll connector state: connected
2020-04-09T08:49:40,559837+0200 evdi: [D] evdi_painter_get_edid_copy:230 (dev=2) EDID valid
2020-04-09T08:49:40,560091+0200 evdi: [D] evdi_detect:92 (dev=1) poll connector state: connected
2020-04-09T08:49:40,560092+0200 evdi: [D] evdi_painter_get_edid_copy:230 (dev=1) EDID valid
2020-04-09T08:50:01,121386+0200 usb 1-11: USB disconnect, device number 22
2020-04-09T08:50:01,121388+0200 usb 1-11.2: USB disconnect, device number 23
2020-04-09T08:50:01,121389+0200 usb 1-11.2.3: USB disconnect, device number 26
2020-04-09T08:50:01,122564+0200 usb 1-11.4: USB disconnect, device number 24
2020-04-09T08:50:01,122566+0200 usb 1-11.4.2: USB disconnect, device number 25
2020-04-09T08:50:01,912856+0200 usb 4-1: USB disconnect, device number 6
2020-04-09T08:50:01,912859+0200 usb 4-1.1: USB disconnect, device number 7
2020-04-09T08:50:01,914212+0200 cdc_ncm 4-1.1:1.5 enx0050b6f14a15: unregister 'cdc_ncm' usb-0000:39:00.0-1.1, CDC NCM
2020-04-09T08:50:01,958297+0200 usb 4-1.2: USB disconnect, device number 8
2020-04-09T08:50:01,963393+0200 usb 4-1.4: USB disconnect, device number 9
2020-04-09T08:50:01,990922+0200 evdi: [D] evdi_painter_disconnect:708 (dev=1) Disconnected from 0000000062b3a6bc
2020-04-09T08:50:01,990926+0200 evdi: [D] evdi_detect:96 (dev=-1) poll connector state: disconnected
2020-04-09T08:50:01,990980+0200 evdi: [D] evdi_driver_postclose:144 (dev=-1) Process tries to close us, postclose
2020-04-09T08:50:01,990983+0200 evdi: [I] Task 11693 (DesktopManagerE) of process 11675 (DisplayLinkMana)
2020-04-09T08:50:01,997589+0200 evdi: [D] evdi_painter_disconnect:708 (dev=2) Disconnected from 00000000856d041f
2020-04-09T08:50:01,997593+0200 evdi: [D] evdi_detect:96 (dev=-1) poll connector state: disconnected
2020-04-09T08:50:01,997646+0200 evdi: [D] evdi_driver_postclose:144 (dev=-1) Process tries to close us, postclose
2020-04-09T08:50:01,997648+0200 evdi: [I] Task 11693 (DesktopManagerE) of process 11675 (DisplayLinkMana)
2020-04-09T08:50:02,047886+0200 evdi: [D] evdi_detect:96 (dev=-1) poll connector state: disconnected
2020-04-09T08:50:02,047907+0200 evdi: [D] evdi_detect:96 (dev=-1) poll connector state: disconnected
2020-04-09T08:50:02,048648+0200 evdi: [D] evdi_detect:96 (dev=-1) poll connector state: disconnected
2020-04-09T08:50:02,048687+0200 evdi: [D] evdi_detect:96 (dev=-1) poll connector state: disconnected
2020-04-09T08:50:02,184977+0200 evdi: [D] evdi_detect:96 (dev=-1) poll connector state: disconnected
2020-04-09T08:50:02,184998+0200 evdi: [D] evdi_detect:96 (dev=-1) poll connector state: dis...

Disabling Thunderbolt Security in the BIOS stops this from happening. This was the only workaround that worked for me.
Not saying this is a fix, but this may help you in finding the root cause.

Please try enable "kernel DMA protection", this is the most security option.

Disabling Thunderbolt Security in the BIOS did not help.
My BIOS has no Kernel DMA protection.

Any other ideas?

Laptop: XPS 15 9570
BIOS Information
 Vendor: Dell Inc.
 Version: 1.15.0
 Release Date: 12/25/2019

Ubuntu 20.04 LTS
Uname: 5.4.0-29-generic #33-Ubuntu SMP Wed Apr 29 14:32:27 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

TB16 with latest firmware (3 jan 2019)

Fully reproducible:
When the "User Authorization" Thunderbolt security feature is enabled, USB devices plugged in to the TB16 randomly disconnect.
When "No security" is set, this does not happen.

Log:
May 6 20:34:55 user-XPS-15-9570 kernel: [ 657.090759] usb 5-1.4.4: USB disconnect, device number 30
May 6 20:34:55 user-XPS-15-9570 acpid: input device has been disconnected, fd 25
May 6 20:34:55 user-XPS-15-9570 acpid: input device has been disconnected, fd 27
May 6 20:34:55 user-XPS-15-9570 kernel: [ 657.579631] usb 5-1.4.4: new full-speed USB device number 31 using xhci_hcd
May 6 20:34:55 user-XPS-15-9570 kernel: [ 657.720769] usb 5-1.4.4: New USB device found, idVendor=24f0, idProduct=0140, bcdDevice= 1.00
May 6 20:34:55 user-XPS-15-9570 kernel: [ 657.720774] usb 5-1.4.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
May 6 20:34:55 user-XPS-15-9570 kernel: [ 657.720778] usb 5-1.4.4: Product: Das Keyboard
May 6 20:34:55 user-XPS-15-9570 kernel: [ 657.720781] usb 5-1.4.4: Manufacturer: Metadot - Das Keyboard
May 6 20:34:55 user-XPS-15-9570 kernel: [ 657.730571] input: Metadot - Das Keyboard Das Keyboard as /devices/pci0000:00/0000:00:1b.0/0000:02:00.0/0000:03:01.0/0000:05:00.0/0000:06:04.0/0000:08:00.0/0000:09:01.0/0000:0a:00.0/usb5/5-1/5-1.4/5-1.4.4/5-1.4.4:1.0/0003:24F0:0140.0036/input/input109
May 6 20:34:55 user-XPS-15-9570 kernel: [ 657.788516] hid-generic 0003:24F0:0140.0036: input,hidraw5: USB HID v1.10 Keyboard [Metadot - Das Keyboard Das Keyboard] on usb-0000:0a:00.0-1.4.4/input0
May 6 20:34:55 user-XPS-15-9570 kernel: [ 657.790664] input: Metadot - Das Keyboard Das Keyboard System Control as /devices/pci0000:00/0000:00:1b.0/0000:02:00.0/0000:03:01.0/0000:05:00.0/0000:06:04.0/0000:08:00.0/0000:09:01.0/0000:0a:00.0/usb5/5-1/5-1.4/5-1.4.4/5-1.4.4:1.1/0003:24F0:0140.0037/input/input110
May 6 20:34:55 user-XPS-15-9570 kernel: [ 657.848086] input: Metadot - Das Keyboard Das Keyboard Consumer Control as /devices/pci0000:00/0000:00:1b.0/0000:02:00.0/0000:03:01.0/0000:05:00.0/0000:06:04.0/0000:08:00.0/0000:09:01.0/0000:0a:00.0/usb5/5-1/5-1.4/5-1.4.4/5-1.4.4:1.1/0003:24F0:0140.0037/input/input111
May 6 20:34:55 user-XPS-15-9570 kernel: [ 657.848589] hid-generic 0003:24F0:0140.0037: input,hidraw6: USB HID v1.10 Device [Metadot - Das Keyboard Das Keyboard] on usb-0000:0a:00.0-1.4.4/input1
May 6 20:34:55 user-XPS-15-9570 mtp-probe: checking bus 5, device 31: "/sys/devices/pci0000:00/0000:00:1b.0/0000:02:00.0/0000:03:01.0/0000:05:00.0/0000:06:04.0/0000:08:00.0/0000:09:01.0/0000:0a:00.0/usb5/5-1/5-1.4/5-1.4.4"
May 6 20:34:55 user-XPS-15-9570 mtp-probe: bus: 5, device: 31 was not an MTP device
May 6 20:34:56 user-XPS-15-9570 boltd[1432]: probing: started [1000]
May 6 20:34:56 user-XPS-15-9570 mtp-probe: checking bus 5, device 31: "/sys/devices/pci0000:00/0000:00:1b.0/0000:02:00.0/0000:03:01.0/0000:05:00.0/0000:06:04.0/0000:08:00.0/0000:09:01.0/0000:0a:00.0...

Having the same or at least similar issue on a DELL XPS13 (9360) D600 Dock. The thunderbolt connection suddenly drops for a few seconds and the automatically reconnects again. Screens go blank for that time and all peripherals also gets disconnected. This happens randomly but at least twice an hour. All firmware is up-to-date.

OS: Ubuntu 20.04 LTS (5.4.0-40-generic)
Hardware: DELL XPS 13 (9360); Intel Core i7-7500U CPU, 8GB RAM
Dock: DELL D600 (with two 1080p monitors connected over DisplayPort)

Here the dmesg:
[ 4088.809311] show_signal_msg: 3032 callbacks suppressed
[ 4088.809314] ActiveCommandQu[6618]: segfault at 7f244c19f000 ip 0000000000998e9e sp 00007f244e7fa438 error 4 in DisplayLinkManager[400000+937000]
[ 4088.809321] Code: 3d db fb c4 c1 3d 72 d0 08 c4 e3 fd 00 d7 d8 c5 bd db fb c5 6d f9 d8 c5 ed fd d0 c5 ed fd d0 c5 ed fd c9 c5 fd 6f 17 4c 01 cf <c5> 7d 6f 17 c5 f5 71 d1 02 c5 ed db c3 c5 ed 72 d2 08 c5 7d 6f 24
[ 4093.927731] evdi: [D] evdi_driver_postclose:133 (dev=2) Process tries to close us, postclose
[ 4093.927733] evdi: [I] Task 1148 (DesktopManagerE) of process 1139 (DisplayLinkMana)
[ 4093.927736] evdi: [D] evdi_painter_disconnect:817 (dev=2) Disconnected from 000000009024a4f0
[ 4093.927739] evdi: [D] evdi_detect:94 (dev=-1) poll connector state: disconnected
[ 4093.927788] evdi: [D] evdi_driver_postclose:133 (dev=1) Process tries to close us, postclose
[ 4093.927789] evdi: [I] Task 1148 (DesktopManagerE) of process 1139 (DisplayLinkMana)
[ 4093.927791] evdi: [D] evdi_painter_disconnect:817 (dev=1) Disconnected from 00000000a19585cf
[ 4093.927792] evdi: [D] evdi_detect:94 (dev=-1) poll connector state: disconnected
[ 4094.278010] evdi: [D] evdi_detect:94 (dev=-1) poll connector state: disconnected
[ 4094.278026] evdi: [D] evdi_detect:94 (dev=-1) poll connector state: disconnected
[ 4094.278039] evdi: [D] evdi_detect:94 (dev=-1) poll connector state: disconnected
[ 4094.278048] evdi: [D] evdi_detect:94 (dev=-1) poll connector state: disconnected
[ 4094.278058] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[ 4094.278064] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[ 4094.278072] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[ 4094.278078] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[ 4094.278514] evdi: [D] evdi_painter_dpms_notify:654 (dev=-1) Notifying dpms mode: 3
[ 4094.278515] evdi: [W] evdi_painter_send_event:307 Painter is not connected!
[ 4094.597176] evdi: [D] evdi_detect:94 (dev=-1) poll connector state: disconnected
[ 4094.597190] evdi: [D] evdi_detect:94 (dev=-1) poll connector state: disconnected
[ 4094.597202] evdi: [D] evdi_detect:94 (dev=-1) poll connector state: disconnected
[ 4094.597210] evdi: [D] evdi_detect:94 (dev=-1) poll connector state: disconnected
[ 4094.597220] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[ 4094.597227] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[ 4094.597237] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[ 4094.597245] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[ 4094.761411] evdi: [D] evdi_pai...

@ #97

Correct me if I'm wrong, but the DELL D6000 is a DisplayLink dock in stead of a Thunderbolt dock.
I would open a new bug for this.

Responding to earlier statement in #93:
Replaced the TB16 (240W) with a WD19TB (180W) and issue disappeared. Also no issues with thunderbolt user authorization setting enabled.

Maybe the hardware differences (usb hub e.g.) between these docks can help you guys identify the problem.

Setting thunderbolt to No Security on my device (XPS 9500 with Ubuntu 20.10) fixes the random disconnect, but input devices still randomly stop working.
The only way to fix this is to unplug them and plug them back in.

When they stop working there is no disconnect message, or any other message, in my dmesg.

Just to clarify. My peripherals are still powered on, show up in lsusb, and /proc/bus/input/devices, but no input is captured by my desktop. Happens on both Wayland and X11.

Should I open a new bug for this? Seems to be related to the USB hub in the TB16.

Found this in my syslog but no indication of why it happens.

`[ 4231.104191] usb 5-1.3: reset low-speed USB device number 15 using xhci_hcd`

This is annoying I bought a Gigbyte 4 TB tb3(usb-c) drive to daisy chain, but it disconnects and I have to restart to get it back, and I also lose access to the things down the chain...

I used to run into this regularly before and just recently ran into it again with the TB16. Previously I had the same issue with a different USB hub without a dock, occurring both on Windows and Linux Dell 5520 and Dell XPS 9560. Without the dock both systems were able to recover. With the dock, only Windows recovers successfully.

I believe this is related to USB bandwidth exhaustion triggering a reset in some edge case. Windows recovers from this after a bit even with the dock, whereas on Linux having it occur with the dock in the chain seems to be preventing recovery.

The issue is that with the dock and a daisy-chained USB hub you end up with too much stuff hanging off a single wire or possibly a single controller. It could be about power draw, heat, 5 Gigs of USB3 not being able to fit more than a single 480 Mbit USB2 bus, or that even the 5 Gigs are actually getting saturated.

The reset will only occur sporadically when all USB devices happen to be under heavy load at the same instant.

Attached the lsusb output from the USB-heavy XPS 9560+TB16 setup that triggers this every 20 minutes when actively using ethernet, audio interfaces, the USB3 NVME SSD and the Android device in an IDE.

Georgi, if you can afford it I would switch from the TB16 to the WD19TB. The latter works much better from my experience and what I read online.

I have a new issue now with the WD19TB though where GNOME constantly reconfigures the Thunderbolt device (the Thunderbolt icon in the top right notification area frequently appears). It usually does not cause any issues, but it seems like something is happening that should not happen.

I wonder if there are at least two different bugs here...

I have a very similar issue with a WD19TB under Ubuntu 20.04 (Dell Latitude 5410) and desperately browsing the net, looking for solutions.

Everything works fine until I resume from suspend. Then all USB devices connected to the dock start having failures (like missing key presses for the keyboard, mouse becoming sluggish until the device is disconnected, or sound becoming bad, also I suspect the ethernet port of the dock doesn't work well anymore).

This is most likely *not* a thunderbolt authorization issue (I tried all the security modes: no security/user based/key based, all show the same behavior), which is a definite difference with many reports I found here and there (and makes it hard to find the same exact one as the one I have).

The present issues description from the opener seems close enough, including dmesg output (although the opener had a Dell 16TB dock).

#106 - please open a separate issue to debug this. The architecture for the WD19TB is very different than the TB16 and it shouldn't be conflated into this issue. The most interesting things to include in your issue - please first try this kernel: https://launchpad.net/ubuntu/+source/linux-oem-5.10. If it persists, can you please open an issue with 'ubuntu-bug linux-oem-5.10' which will attach all the logs to your issue?

I'm pretty confident I'm experiencing this same issue with a TB16 on "Dell Inc. XPS 15 7590/0VYV0G, BIOS 1.9.1 12/14/2020"

1. I'm able to reset my USB without unplugging/plugging with a "fix_usb" script which does:

echo -n "0000:3a:00.0" | sudo tee /sys/bus/pci/drivers/xhci_hcd/unbind
echo -n "0000:3a:00.0" | sudo tee /sys/bus/pci/drivers/xhci_hcd/bind

2. [ 315.161687] usb 3-1.5: 2:1: usb_set_interface failed (-19)
[ 315.161727] usb 3-1.5: Not enough bandwidth for altsetting 1

I also have a Dell 9380 I've used with this dock, and I've been able to reduce the frequency of the disconnects by installing either `laptop-mode-tools` or `tlp` and setting RUNTIME_PM_DRIVER_BLACKLIST="amdgpu nouveau nvidia pcieport radeon"

This forces the "MEI" device to stay "on" rather than "auto" from a PM perspective.

I experience this primarily with my USB keyboard/mouse (happens with wired/wireless and Logitech/Razer). Best ways to reproduce quickly:
1. use a USB webcam, then stop using it. About 1 in 4 times this will lock up my mouse or keyboard.
2. let the computer go to display sleep and this will frequently prevent waking via the USB keyboard/mouse.

I'm presently running 20.04 with linux-generic-hwe-20.04.

I'm going to test the latest 5.10 as instructed above.

My keyboard just dropped out after a few hours with `5.10.0-1008-oem` build. It's working again after the unbind/bind sequence from above.

Few months ago I gave up and stopped using my TB18. Easier to connect few cables once a day than fight with this. I'm much happier now. TB18 serves as an expensive laptop stand for me (elevates laptop 5 cm from table).

#110 (Toumas) - I no longer experience this problem when running 20.10 with the latest kernel and the latest Dell firmware update (fwupdmgr works reasonably well, but you can also just download the firmware file from Dell, put it on a USB dok and the preboot screen lets you apply it directly - no MS-Windows needed).

That being said, when I had the most serious problems, the small script attached below would take care of things semi-automatically or automatically (follow step 4 in the header doc for completely automated recovery - when the dock crashes, wait a few seconds and it'll auto recover).

#!/bin/bash

### Installation Instructions:
# 1. Install file into `/usr/local/bin/reset-tb`
#
# 2. Optional: allow password less sudo by creating a file `/etc/sudoers.d/allow-reset-tb` with the following content:
# ----8<-----
# <your username> ALL = NOPASSWD: /usr/local/bin/reset-tb
# ----8<-----
#
# 3. Optional: allow easy access from the menu by creating a file `$HOME/.local/share/applications/Reset Thunderbolt.desktop` with the following content:
# ----8<-----
# [Desktop Entry]
# Exec=bash -c 'sudo -S /usr/local/bin/reset-tb'
# Icon=amarok_playlist_refresh
# Name=Reset Thunderbolt
# NoDisplay=false
# StartupNotify=false
# ----8<-----
#
# 4. Optional: run a service to automatically trigger the reset and send you an email when "unknown event type 15" error is detected, by setting your email
# in this file below, then creating a file `/etc/systemd/system/auto-reset-tb.service` with the following content:
# ----8<-----
# [Unit]
# Description=Automatically reset XHCI USB bus when detecting a Thunderbolt dock error
# [Service]
# ExecStart=/usr/local/bin/reset-tb -l
# [Install]
# WantedBy=multi-user.target
# ----8<-----
# Then run:
# ```
# sudo systemctl daemon-reload
# sudo systemctl enable auto-reset-tb
# sudo systemctl start auto-reset-tb
# ```

<email address hidden>
SUBJECT="Detected Thunderbolt error in your system"
MESSAGE="
Check the logs, please.
"

function do_reset() {
        tbtid="$(ls /sys/bus/pci/drivers/xhci_hcd/ | grep '[0-9]' | tail -n1)"
        echo "Resetting thunderbolt bus">&2
        for id in $tbtid; do
                echo -n $id > /sys/bus/pci/drivers/xhci_hcd/unbind
        done
        sleep 1
        for id in $tbtid; do
                echo -n $id > /sys/bus/pci/drivers/xhci_hcd/bind
        done
        echo "Done resetting thunderbolt bus" >&2
}

function listen_for_reset() {
        dmesg -w | while read line; do
                [[ "$line" =~ "xHCI host controller not responding, assume dead" ]] || continue
                (
                        sleep 15 # let the busses settle
                        do_reset
                        sleep 90 # don't reset too much
                )&
                mail -s "$SUBJECT" $EMAIL <<< "$MESSAGE Date: $(date -R)"
        done
}

[ "$1" == "-l" ] && listen_for_reset || do_reset

I still experience this on 21.04 unfortunately. It might be a different bug though.

For me now, it mostly happens when suspending the laptop while connected to the Dock. After resuming I get constant resets...

#106 The described symptoms are so specific that it would be a really surprising coincidence if my issue had a different cause with so identical symptoms.

Are you sure this is really about the dock?
What if it was actually about the thunderbolt controller on the motherboard instead?
I assume most people who post here also have similar computers (being Dell consumers).

Another argument supporting this theory: the system switches to the faulty mode after a suspend/resume of the computer. Nothing you do with just the dock triggers the faulty mode until you suspend/resume the computer and, after that, nothing you do with the dock (including powering it down and up again) will switch the system back to the non-faulty mode until the computer is powered down. Moreover the system switches to faulty mode as soon as a computer suspend/resume occurs, even if no thunderbolt dock was actually plugged in yet when the computer was suspended.

Of course I don't know what are the results of the investigations so far, so I may be completely wrong. But then it would be very interesting to know the explanation.

#107 (sorry, my previous message was meant as an answer to #107 too!)

Incidentally, linux-oem-5.10 does not fix this my issue (with a WB19TB dock).

Does this kernel work well with the TB16?

What are the relevant logs I should join to my bug report to linux-oem-5.10? Is dmesg output enough?

I've been experiencing the same problem on 20.04 with a different HW setup: Lenovo thinkpad X1 Carbon gen7 (BIOS, thunderbolt controller, etc... firmware all fully up to date), and an Alogic Thunderbolt 3.0 Docking Station.

It generally works fine, but every now and then, the xhci controller in the dock itself stops working causing by webcam to vanish.

Interestingly no other function of the dock stops: DP still works, USB1/2 devices too such as my headset, keyboard and mouse.

It may or may not be the same problem. Next time it happens I'll try capturing the relevant logs.

I just started experiencing this issue again, last week. Same hardware: Precision 5520 with thunderbolt dock Dell TB-16. Kernel 5.11.0-22-generic on hirsute.

---8<---
Jun 27 14:53:11 vesho kernel: xhci_hcd 0000:0e:00.0: ERROR unknown event type 15
Jun 27 14:53:16 vesho kernel: xhci_hcd 0000:0e:00.0: xHCI host not responding to stop endpoint command.
Jun 27 14:53:16 vesho kernel: xhci_hcd 0000:0e:00.0: USBSTS:
Jun 27 14:53:16 vesho kernel: xhci_hcd 0000:0e:00.0: xHCI host controller not responding, assume dead
Jun 27 14:53:16 vesho kernel: xhci_hcd 0000:0e:00.0: HC died; cleaning up
Jun 27 14:53:16 vesho kernel: usb 3-1: USB disconnect, device number 2
Jun 27 14:53:16 vesho kernel: usb 3-1.1: USB disconnect, device number 3
Jun 27 14:53:16 vesho kernel: usb 3-1.1.1: USB disconnect, device number 5
Jun 27 14:53:16 vesho kernel: usb 3-1.1.1.4: USB disconnect, device number 7
Jun 27 14:53:16 vesho kernel: usb 4-1: USB disconnect, device number 2
Jun 27 14:53:16 vesho kernel: usb 4-1.1: USB disconnect, device number 3
Jun 27 14:53:16 vesho kernel: usb 4-1.2: USB disconnect, device number 4
Jun 27 14:53:16 vesho kernel: usb 3-1.1.4: USB disconnect, device number 6
Jun 27 14:53:16 vesho kernel: usb 3-1.1.5: USB disconnect, device number 9
Jun 27 14:53:16 vesho kernel: usb 3-1.5: USB disconnect, device number 4
Jun 27 14:53:16 vesho kernel: usb 3-1.6: USB disconnect, device number 8
Jun 27 14:53:16 vesho kernel: usb 3-1.6.4: USB disconnect, device number 10
Jun 27 14:53:16 vesho kernel: usb 3-1.6.5: USB disconnect, device number 11
---8<---