USB over thunderbolt turns off every once in a while

Bug #1766076 reported by Oded Arbel
174
This bug affects 31 people
Affects Status Importance Assigned to Milestone
Dell Sputnik
New
Undecided
Unassigned
linux (Ubuntu)
Incomplete
Medium
Unassigned

Bug Description

I'm using a USB hub in the Dell TB16 (240W) connected to a Dell Precision 5520 using Thunderbolt 3.

Every so often (can be several times in an hour if I'm really unlucky, some days it is less of a problem), the USB hub disconnects from the computer and the devices connected to it lose power and stop responding.

disconnecting and reconnecting the USB cables has no effect. I can restore functionality by instructing the xhci_hcd driver to unbind from the USB 3.0 Host Controller in the dock and to rebind to it using the commands:

echo -n "0000:0e:00.0" > /sys/bus/pci/drivers/xhci_hcd/unbind
echo -n "0000:0e:00.0" > /sys/bus/pci/drivers/xhci_hcd/bind

Here's the dmesg output when the USB hub disconnects:

279278.102701] xhci_hcd 0000:0e:00.0: ERROR unknown event type 15
[279283.021802] xhci_hcd 0000:0e:00.0: xHCI host not responding to stop endpoint command.
[279283.022145] xhci_hcd 0000:0e:00.0: xHCI host controller not responding, assume dead
[279283.022161] r8152 4-1.2:1.0 enxd481d731b2b1: Tx status -108
[279283.022199] xhci_hcd 0000:0e:00.0: HC died; cleaning up
[279283.022227] usb 3-1.5: Failed to suspend device, error -22
[279283.022234] usb 3-1: USB disconnect, device number 2
[279283.022235] usb 3-1.1: USB disconnect, device number 3
[279283.022236] usb 3-1.1.1: USB disconnect, device number 5
[279283.022237] usb 3-1.1.1.1: USB disconnect, device number 8
[279283.022238] usb 3-1.1.1.1.4: USB disconnect, device number 11
[279283.022326] usb 4-1: USB disconnect, device number 2
[279283.022328] usb 4-1.1: USB disconnect, device number 3
[279283.022329] usb 4-1.1.1: USB disconnect, device number 5
[279283.022998] usb 4-1.2: USB disconnect, device number 4
[279283.191217] usb 3-1.1.1.5: USB disconnect, device number 9
[279283.191730] usb 3-1.1.3: USB disconnect, device number 6
[279283.260810] usb 3-1.1.5: USB disconnect, device number 7
[279283.261350] usb 3-1.5: USB disconnect, device number 4

Here's dmesg output during the USB host controller reset:

279389.813889] xhci_hcd 0000:0e:00.0: remove, state 1
[279389.813894] usb usb4: USB disconnect, device number 1
[279389.814103] xhci_hcd 0000:0e:00.0: USB bus 4 deregistered
[279389.814107] xhci_hcd 0000:0e:00.0: remove, state 1
[279389.814110] usb usb3: USB disconnect, device number 1
[279389.881651] xhci_hcd 0000:0e:00.0: USB bus 3 deregistered
[279389.882133] xhci_hcd 0000:0e:00.0: xHCI Host Controller
[279389.882138] xhci_hcd 0000:0e:00.0: new USB bus registered, assigned bus number 3
[279389.949391] xhci_hcd 0000:0e:00.0: hcc params 0x0200e081 hci version 0x100 quirks 0x10000410
[279389.949979] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
[279389.949981] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[279389.949982] usb usb3: Product: xHCI Host Controller
[279389.949983] usb usb3: Manufacturer: Linux 4.15.0-15-generic xhci-hcd
[279389.949983] usb usb3: SerialNumber: 0000:0e:00.0
[279389.950117] hub 3-0:1.0: USB hub found
[279389.950135] hub 3-0:1.0: 2 ports detected
[279389.950310] xhci_hcd 0000:0e:00.0: xHCI Host Controller
[279389.950314] xhci_hcd 0000:0e:00.0: new USB bus registered, assigned bus number 4
[279389.951098] usb usb4: We don't know the algorithms for LPM for this host, disabling LPM.
[279389.951117] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003
[279389.951119] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[279389.951120] usb usb4: Product: xHCI Host Controller
[279389.951121] usb usb4: Manufacturer: Linux 4.15.0-15-generic xhci-hcd
[279389.951122] usb usb4: SerialNumber: 0000:0e:00.0
[279389.951306] hub 4-0:1.0: USB hub found
[279389.951321] hub 4-0:1.0: 2 ports detected
[279390.299396] usb 4-1: new SuperSpeed USB device number 2 using xhci_hcd
[279390.321750] usb 4-1: New USB device found, idVendor=0424, idProduct=5807
[279390.321752] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[279390.321753] usb 4-1: Product: USB5807 Hub
[279390.321754] usb 4-1: Manufacturer: Microchip
[279390.341684] hub 4-1:1.0: USB hub found
[279390.342312] hub 4-1:1.0: 7 ports detected
[279390.513286] usb 3-1: new high-speed USB device number 2 using xhci_hcd
[279390.750013] usb 3-1: New USB device found, idVendor=0424, idProduct=2807
[279390.750015] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[279390.750016] usb 3-1: Product: USB2807 Hub
[279390.750017] usb 3-1: Manufacturer: Microchip
[279390.769651] hub 3-1:1.0: USB hub found
[279390.769793] hub 3-1:1.0: 7 ports detected
[279390.839440] usb 4-1.1: new SuperSpeed USB device number 3 using xhci_hcd
[279390.861567] usb 4-1.1: New USB device found, idVendor=0424, idProduct=5734
[279390.861568] usb 4-1.1: New USB device strings: Mfr=2, Product=3, SerialNumber=0
[279390.861569] usb 4-1.1: Product: USB5734
[279390.861570] usb 4-1.1: Manufacturer: Microchip Tech
[279390.881472] hub 4-1.1:1.0: USB hub found
[279390.882171] hub 4-1.1:1.0: 5 ports detected
[279390.991442] usb 4-1.2: new SuperSpeed USB device number 4 using xhci_hcd
[279391.015809] usb 4-1.2: New USB device found, idVendor=0bda, idProduct=8153
[279391.015811] usb 4-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[279391.015812] usb 4-1.2: Product: USB 10/100/1000 LAN
[279391.015813] usb 4-1.2: Manufacturer: Realtek
[279391.015814] usb 4-1.2: SerialNumber: 000001000000
[279391.089207] usb 3-1.1: new high-speed USB device number 3 using xhci_hcd
[279391.211462] usb 3-1.1: New USB device found, idVendor=0424, idProduct=2734
[279391.211481] usb 3-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[279391.211482] usb 3-1.1: Product: USB2734
[279391.211483] usb 3-1.1: Manufacturer: Microchip Tech
[279391.231366] hub 3-1.1:1.0: USB hub found
[279391.231502] hub 3-1.1:1.0: 5 ports detected
[279391.302796] usb 4-1.2: reset SuperSpeed USB device number 4 using xhci_hcd
[279391.355371] usb 4-1.2: Dell TB16 Dock, disable RX aggregation
[279391.370639] r8152 4-1.2:1.0 (unnamed net_device) (uninitialized): Using pass-thru MAC addr d4:81:d7:31:b2:b1
[279391.401126] usb 3-1.5: new high-speed USB device number 4 using xhci_hcd
[279391.425377] r8152 4-1.2:1.0 eth0: v1.09.9
[279391.588750] usb 3-1.5: New USB device found, idVendor=0bda, idProduct=4014
[279391.588752] usb 3-1.5: New USB device strings: Mfr=3, Product=1, SerialNumber=2
[279391.588754] usb 3-1.5: Product: USB Audio
[279391.588755] usb 3-1.5: Manufacturer: Generic
[279391.588757] usb 3-1.5: SerialNumber: 200901010001
[279391.663127] usb 4-1.1.1: new SuperSpeed USB device number 5 using xhci_hcd
[279391.685637] usb 4-1.1.1: New USB device found, idVendor=0424, idProduct=5734
[279391.685639] usb 4-1.1.1: New USB device strings: Mfr=2, Product=3, SerialNumber=0
[279391.685640] usb 4-1.1.1: Product: USB5734
[279391.685641] usb 4-1.1.1: Manufacturer: Microchip Tech
[279391.812609] hub 4-1.1.1:1.0: USB hub found
[279391.813185] hub 4-1.1.1:1.0: 5 ports detected
[279391.973147] usb 3-1.1.1: new high-speed USB device number 5 using xhci_hcd
[279392.095383] usb 3-1.1.1: New USB device found, idVendor=0424, idProduct=2734
[279392.095386] usb 3-1.1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[279392.095388] usb 3-1.1.1: Product: USB2734
[279392.095389] usb 3-1.1.1: Manufacturer: Microchip Tech
[279392.104109] r8152 4-1.2:1.0 enxd481d731b2b1: renamed from eth0
[279392.165057] IPv6: ADDRCONF(NETDEV_UP): enxd481d731b2b1: link is not ready
[279392.187087] IPv6: ADDRCONF(NETDEV_UP): enxd481d731b2b1: link is not ready
[279392.398705] hub 3-1.1.1:1.0: USB hub found
[279392.398894] hub 3-1.1.1:1.0: 5 ports detected
[279392.625122] usb 3-1.1.3: new full-speed USB device number 6 using xhci_hcd
[279392.884608] usb 3-1.1.3: New USB device found, idVendor=046d, idProduct=c52b
[279392.884609] usb 3-1.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[279392.884610] usb 3-1.1.3: Product: USB Receiver
[279392.884611] usb 3-1.1.3: Manufacturer: Logitech
[279392.934819] logitech-djreceiver 0003:046D:C52B.0091: hiddev1,hidraw3: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:0e:00.0-1.1.3/input2
[279393.062222] logitech-hidpp-device 0003:046D:402D.0092: hidraw4: USB HID v1.11 Keyboard [Logitech M560] on usb-0000:0e:00.0-1.1.3:1
[279393.133173] usb 3-1.1.5: new high-speed USB device number 7 using xhci_hcd
[279393.260962] usb 3-1.1.5: New USB device found, idVendor=0424, idProduct=274c
[279393.260965] usb 3-1.1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[279393.260966] usb 3-1.1.5: Product: Hub Controller
[279393.260967] usb 3-1.1.5: Manufacturer: Microchip Tech
[279393.337238] usb 3-1.1.1.1: new high-speed USB device number 8 using xhci_hcd
[279393.463217] usb 3-1.1.1.1: New USB device found, idVendor=05e3, idProduct=0608
[279393.463236] usb 3-1.1.1.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[279393.463237] usb 3-1.1.1.1: Product: USB2.0 Hub
[279393.839721] hid-generic 0003:0424:274C.0093: hiddev2,hidraw5: USB HID v1.10 Device [Microchip Tech Hub Controller] on usb-0000:0e:00.0-1.1.5/input0
[279393.857686] hub 3-1.1.1.1:1.0: USB hub found
[279393.858162] hub 3-1.1.1.1:1.0: 4 ports detected
[279393.985185] usb 3-1.1.1.5: new high-speed USB device number 9 using xhci_hcd

Software:

Ubuntu bionic beta
Uname: Linux xxxxx 4.15.0-15-generic #16-Ubuntu SMP Wed Apr 4 13:58:14 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

lspci:

00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 05)
00:01.0 PCI bridge: Intel Corporation Skylake PCIe Controller (x16) (rev 05)
00:02.0 VGA compatible controller: Intel Corporation Device 591b (rev 04)
00:04.0 Signal processing controller: Intel Corporation Skylake Processor Thermal Subsystem (rev 05)
00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller (rev 31)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-H Thermal subsystem (rev 31)
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-H Serial IO I2C Controller #0 (rev 31)
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-H Serial IO I2C Controller #1 (rev 31)
00:16.0 Communication controller: Intel Corporation Sunrise Point-H CSME HECI #1 (rev 31)
00:17.0 SATA controller: Intel Corporation Sunrise Point-H SATA controller [AHCI mode] (rev 31)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #1 (rev f1)
00:1c.1 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #2 (rev f1)
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #9 (rev f1)
00:1d.4 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #13 (rev f1)
00:1d.6 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #15 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-H LPC Controller (rev 31)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-H PMC (rev 31)
00:1f.3 Audio device: Intel Corporation CM238 HD Audio Controller (rev 31)
00:1f.4 SMBus: Intel Corporation Sunrise Point-H SMBus (rev 31)
01:00.0 3D controller: NVIDIA Corporation GM107GLM [Quadro M1200 Mobile] (rev ff)
02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)
03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS525A PCI Express Card Reader (rev 01)
04:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961
06:00.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge [Alpine Ridge 2C 2015]
07:00.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge [Alpine Ridge 2C 2015]
07:01.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge [Alpine Ridge 2C 2015]
07:02.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge [Alpine Ridge 2C 2015]
08:00.0 System peripheral: Intel Corporation DSL6340 Thunderbolt 3 NHI [Alpine Ridge 2C 2015]
09:00.0 PCI bridge: Intel Corporation DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015]
0a:01.0 PCI bridge: Intel Corporation DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015]
0a:04.0 PCI bridge: Intel Corporation DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015]
0c:00.0 PCI bridge: Intel Corporation DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015]
0d:01.0 PCI bridge: Intel Corporation DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015]
0d:04.0 PCI bridge: Intel Corporation DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015]
0e:00.0 USB controller: ASMedia Technology Inc. ASM1042A USB 3.0 Host Controller
---
ApportVersion: 2.20.9-0ubuntu5
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/pcmC0D0p: odeda 2692 F...m pulseaudio
 /dev/snd/controlC0: odeda 2692 F.... pulseaudio
CurrentDesktop: KDE
DistroRelease: Ubuntu 18.04
HibernationDevice: RESUME=UUID=48b9dbd0-5260-48d5-bf45-a3785e48227b
InstallationDate: Installed on 2017-08-17 (247 days ago)
InstallationMedia: Kubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170725)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 003: ID 0cf3:e007 Atheros Communications, Inc.
 Bus 001 Device 004: ID 0c45:6713 Microdia
 Bus 001 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: Dell Inc. Precision 5520
Package: linux (not installed)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-15-generic.efi.signed root=UUID=5abbb78f-aade-4e35-b206-816fb83c5e6e ro rootflags=subvol=@ quiet splash acpi_osi=!Windows\\x202013 acpi_osi=Linux nogpumanager intel_iommu=on pcie_port_pm=off vt.handoff=1
ProcVersionSignature: Ubuntu 4.15.0-15.16-generic 4.15.15
RelatedPackageVersions:
 linux-restricted-modules-4.15.0-15-generic N/A
 linux-backports-modules-4.15.0-15-generic N/A
 linux-firmware 1.173
Tags: bionic
Uname: Linux 4.15.0-15-generic x86_64
UpgradeStatus: Upgraded to bionic on 2018-04-08 (14 days ago)
UserGroups: adm bumblebee cdrom dip docker libvirt lpadmin lxd plugdev sambashare sudo wireshark
_MarkForUpload: True
dmi.bios.date: 01/25/2018
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.7.1
dmi.board.name: 0R6JFH
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 10
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr1.7.1:bd01/25/2018:svnDellInc.:pnPrecision5520:pvr:rvnDellInc.:rn0R6JFH:rvrA00:cvnDellInc.:ct10:cvr:
dmi.product.family: Precision
dmi.product.name: Precision 5520
dmi.sys.vendor: Dell Inc.

Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Missing required logs.

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.

Changed in linux (Ubuntu):
status: New → Incomplete
tags: added: bionic
Revision history for this message
Oded Arbel (oded-geek) wrote : AlsaInfo.txt

apport information

tags: added: apport-collected
description: updated
Revision history for this message
Oded Arbel (oded-geek) wrote : CRDA.txt

apport information

Revision history for this message
Oded Arbel (oded-geek) wrote : CurrentDmesg.txt

apport information

Revision history for this message
Oded Arbel (oded-geek) wrote : IwConfig.txt

apport information

Revision history for this message
Oded Arbel (oded-geek) wrote : Lspci.txt

apport information

Revision history for this message
Oded Arbel (oded-geek) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
Oded Arbel (oded-geek) wrote : ProcCpuinfoMinimal.txt

apport information

Revision history for this message
Oded Arbel (oded-geek) wrote : ProcEnviron.txt

apport information

Revision history for this message
Oded Arbel (oded-geek) wrote : ProcInterrupts.txt

apport information

Revision history for this message
Oded Arbel (oded-geek) wrote : ProcModules.txt

apport information

Revision history for this message
Oded Arbel (oded-geek) wrote : PulseList.txt

apport information

Revision history for this message
Oded Arbel (oded-geek) wrote : RfKill.txt

apport information

Revision history for this message
Oded Arbel (oded-geek) wrote : UdevDb.txt

apport information

Revision history for this message
Oded Arbel (oded-geek) wrote : WifiSyslog.txt

apport information

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

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

Changed in linux (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Oded Arbel (oded-geek) wrote :

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.

Revision history for this message
Branan Purvine-Riley (branan) wrote :

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.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in linux (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Chuck LeDuc Díaz (celeduc-a) wrote :

@Branan any luck?

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

This should be fixed in latest Bionic kernel.

Revision history for this message
Oded Arbel (oded-geek) wrote :

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.

Revision history for this message
Oded Arbel (oded-geek) wrote :

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

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Do all of you use Precision 5520 + TB16?

Changed in linux (Ubuntu):
status: Expired → Confirmed
Revision history for this message
Oded Arbel (oded-geek) wrote :

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

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

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

Revision history for this message
Oded Arbel (oded-geek) wrote :

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.

Revision history for this message
Oded Arbel (oded-geek) wrote :

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.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

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

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

Revision history for this message
Oded Arbel (oded-geek) wrote :

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

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

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

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

Revision history for this message
Kathryn Morgan (katamo) wrote :

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.

Revision history for this message
Kathryn Morgan (katamo) wrote : apport information

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.

Revision history for this message
Kathryn Morgan (katamo) wrote : AlsaInfo.txt

apport information

Revision history for this message
Kathryn Morgan (katamo) wrote : CRDA.txt

apport information

Revision history for this message
Kathryn Morgan (katamo) wrote : CurrentDmesg.txt

apport information

Revision history for this message
Kathryn Morgan (katamo) wrote : IwConfig.txt

apport information

Revision history for this message
Kathryn Morgan (katamo) wrote : Lspci.txt

apport information

Revision history for this message
Kathryn Morgan (katamo) wrote : Lsusb.txt

apport information

Revision history for this message
Kathryn Morgan (katamo) wrote : ProcCpuinfo.txt

apport information

Changed in linux (Ubuntu):
assignee: nobody → Kai-Heng Feng (kaihengfeng)
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Changed in linux (Ubuntu):
assignee: Kai-Heng Feng (kaihengfeng) → nobody
36 comments hidden view all 116 comments
Revision history for this message
Oded Arbel (oded-geek) wrote :

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.

Revision history for this message
torel (torehl) wrote :

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.

Revision history for this message
Georgi Boiko (pandasauce) wrote :

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.

Revision history for this message
torel (torehl) wrote :

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?

Revision history for this message
Oded Arbel (oded-geek) wrote :

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
```

Revision history for this message
Greg Woodward (grw) wrote :

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

Revision history for this message
Oded Arbel (oded-geek) wrote :

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

Revision history for this message
CiaranM (ciaranm) wrote :

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

~

```

Revision history for this message
Barney (barney-b) wrote :
Download full text (3.3 KiB)

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

Read more...

Revision history for this message
Jason (jmnielsen09) wrote :

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.

Revision history for this message
Jason (jmnielsen09) wrote :

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

Revision history for this message
Oded Arbel (oded-geek) wrote :
Download full text (6.9 KiB)

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

Read more...

Revision history for this message
Oded Arbel (oded-geek) wrote :

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.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

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/

Revision history for this message
Oded Arbel (oded-geek) wrote :

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

Revision history for this message
Nikolai Strässle (nikolaistr) wrote :
Download full text (12.2 KiB)

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

Revision history for this message
snevas (snevas) wrote :

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.

Revision history for this message
AaronMa (mapengyu) wrote :

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

Revision history for this message
Nikolai Strässle (nikolaistr) wrote :

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

Any other ideas?

Revision history for this message
snevas (snevas) wrote :
Download full text (3.3 KiB)

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

Read more...

Revision history for this message
Viktor Aschenbrenner (lnx80usr) wrote :
Download full text (7.6 KiB)

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

Read more...

Revision history for this message
snevas (snevas) wrote :

@ #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.

Changed in linux (Ubuntu):
status: Incomplete → Opinion
status: Opinion → Confirmed
status: Confirmed → Incomplete
Jeff Lane  (bladernr)
tags: added: ubuntu-certified
Revision history for this message
snevas (snevas) wrote :

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.

Revision history for this message
Kai Mast (kai-mast) wrote :

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.

Revision history for this message
Kai Mast (kai-mast) wrote :

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.

Revision history for this message
Kai Mast (kai-mast) wrote :

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`

Revision history for this message
ike (ikeahloe) wrote :

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

Revision history for this message
Georgi Boiko (pandasauce) wrote :

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.

Revision history for this message
Kai Mast (kai-mast) wrote :

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

Revision history for this message
Aldoo (aldric-degorre) wrote :

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

Revision history for this message
Mario Limonciello (superm1) wrote :

#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?

Revision history for this message
David Rasch (rasch) wrote :

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.

Revision history for this message
David Rasch (rasch) wrote :

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.

Revision history for this message
Tuomas (tuma+sec) wrote :

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

Revision history for this message
Oded Arbel (oded-geek) wrote :

#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

Revision history for this message
Kai Mast (kai-mast) wrote :

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

Revision history for this message
Aldoo (aldric-degorre) wrote :

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

Revision history for this message
Aldoo (aldric-degorre) wrote :

#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?

Revision history for this message
Benjamin Herrenschmidt (benh-kernel) wrote :

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.

Revision history for this message
Oded Arbel (oded-geek) wrote :

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

Displaying first 40 and last 40 comments. View all 116 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.