System details: Operating System: openSUSE Tumbleweed Kernel: Linux 6.4.4-1-default Architecture: x86-64 Hardware Vendor: Lenovo Hardware Model: ThinkPad P72 Firmware Version: N2CET65W (1.48 ) Firmware Date: Mon 2022-08-01 I have an old Elgato Thunderbolt 2 dock connected to my laptop's Thunderbolt 3 port via the Apple TB2->TB3 adapter (https://www.apple.com/shop/product/MMEL2AM/A/thunderbolt-3-usb-c-to-thunderbolt-2-adapter). I have some USB devices connected to that dock: keyboard, speakers (using USB audio). The USB subsystem of the dock randomly disconnects with the following trace: [50410.012153] xhci_hcd 0000:09:00.0: xHCI host controller not responding, assume dead [50410.012191] xhci_hcd 0000:09:00.0: HC died; cleaning up [50410.012231] usb 5-4: USB disconnect, device number 2 It disconnects randomly less than one hour after fresh boot or hours later, there is no identifiable pattern. It happens out of the blue while I'm using the machine normally, usually playing audio to the connected speaker via USB audio. Replugging the TB3 cable usually makes USB work again for a while until it disconnects again. A monitor is connected to this dock via DisplayPort and is unaffected. I noticed that issue starting with Kernel 6.3.4, although it could have happened before. Here's my initial bug report on openSUSE Tumbleweed issue tracker: https://bugzilla.opensuse.org/show_bug.cgi?id=1212019 I can provide any additional info required.
(In reply to youp1one1 from comment #0) > System details: > > Operating System: openSUSE Tumbleweed > Kernel: Linux 6.4.4-1-default > Architecture: x86-64 > Hardware Vendor: Lenovo > Hardware Model: ThinkPad P72 > Firmware Version: N2CET65W (1.48 ) > Firmware Date: Mon 2022-08-01 > > > I have an old Elgato Thunderbolt 2 dock connected to my laptop's Thunderbolt > 3 port via the Apple TB2->TB3 adapter > (https://www.apple.com/shop/product/MMEL2AM/A/thunderbolt-3-usb-c-to- > thunderbolt-2-adapter). > > I have some USB devices connected to that dock: keyboard, speakers (using > USB audio). > The USB subsystem of the dock randomly disconnects with the following trace: > > [50410.012153] xhci_hcd 0000:09:00.0: xHCI host controller not responding, > assume dead > [50410.012191] xhci_hcd 0000:09:00.0: HC died; cleaning up > [50410.012231] usb 5-4: USB disconnect, device number 2 > > It disconnects randomly less than one hour after fresh boot or hours later, > there is no identifiable pattern. It happens out of the blue while I'm using > the machine normally, usually playing audio to the connected speaker via USB > audio. > Replugging the TB3 cable usually makes USB work again for a while until it > disconnects again. A monitor is connected to this dock via DisplayPort and > is unaffected. > I noticed that issue starting with Kernel 6.3.4, although it could have > happened before. > > Here's my initial bug report on openSUSE Tumbleweed issue tracker: > https://bugzilla.opensuse.org/show_bug.cgi?id=1212019 > > I can provide any additional info required. * Show the full dmesg and lspci output. * Does this issue occurs on v6.1.y stable series? If none, can you also check latest mainline (currently v6.5-rc3)?
Created attachment 304707 [details] lscpi output
Created attachment 304708 [details] dmesg outout
Thank you for your response. I attached both files. Note that I only have USB audio attached to the dock for these files. The end of dmesg shows me replugging the TB3 cable. I will test later with v6.5-rc3 and report.
I've been testing with v6.5-rc3 and it has been promising, with no disconnections during several hours. For the time being, I had to revert to the distro's current kernel for other reasons (some third party modules not being compiled for 6.5) but I will be able to definitely tell is v6.5 fixes this issue when Tumbleweed is updated to it, I suppose in a few weeks.
Still happening on Kernel 6.5.4: [71475.437698] xhci_hcd 0000:3d:00.0: xHCI host controller not responding, assume dead [71475.437733] xhci_hcd 0000:3d:00.0: HC died; cleaning up [71475.437775] usb 3-4: USB disconnect, device number 2
I have not seen this issue happening since Kernel 6.5.6, so closing it.