New: [6.13.9] regression USB controller dies

https://bugzilla.kernel.org/show_bug.cgi?id=220069

            Bug ID: 220069
           Summary: [6.13.9] regression USB controller dies
           Product: Drivers
           Version: 2.5
          Hardware: AMD
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: USB
          Assignee: [email protected]
          Reporter: [email protected]
        Regression: No

This seems, at least to me, a regression after the apparent fix on 6.13.7; I've tested on 6.13.9 and 6.14.3, and 6.13.7 seems to be working fine to me.

At random times (whether idle or with actual active usage), there is a high chance that any of the xHCI controllers will fail.

```
Apr 28  6:54:28 PM kernel: usb 7-11: USB disconnect, device number 11
Apr 28  6:54:28 PM kernel: usb 7-7: USB disconnect, device number 6
Apr 28  6:54:28 PM kernel: usb 7-5.2: USB disconnect, device number 9
Apr 28  6:54:28 PM kernel: usb 7-5: USB disconnect, device number 4
Apr 28  6:54:28 PM kernel: usb 7-3.5: USB disconnect, device number 15
Apr 28  6:54:28 PM kernel: usb 7-3.4: USB disconnect, device number 14
Apr 28  6:54:28 PM kernel: usb 7-3.3: USB disconnect, device number 12
Apr 28  6:54:28 PM kernel: usb 8-5: USB disconnect, device number 4
Apr 28  6:54:28 PM kernel: usb 8-2: USB disconnect, device number 2
Apr 28  6:54:28 PM kernel: usb 8-3.4: USB disconnect, device number 5
Apr 28  6:54:28 PM kernel: usb 8-3: USB disconnect, device number 3
Apr 28  6:54:28 PM kernel: usb 7-3.1: USB disconnect, device number 7
Apr 28  6:54:28 PM kernel: usb 7-3: USB disconnect, device number 3
Apr 28  6:54:28 PM kernel: usb 7-2.5: USB disconnect, device number 8
Apr 28  6:54:28 PM kernel: usb 7-2.3.2: USB disconnect, device number 13
Apr 28  6:54:28 PM kernel: usb 7-2.3.1: USB disconnect, device number 10
Apr 28  6:54:28 PM kernel: usb 7-2.3: USB disconnect, device number 5
Apr 28  6:54:28 PM kernel: usb 7-2: USB disconnect, device number 2
Apr 28  6:51:25 PM kernel: usb 7-3.4.2: USB disconnect, device number 18
Apr 28 11:23:44 AM kernel: usb 7-3.4.2: USB disconnect, device number 17
Apr 27  1:06:10 AM kernel: usb 7-3.4.2: USB disconnect, device number 16
```

Running (replace ?? for the actual guid)

```
echo -n "0000:??:00.0" | sudo tee /sys/bus/pci/drivers/xhci_hcd/unbind && echo
-n "0000:??:00.0" | sudo tee /sys/bus/pci/drivers/xhci_hcd/bind
```

Reinitialises the controller.

----

uname:

```
6.13.9-103.bazzite.fc42.x86_64
```

rpm-ostree:

```
● ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable
                   Digest:
sha256:1a7ae28b95fde42b976cc9aa159219c0aaaa0611f7416f4b3b30284e292b0875
                  Version: 42.20250417 (2025-04-17T07:35:37Z)
          LayeredPackages: android-tools
            LocalPackages: 1password-8.10.70-1.x86_64
sublime-text-4192-1.x86_64
```

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

Michał Pecio ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #1 from Michał Pecio ([email protected]) --- That's odd, because there are no xhci changes between 6.13.7 and 6.13.9, and very few USB changes at all.

Are you really sure that 6.13.7 was OK?
Can you reproduce this on upstream kernels built from source? Or bring the issue up with Fedora, in case they apply other patches?

What's the affected host controller (lspci -nn)?
I presume you are seeing the "HC died" message too, could you post full dmesg?

There is clearly "something" here, but hard to tell what it is and why.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #2 from Claudio Wunder ([email protected]) ---

I could confirm, at least to my extent of testing, that on 6.13.7 this issue was not there.

It might be a bit tricky (not to mention unstable) attempting to use upstream kernel on a ostree-locked OS; I could try to reach out to the maintainers of the distro (Silver Blue/Bazzite) and check if there are any guides on that.

That's correct, the exact symptoms are present. Here's some sample messages from journald

```
xhci_hcd 0000:6a:00.0: HC died; cleaning up
xhci_hcd 0000:6a:00.0: xHCI host controller not responding, assume dead
xhci_hcd 0000:6a:00.0: Abort failed to stop command ring: -110
```

On this current Boot, 6a is not present on lspci -nn, but I assume that's because of the virtual re-maping (order the kernel is binding the controllers at boot time), here's the output anyways:

```
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Root Complex [1022:14d8]
00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge
IOMMU [1022:14d9]
00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Dummy Host Bridge [1022:14da]
00:01.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge GPP Bridge [1022:14db]
00:01.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge GPP Bridge [1022:14db]
00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Dummy Host Bridge [1022:14da]
00:02.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge GPP Bridge [1022:14db]
00:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Dummy Host Bridge [1022:14da]
00:04.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Dummy Host Bridge [1022:14da]
00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Dummy Host Bridge [1022:14da]
00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Internal GPP Bridge to Bus [C:A] [1022:14dd]
00:08.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Internal GPP Bridge to Bus [C:A] [1022:14dd]
00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller
[1022:790b] (rev 71)
00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge
[1022:790e] (rev 51)
00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Data Fabric; Function 0 [1022:14e0]
00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Data Fabric; Function 1 [1022:14e1]
00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Data Fabric; Function 2 [1022:14e2]
00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Data Fabric; Function 3 [1022:14e3]
00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Data Fabric; Function 4 [1022:14e4]
00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Data Fabric; Function 5 [1022:14e5]
00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Data Fabric; Function 6 [1022:14e6]
00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Data Fabric; Function 7 [1022:14e7]
01:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL
Upstream Port of PCI Express Switch [1002:1478] (rev 10)
02:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL
Downstream Port of PCI Express Switch [1002:1479] (rev 10)
03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Navi 31 [Radeon RX 7900 XT/7900 XTX/7900 GRE/7900M] [1002:744c] (rev
c8)
03:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 31
HDMI/DP Audio [1002:ab30]
03:00.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 31
USB [1002:7446]
03:00.3 Serial bus controller [0c80]: Advanced Micro Devices, Inc. [AMD/ATI]
Device [1002:7444]
04:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe
SSD Controller S4LV008[Pascal] [144d:a80c]
05:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Upstream Port [1022:43f4] (rev 01)
06:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Downstream Port [1022:43f5] (rev 01)
06:08.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Downstream Port [1022:43f5] (rev 01)
06:0c.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Downstream Port [1022:43f5] (rev 01)
06:0d.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Downstream Port [1022:43f5] (rev 01)
08:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Upstream Port [1022:43f4] (rev 01)
09:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Downstream Port [1022:43f5] (rev 01)
09:01.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Downstream Port [1022:43f5] (rev 01)
09:02.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Downstream Port [1022:43f5] (rev 01)
09:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Downstream Port [1022:43f5] (rev 01)
09:08.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Downstream Port [1022:43f5] (rev 01)
09:0c.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Downstream Port [1022:43f5] (rev 01)
09:0d.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Downstream Port [1022:43f5] (rev 01)
0a:00.0 Network controller [0280]: Intel Corporation Wi-Fi 6E(802.11ax)
AX210/AX1675* 2x2 [Typhoon Peak] [8086:2725] (rev 1a)
0b:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller
I225-V [8086:15f3] (rev 03)
0d:00.0 PCI bridge [0604]: Intel Corporation Thunderbolt 4 Bridge [Maple Ridge
4C 2020] [8086:1136] (rev 02)
0e:00.0 PCI bridge [0604]: Intel Corporation Thunderbolt 4 Bridge [Maple Ridge
4C 2020] [8086:1136] (rev 02)
0e:01.0 PCI bridge [0604]: Intel Corporation Thunderbolt 4 Bridge [Maple Ridge
4C 2020] [8086:1136] (rev 02)
0e:02.0 PCI bridge [0604]: Intel Corporation Thunderbolt 4 Bridge [Maple Ridge
4C 2020] [8086:1136] (rev 02)
0e:03.0 PCI bridge [0604]: Intel Corporation Thunderbolt 4 Bridge [Maple Ridge
4C 2020] [8086:1136] (rev 02)
0f:00.0 USB controller [0c03]: Intel Corporation Thunderbolt 4 NHI [Maple Ridge
4C 2020] [8086:1137]
3b:00.0 USB controller [0c03]: Intel Corporation Thunderbolt 4 USB Controller
[Maple Ridge 4C 2020] [8086:1138]
68:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset USB 3.2 Controller [1022:43f7] (rev 01)
69:00.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset SATA Controller [1022:43f6] (rev 01)
6a:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset USB 3.2 Controller [1022:43f7] (rev 01)
6b:00.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset SATA Controller [1022:43f6] (rev 01)
6c:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Granite Ridge [Radeon Graphics] [1002:13c0] (rev cb)
6c:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt
Radeon High Definition Audio Controller [1002:1640]
6c:00.2 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Family
19h PSP/CCP [1022:1649]
6c:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
Raphael/Granite Ridge USB 3.1 xHCI [1022:15b6]
6c:00.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
Raphael/Granite Ridge USB 3.1 xHCI [1022:15b7]
6d:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
Raphael/Granite Ridge USB 2.0 xHCI [1022:15b8]
```

Regarding dmesg would you like a full output? The logs are... long.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #3 from Claudio Wunder ([email protected]) --- *Apologies, I forgot to filter only the USB controllers on my last snippet from lspci

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #4 from Michał Pecio ([email protected]) --- (In reply to Claudio Wunder from comment #2)

If "abort failed" is what starts everything, this looks like a genuine case of hardware going bad for some reason, unlike the February "hc died" regression which was a trivial driver bug and the HW worked as designed. This may be harder to solve and HW specific, possibly including connected devices.

Actually, a regression could conceivably be caused by a change in some device driver. And distro regressions can also be caused by changes in kernel .config, so you may want to ask them about that too.

Well, at the very least, it would be nice to see complete and unmodified kernel log from the event you are complaining about ;) The snippet quoted above, for example, appears to be in reverse order and I don't know why. Timestamps can useful too.

If you can't or don't want to post full kernel log (from boot to "hc died"), please at least grep it for '0000:6a:00.0' since this will show PCI IDs of the culprit chip and maybe some anomalies previously logged by xhci_hcd.

Going forward, does your system support dynamic debug and/or debugfs? Please try:

echo 'module usbcore +p' | sudo tee /proc/dynamic_debug/control echo 'module xhci_hcd +p' | sudo tee /proc/dynamic_debug/control

If this produces dmesg noise on a completely idle system, post a sample. If not, you may leave it enabled (changing +p to -p disables it) and collect dmesg with this debug info included next time something happens.

If you can mount debugfs and access /sys/kernel/debug/usb/xhci/0000:??:00.0 (all as root), please save a copy of that directory after the next crash but before unbinding and rebinding the driver. This will contain information about what the chip was doing when it went belly up.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

Mathias Nyman ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

                 CC|                            |[email protected]
                   |                            |om

--- Comment #5 from Mathias Nyman ([email protected]) --- The symptoms still hint to be the regression caused by:

36b972d4b7ce usb: xhci: improve xhci_clear_command_ring()

Which was fixed by Michal in:
c7c1f3b05c67 usb: xhci: Fix host controllers "dying" after suspend and resume

Regression was caused by command cycle confusion, meaning controller stops fetching commands from the ringbuffer as it incorrectly assumes that commands queued after cycle mismatch are old commands from last cycle on ring buffer. Driver keeps queuing new commands and hardware keeps ignoring them.

Regression was first noticed when a dedicated timeout timer for "stop endpoint" command did not complete in time, and timer handler assumed host is dead.

In this case it's the generic command timer that times out before a "stop endpoint" timer. xhci driver tries to recover by aborting the failing command, but abort likely fails as well as hardware isn't really processing any commands at the moment, and we end up assuming host is dead.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #6 from Claudio Wunder ([email protected]) ---

Here's some sample logs with the correct times, apologies for not providing the timestamps.

```
Apr 26 23:16:09 angel-thesis kernel: xhci_hcd 0000:6b:00.0: Event TRB for slot
18 ep 0 with no TDs queued
Apr 26 23:16:24 angel-thesis kernel: xhci_hcd 0000:6b:00.0: ERROR unknown event
type 4
Apr 26 23:16:24 angel-thesis kernel: xhci_hcd 0000:6b:00.0: Abort failed to
stop command ring: -110
Apr 26 23:16:24 angel-thesis kernel: xhci_hcd 0000:6b:00.0: xHCI host
controller not responding, assume dead
Apr 26 23:16:24 angel-thesis kernel: xhci_hcd 0000:6b:00.0: HC died; cleaning
up
Apr 26 23:16:24 angel-thesis kernel: xhci_hcd 0000:6b:00.0: Timeout while
waiting for setup device command
```

```
Apr 26 23:16:24 angel-thesis kernel: usb 7-2: USB disconnect, device number 2
Apr 26 23:16:24 angel-thesis kernel: usb 7-2.3: USB disconnect, device number 5
Apr 26 23:16:24 angel-thesis kernel: usb 7-2.3.1: USB disconnect, device number
10
Apr 26 23:16:24 angel-thesis kernel: usb 7-2.4: USB disconnect, device number 8
Apr 26 23:16:24 angel-thesis kernel: usb 7-2.5: USB disconnect, device number
13
Apr 26 23:16:24 angel-thesis kernel: usb 7-3: USB disconnect, device number 3
Apr 26 23:16:25 angel-thesis kernel: usb 7-3.1: USB disconnect, device number 7
Apr 26 23:16:25 angel-thesis kernel: usb 8-3: USB disconnect, device number 3
Apr 26 23:16:25 angel-thesis kernel: usb 8-3.4: USB disconnect, device number 5
Apr 26 23:16:25 angel-thesis kernel: usb 8-2: USB disconnect, device number 2
Apr 26 23:16:25 angel-thesis kernel: usb 8-5: USB disconnect, device number 4
Apr 26 23:16:25 angel-thesis kernel: usb 7-3.3: USB disconnect, device number
12
Apr 26 23:16:25 angel-thesis kernel: usb 7-3.4: USB disconnect, device number
14
Apr 26 23:16:25 angel-thesis kernel: usb 7-3.4.2: USB disconnect, device number
19
Apr 26 23:16:25 angel-thesis kernel: usb 7-3.5: USB disconnect, device number
15
Apr 26 23:16:25 angel-thesis kernel: usb 7-5: USB disconnect, device number 4
Apr 26 23:16:25 angel-thesis kernel: usb 7-5.2: USB disconnect, device number 9
Apr 26 23:16:25 angel-thesis kernel: usb 7-7: USB disconnect, device number 6
Apr 26 23:16:25 angel-thesis kernel: usb 7-11: USB disconnect, device number 11
```

```
Apr 28 18:54:12 angel-thesis kernel: xhci_hcd 0000:6a:00.0: Event TRB for slot
18 ep 0 with no TDs queued
Apr 28 18:54:28 angel-thesis kernel: xhci_hcd 0000:6a:00.0: ERROR unknown event
type 4
Apr 28 18:54:28 angel-thesis kernel: xhci_hcd 0000:6a:00.0: Abort failed to
stop command ring: -110
Apr 28 18:54:28 angel-thesis kernel: xhci_hcd 0000:6a:00.0: xHCI host
controller not responding, assume dead
Apr 28 18:54:28 angel-thesis kernel: xhci_hcd 0000:6a:00.0: HC died; cleaning
up
Apr 28 18:54:28 angel-thesis kernel: xhci_hcd 0000:6a:00.0: Timeout while
waiting for setup device command
```

```
Apr 28 18:51:25 angel-thesis kernel: usb 7-3.4.2: USB disconnect, device number
18
Apr 28 18:54:28 angel-thesis kernel: usb 7-2: USB disconnect, device number 2
Apr 28 18:54:28 angel-thesis kernel: usb 7-2.3: USB disconnect, device number 5
Apr 28 18:54:28 angel-thesis kernel: usb 7-2.3.1: USB disconnect, device number
10
Apr 28 18:54:28 angel-thesis kernel: usb 7-2.3.2: USB disconnect, device number
13
Apr 28 18:54:28 angel-thesis kernel: usb 7-2.5: USB disconnect, device number 8
Apr 28 18:54:28 angel-thesis kernel: usb 7-3: USB disconnect, device number 3
Apr 28 18:54:28 angel-thesis kernel: usb 7-3.1: USB disconnect, device number 7
Apr 28 18:54:28 angel-thesis kernel: usb 8-3: USB disconnect, device number 3
Apr 28 18:54:28 angel-thesis kernel: usb 8-3.4: USB disconnect, device number 5
Apr 28 18:54:28 angel-thesis kernel: usb 8-2: USB disconnect, device number 2
Apr 28 18:54:28 angel-thesis kernel: usb 8-5: USB disconnect, device number 4
Apr 28 18:54:28 angel-thesis kernel: usb 7-3.3: USB disconnect, device number
12
Apr 28 18:54:28 angel-thesis kernel: usb 7-3.4: USB disconnect, device number
14
Apr 28 18:54:28 angel-thesis kernel: usb 7-3.5: USB disconnect, device number
15
Apr 28 18:54:28 angel-thesis kernel: usb 7-5: USB disconnect, device number 4
Apr 28 18:54:28 angel-thesis kernel: usb 7-5.2: USB disconnect, device number 9
Apr 28 18:54:28 angel-thesis kernel: usb 7-7: USB disconnect, device number 6
Apr 28 18:54:28 angel-thesis kernel: usb 7-11: USB disconnect, device number 11
Apr 29 10:05:16 angel-thesis kernel: usb 5-1: USB disconnect, device number 2
```

I'll reach out to Fedora's Discourse/Universal Blue Discourse.

Here's the full dmesg log via journalctl -o short-precise -k -b -3:
https://gist.github.com/ovflowd/0b0aa5c748683eca33909dc3ed7c66f7 (I shared on GitHub Gist due to the large size, if you rather have me hosting it on a FOSS alternative, let me know, I can upload it to gitlab.gnome.org)

Let me check and circle back.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #7 from Claudio Wunder ([email protected]) --- Running the echo commands to proc resulted on zero noise on dmesg, but I've mounted the debug partition and can see files here:

```
❯ sudo ls -la /sys/kernel/debug/usb/xhci/0000:6a:00.0
total 0
drwxr-xr-x.  6 root root 0 Apr 30 10:01 .
drwxr-xr-x.  9 root root 0 Apr 30 10:01 ..
drwxr-xr-x.  2 root root 0 Apr 30 10:01 command-ring
drwxr-xr-x.  7 root root 0 Apr 30 10:05 devices
drwxr-xr-x.  2 root root 0 Apr 30 10:01 event-ring
drwxr-xr-x. 20 root root 0 Apr 30 10:01 ports
-r--r--r--.  1 root root 0 Apr 30 10:01 reg-cap
-r--r--r--.  1 root root 0 Apr 30 10:01 reg-ext-dbc:00
-r--r--r--.  1 root root 0 Apr 30 10:01 reg-ext-legsup:00
-r--r--r--.  1 root root 0 Apr 30 10:01 reg-ext-protocol:00
-r--r--r--.  1 root root 0 Apr 30 10:01 reg-ext-protocol:01
-r--r--r--.  1 root root 0 Apr 30 10:01 reg-ext-protocol:02
-r--r--r--.  1 root root 0 Apr 30 10:01 reg-op
-r--r--r--.  1 root root 0 Apr 30 10:01 reg-runtime
```

I'll wait for the next crash to happen to zip them via ssh after next crash, but as requested, before unbinding/binding.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #8 from Claudio Wunder ([email protected]) ---
Ah, BTW, on the current boot, these are all the available USB controllers:

```
03:00.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 31
USB [1002:7446]
0f:00.0 USB controller [0c03]: Intel Corporation Thunderbolt 4 NHI [Maple Ridge
4C 2020] [8086:1137]
3b:00.0 USB controller [0c03]: Intel Corporation Thunderbolt 4 USB Controller
[Maple Ridge 4C 2020] [8086:1138]
68:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset USB 3.2 Controller [1022:43f7] (rev 01)
6a:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset USB 3.2 Controller [1022:43f7] (rev 01)
6c:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
Raphael/Granite Ridge USB 3.1 xHCI [1022:15b6]
6c:00.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
Raphael/Granite Ridge USB 3.1 xHCI [1022:15b7]
6d:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
Raphael/Granite Ridge USB 2.0 xHCI [1022:15b8]
```

A random note, that I'm unaware if it has any affect at all, is that "Legacy xHCI Hand-Off is disabled" on my EFI; I assume since modern versions of the Kernel this isn't required.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #9 from Michał Pecio ([email protected]) --- (In reply to Claudio Wunder from comment #6)

Thanks. That's not a really huge file, you can upload such files here as attachments to this bug.

This means it's the "600 series chipset", which is reportedly a Promontory family chipset, made for AMD by ASMedia. And IME ASMedia controllers are pretty buggy.

That's sort of stuff which may show up when they get completely FUBAR'd and about to stop working at all. So I don't really share the optimism that it's a simple SW bug which causes the abort to fail, it's probably a deeper screwup. The debugfs dump will tell...

I think you said you have more of those logs, is the above always appearing a few seconds before "hc died"? It seems related to the 8-3 device, a VIA USB 3.0 hub.

IME such problems tend to be happening under particular workloads, so still no idea how a minor kernel update could cause it to appear. Were there no hardware changes, like USB devices added or moved to other ports? How long are you using this machine with all of those devices, which kernel versions were working OK for so long that they certainly cannot possibly have this problem?

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #10 from Claudio Wunder ([email protected]) ---

That's interesting... I do recall on Windows at times, resuming from sleep would.. have issues (I had to change the AMD drivers to custom ones due to SMU/ULPS issues. I'm not sure if this piece of log xhci_hcd 0000:03:00.2: xHC error in resume, USBSTS 0x401, Reinit is relevant.

Never been so excited for a crash to happen lol.

For the sample of two items I have so far, it appears that these are showing up. Note that on both the original regression and the current "apparent" one (if we can even call it a regression?), these errors above are happening. I will need to wait to see the next crash also happens to have said logs;

Nope, no changes. I know older versions of Fedora (40) had no issues, but it's been a while since I've used it (I was recently on Windows 11 (no issues whatsoever, except for AMDgpu ULPS driver issues) and now I've been fresh to Bazzite (Universal Blue/Silverblue) and been facing said issues.

It could as well be _my hardware_ -- but given the coincidence, and that with 6.13.7 the issue disappeared for a whole week, and then once going to the next update of Bazzite with 6.13.9 and the update with 6.14.3 it has been happening again. (Curiously on 6.13.9 it happens not often, but on 6.14.3 it was happening every few hours; Unfortunately since with rpm-ostree I rollbacked the system, the logs for those boots are lost; I could attempt to upgrade to 6.14.3 to see if I find the bug more often)

That said, I genuinely don't know, nor if it is due to a Kernel change.

It happened before on both resuming from sleep, intensive workloads (i.e. gaming) or simply when typing/using the PC normally or when the PC is idle. I discarded power profile or power management at the time as a cause. Enabling or disabling OS-managed ASPM also has no effect, so I ruled out being an ACPI/APM issue.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #11 from Claudio Wunder ([email protected]) ---

OOC, X670E is my chipset, I assume it is indeed part of the buggy club. I could change my motherboard, something like X870E (Assuming the 800 series by ASMedia does not have the same issue); Just to rule out the "this is probably the chipset" culprit.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #12 from Michał Pecio ([email protected]) --- (In reply to Claudio Wunder from comment #10)

Wait, this is important. If you were seeing "Abort failed to stop command ring:
-110" instead of "xHCI host not responding to stop endpoint command" before 6.13.7 then it is at least possible, if not likely, that you were already running into a different problem than the one fixed in 6.13.7. And it gets doubly suspicious if you also saw "ERROR unknown event type <some number>" a few seconds before "HC died". Do you still have those logs by any chance?

As Mathias Nyman explained, the known 6.13 issue was a simple driver bug:
commands were written incorrectly, chips correctly ignored them, the driver incorrectly pronounced them dead.

Mathias further suggests that this or similar bug may still somehow exist in your kernel and that command abort fails because the chip believes there are no pending commands. That is possible, but unlikely because command abort is not supposed to fail like that. So if you ever seem command abort timeout, either the abort code is buggy (and it looks like no one touched that part in ages) or the chip is buggy in one way or another.

It would be sad if this turns out to be a regression due to the commits initially suspected back in February:
https://bugzilla.kernel.org/show_bug.cgi?id=219824#c5

These are present in all 6.12 and higher releases from this year, so the only supported kernels without them are old LTS series. Not sure if you have means of testing those for a few weeks on the same HW, userspace and workload?

I could also suggest some stress tests which exercise this code (and the USB controller). I found webcams and USB serial dongles to be particularly suitable, do you have some of such stuff at hand?

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #13 from Michał Pecio ([email protected]) --- (In reply to Claudio Wunder from comment #11)

That's an assumption ;)

A simpler thing is to try different USB ports (rear or front panel) and see if any are connected to different (probably in-CPU) controllers. Or get a PCIe card, those with Renesas uPD720201/uPD720202 chips are reliable, though 5Gbps only.

Your problem seems to be HW specific, because others generally stopped complaining after 6.13.7. I have heard about one more case of "Abort failed to stop command ring: -110" and suggested filing a bug here, but the reporter never did.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #14 from Claudio Wunder ([email protected]) ---

The closest log from all my previously stored logs within journald to "xHCI host not responding to stop endpoint command" is "Apr 21 11:23:10.258699 angel-thesis kernel: xhci_hcd 0000:6a:00.0: xHCI host controller not responding, assume dead"

Here are some more logs:

```
Apr 21 03:14:59 angel-thesis kernel: xhci_hcd 0000:6a:00.0: Event TRB for slot
4 ep 0 with no TDs queued
Apr 21 04:20:16 angel-thesis kernel: xhci_hcd 0000:6a:00.0: ERROR unknown event
type 4
Apr 21 04:20:16 angel-thesis kernel: xhci_hcd 0000:6a:00.0: Abort failed to
stop command ring: -110
Apr 21 04:20:16 angel-thesis kernel: xhci_hcd 0000:6a:00.0: xHCI host
controller not responding, assume dead
Apr 21 04:20:16 angel-thesis kernel: xhci_hcd 0000:6a:00.0: HC died; cleaning
up
Apr 21 04:20:16 angel-thesis kernel: xhci_hcd 0000:6a:00.0: Timeout while
waiting for setup device command
```

Yes!

```
Apr 26 23:57:40 angel-thesis kernel: xhci_hcd 0000:6b:00.0: Event TRB for slot
4 ep 0 with no TDs queued
Apr 26 23:57:40 angel-thesis kernel: usb 8-3: Device not responding to setup
address.
Apr 26 23:57:55 angel-thesis kernel: xhci_hcd 0000:6b:00.0: ERROR unknown event
type 4
Apr 26 23:57:55 angel-thesis kernel: xhci_hcd 0000:6b:00.0: Abort failed to
stop command ring: -110
Apr 26 23:57:55 angel-thesis kernel: xhci_hcd 0000:6b:00.0: xHCI host
controller not responding, assume dead
Apr 26 23:57:55 angel-thesis kernel: xhci_hcd 0000:6b:00.0: HC died; cleaning
up
Apr 26 23:57:55 angel-thesis kernel: xhci_hcd 0000:6b:00.0: Timeout while
waiting for setup device command
Apr 26 23:57:55 angel-thesis kernel: usb 7-2: USB disconnect, device number 2
Apr 26 23:57:55 angel-thesis kernel: usb 7-2.3: USB disconnect, device number 5
Apr 26 23:57:55 angel-thesis kernel: usb 7-2.3.1: USB disconnect, device number
10
Apr 26 23:57:55 angel-thesis kernel: usb 7-2.4: USB disconnect, device number 8
Apr 26 23:57:55 angel-thesis kernel: usb 7-2.5: USB disconnect, device number
13
Apr 26 23:57:55 angel-thesis kernel: usb 7-3: USB disconnect, device number 3
Apr 26 23:57:55 angel-thesis kernel: usb 7-3.1: USB disconnect, device number 7
Apr 26 23:57:55 angel-thesis kernel: usb 7-3.3: USB disconnect, device number
12
Apr 26 23:57:55 angel-thesis kernel: usb 7-3.4: USB disconnect, device number
14
Apr 26 23:57:55 angel-thesis kernel: usb 7-3.4.2: USB disconnect, device number
16
Apr 26 23:57:55 angel-thesis kernel: usb 7-3.5: USB disconnect, device number
15
Apr 26 23:57:55 angel-thesis kernel: usb 7-5: USB disconnect, device number 4
Apr 26 23:57:55 angel-thesis kernel: usb 7-5.2: USB disconnect, device number 9
Apr 26 23:57:55 angel-thesis kernel: usb 7-7: USB disconnect, device number 6
Apr 26 23:57:55 angel-thesis kernel: usb 7-11: USB disconnect, device number 11
Apr 26 23:57:55 angel-thesis kernel: usb 8-3: device not accepting address 3,
error -62
Apr 26 23:57:55 angel-thesis kernel: usb 8-3: USB disconnect, device number 3
Apr 26 23:57:55 angel-thesis kernel: usb 8-3.4: USB disconnect, device number 5
Apr 26 23:57:55 angel-thesis kernel: usb usb8-port3: couldn't allocate
usb_device
Apr 26 23:57:55 angel-thesis kernel: usb 8-2: USB disconnect, device number 2
Apr 26 23:57:55 angel-thesis kernel: usb 8-5: USB disconnect, device number 4
```

```
Apr 28 18:54:12 angel-thesis kernel: xhci_hcd 0000:6a:00.0: Event TRB for slot
18 ep 0 with no TDs queued
Apr 28 18:54:12 angel-thesis kernel: usb 8-3: Device not responding to setup
address.
Apr 28 18:54:28 angel-thesis kernel: xhci_hcd 0000:6a:00.0: ERROR unknown event
type 4
Apr 28 18:54:28 angel-thesis kernel: xhci_hcd 0000:6a:00.0: Abort failed to
stop command ring: -110
Apr 28 18:54:28 angel-thesis kernel: xhci_hcd 0000:6a:00.0: xHCI host
controller not responding, assume dead
Apr 28 18:54:28 angel-thesis kernel: xhci_hcd 0000:6a:00.0: HC died; cleaning
up
Apr 28 18:54:28 angel-thesis kernel: xhci_hcd 0000:6a:00.0: Timeout while
waiting for setup device command
Apr 28 18:54:28 angel-thesis kernel: usb 7-2: USB disconnect, device number 2
Apr 28 18:54:28 angel-thesis kernel: usb 7-2.3: USB disconnect, device number 5
Apr 28 18:54:28 angel-thesis kernel: usb 7-2.3.1: USB disconnect, device number
10
Apr 28 18:54:28 angel-thesis kernel: usb 7-2.3.2: USB disconnect, device number
13
Apr 28 18:54:28 angel-thesis kernel: usb 7-2.5: USB disconnect, device number 8
Apr 28 18:54:28 angel-thesis kernel: usb 7-3: USB disconnect, device number 3
Apr 28 18:54:28 angel-thesis kernel: usb 7-3.1: USB disconnect, device number 7
Apr 28 18:54:28 angel-thesis kernel: usb 8-3: device not accepting address 3,
error -62
Apr 28 18:54:28 angel-thesis kernel: usb 8-3: USB disconnect, device number 3
Apr 28 18:54:28 angel-thesis kernel: usb 8-3.4: USB disconnect, device number 5
Apr 28 18:54:28 angel-thesis kernel: usb usb8-port3: couldn't allocate
usb_device
Apr 28 18:54:28 angel-thesis kernel: usb 8-2: USB disconnect, device number 2
Apr 28 18:54:28 angel-thesis kernel: usb 8-5: USB disconnect, device number 4
Apr 28 18:54:28 angel-thesis kernel: usb 7-3.3: USB disconnect, device number
12
Apr 28 18:54:28 angel-thesis kernel: usb 7-3.4: USB disconnect, device number
14
Apr 28 18:54:28 angel-thesis kernel: usb 7-3.5: USB disconnect, device number
15
Apr 28 18:54:28 angel-thesis kernel: usb 7-5: USB disconnect, device number 4
Apr 28 18:54:28 angel-thesis kernel: usb 7-5.2: USB disconnect, device number 9
Apr 28 18:54:28 angel-thesis kernel: usb 7-7: USB disconnect, device number 6
Apr 28 18:54:28 angel-thesis kernel: usb 7-11: USB disconnect, device number 11
```

And it happens indeed a few seconds afterwards.

That's interesting.

Ill wait for the issue to happen again, so I can at least upload the debugfs; Then Ill attempt to switch to an older Kernel version (6.12.X) if needed.

You mean simulated code? Like Prime95? On the dongles/connected USB devices (here's a screenshot of the USB Devices Tree:
https://gist.github.com/ovflowd/0b0aa5c748683eca33909dc3ed7c66f7#file-screenshot_20250501_113016-png)

But pretty much:

- There's a RodeCaster Duo connected to one of the USB rear ports
- Note that this has two (2) USB-out ports to connect to two devices;
- There's a KVM switch from Anker connected to another USB port (Model Number:
A83K3) with a keyboard (Wooting 60HE+ and a Logitech Bolt dongle connected to it (mouse wireless dongle))
- 2nd RodeCaster Duo USB port also connected there.
- I'm using a Monitor with an USB-B hub (Supposedly USB 3.2, per monitor settings, but Linux recognises it as a USB 2.0, possibly because bandwidth negotiations are at 2.0 speeds; either with webcam on idle or non-idle) where a webcam (Insta 360 Link 2C) indeed is connected.

To be honest, neither of these devices are bandwidth hungry, even the webcam is capped at 2K but always on 1080p/i

There are a bunch of integrated peripherals appearing there such as ASMedia's ASM Controller (ASM107x whatever that is, and seems to be shared on two xHCI controllers); The Bluetooth Controller, LED controller and the AIO Pump Controller.

It is really hard to say if any of these devices are somehow crashing the xHCI controller, and I believe it might be crashing a specific one? For example, Audio on my RodeCaster Duo and Bluetooth keep working when that said crash happens (not sure if this is important info), but all other devices (like my mouse, keyboard) stop working (I already tried to plug on different front ports, but not rear ports)

And from the Logs, it is exactly the controller that all my peripherals besides the back port of my RodeCaster Duo is.

```
Manufacturer: Linux 6.13.9-103.bazzite.fc42.x86_64 xhci-hcd
Serial #: 0000:6a:00.0
```

(This one contains all my devices, mouse, etc); Except for Bluetooth and the 1st RodeCaster Duo port.

```
Manufacturer: Linux 6.13.9-103.bazzite.fc42.x86_64 xhci-hcd
Serial #: 0000:68:00.0
```

And since all integrated mobo peripherals are on the former one, I'm assuming maybe it could be related to some integrated hardware, as you mentioned before?

It's really hard to know now without the logs, so I'll stop my assumptions.

Yeah, that's what I described above.

I worry I am wasting too much of your time, tbh. Genuinely speaking, no idea what's going on besides of "I definitely would like a solution for this" and contribute as much as I can with reporting a bug that may or may not be affecting other users.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #15 from Claudio Wunder ([email protected]) ---
Aand it happened again, during gaming workload. Unfortunately, I had restarted my PC and the debugfs partition was gone, but here are the logs:

```
May 01 22:53:53 angel-thesis kernel: xhci_hcd 0000:6a:00.0: Abort failed to
stop command ring: -110
May 01 22:53:53 angel-thesis kernel: xhci_hcd 0000:6a:00.0: xHCI host
controller not responding, assume dead
May 01 22:53:53 angel-thesis kernel: xhci_hcd 0000:6a:00.0: HC died; cleaning
up
May 01 22:53:53 angel-thesis kernel: usb 7-2: USB disconnect, device number 2
May 01 22:53:53 angel-thesis kernel: usb 7-2.3: USB disconnect, device number 5
May 01 22:53:53 angel-thesis kernel: usb 7-2.3.1: USB disconnect, device number
10
May 01 22:53:53 angel-thesis kernel: xhci_hcd 0000:6a:00.0: Timeout while
waiting for setup device command
May 01 22:53:53 angel-thesis kernel: usb 7-2.3.2: USB disconnect, device number
13
May 01 22:53:53 angel-thesis kernel: usb 7-2.5: USB disconnect, device number 8
May 01 22:53:53 angel-thesis kernel: usb 7-3: USB disconnect, device number 3
May 01 22:53:53 angel-thesis kernel: usb 7-3.1: USB disconnect, device number 7
May 01 22:53:53 angel-thesis kernel: usb 8-3: device not accepting address 3,
error -62
May 01 22:53:53 angel-thesis kernel: usb 8-3: USB disconnect, device number 3
May 01 22:53:53 angel-thesis kernel: usb 8-3.4: USB disconnect, device number 5
May 01 22:53:53 angel-thesis kernel: usb usb8-port3: couldn't allocate
usb_device
May 01 22:53:53 angel-thesis kernel: usb 8-2: USB disconnect, device number 2
May 01 22:53:53 angel-thesis kernel: usb 8-5: USB disconnect, device number 4
May 01 22:53:53 angel-thesis kernel: usb 7-3.3: USB disconnect, device number
12
May 01 22:53:53 angel-thesis kernel: usb 7-3.4: USB disconnect, device number
14
May 01 22:53:53 angel-thesis kernel: usb 7-3.4.2: USB disconnect, device number
16
May 01 22:53:53 angel-thesis kernel: usb 7-3.5: USB disconnect, device number
15
May 01 22:53:53 angel-thesis kernel: usb 7-5: USB disconnect, device number 4
May 01 22:53:54 angel-thesis kernel: usb 7-5.2: USB disconnect, device number 9
May 01 22:53:54 angel-thesis kernel: usb 7-7: USB disconnect, device number 6
```

If it happens again, I will be ready this time.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #16 from Claudio Wunder ([email protected]) --- (note that I restarted my PC prior to this due to an unrelated matter)

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #17 from Michał Pecio ([email protected]) --- Actually, I think it would still work if you mount debugfs after the fact. These files are generated by the driver from data which already exist in memory and will only be lost after unbind. But no problem, looks like the same thing is happening every few days.

(In reply to Claudio Wunder from comment #14)

The devices which stop working are exactly those connected to the controller which fails. And the problem source is also somewhere there. There is something suspicious about the 8-3 hub which is always undergoing a reset when the HC dies, and it is those commands which appear to be timing out and then refusing to abort.

Not sure if it's the cause or a symptom, maybe try to request a reset manually a few times? The 'usbutils' packages which provides 'lsusb' should also have 'usbreset', this will do the business:

sudo usbreset 2109:0817

Or exercise this hub a little by asking it to reset its child device. There is another hub connected to it with different ID:

sudo usbreset 2109:0211

(BTW, bus 7 is the USB 2.0 part of bus 8, and devices seen on both 7 and 8 are USB 3.x hubs).

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #18 from Claudio Wunder ([email protected]) ---

I assume you're referring to:

```
May 01 22:53:53 angel-thesis kernel: usb 8-3: device not accepting address 3,
error -62
May 01 22:53:53 angel-thesis kernel: usb usb8-port3: couldn't allocate
usb_device
```

Oh that makes a lot of sense!

Just to verify, with sudo usbreset 2109:0817 and sudo usbreset 2109:0211 you're asking me to reset the USB 3.0 Hub from (8) and it's child device, right? There's nothing connected to them, but just verifying.

In the last 2 times these match times I've been playing games. Another symptom before the reset, is the system freezes for a few seconds, including audio, but then it unfreezes with the devices then disconnecting.

Alrighty, then no use, I had no recollection of this info; The mount was done after I ran unbind/bind from ssh... But here's the zip anyways, maybe it helps.
https://gist.github.com/ovflowd/0b0aa5c748683eca33909dc3ed7c66f7#file-debugfs-zip

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #19 from Claudio Wunder ([email protected]) ---
BTW, I ran the usbreset commands and got: "Resetting USB3.0 Hub ... ok" and "Resetting USB3.0 Hub ... ok" respectively.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #20 from Michał Pecio ([email protected]) --- Try hammering each variant in a loop for a few hours:

while :; do usbreset <numbers>; done

You could also pile more work on the HC at the same time, for example starting and stopping video recording makes them quite busy. I suggest automating this job too, I use the yavta tool (linked below) like this:

while test -c /dev/video0; do yavta -c3 /dev/video0; done

https://git.ideasonboard.org/yavta.git

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #21 from Michał Pecio ([email protected]) --- (In reply to Claudio Wunder from comment #18)

If my tricks fail to accelerate the failure you can always go back to gaming ;)

The freeze is a known (at least to me) bug. I believe it's caused by the driver waiting for the command abort to complete with xhci->lock held, which blocks the IRQ handler for a few seconds as it tries to acquire the same lock, which apparently causes other random IRQs to get delayed as well. I have been putting off looking into it properly since December, maybe it's time to alert Mathias...

This zip is OK, but it contains current data from normal operation, not a failure. A few random transfers on some devices and it looks like the familiar 8-3 hub is periodically getting autosuspended, maybe that's what sometimes goes wrong.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #22 from Claudio Wunder ([email protected]) ---

Yeah, as I mentioned that was after I made the unbind/bind.

I appreciate the extra info. Let me try those simulated failures, let's see if that accelerates the issue.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #23 from Claudio Wunder ([email protected]) --- I was finally able to capture a zip from debugfs before unbind/bind.

Here's the file:
https://gist.github.com/ovflowd/0b0aa5c748683eca33909dc3ed7c66f7#file-debugfs-new-zip

And the logs:

```
May 03 01:53:29 angel-thesis kernel: xhci_hcd 0000:6a:00.0: Event TRB for slot
19 ep 0 with no TDs queued
May 03 01:53:29 angel-thesis kernel: usb 8-3: Device not responding to setup
address.
May 03 01:53:44 angel-thesis kernel: xhci_hcd 0000:6a:00.0: ERROR unknown event
type 4
May 03 01:53:44 angel-thesis kernel: xhci_hcd 0000:6a:00.0: Abort failed to
stop command ring: -110
May 03 01:53:44 angel-thesis kernel: xhci_hcd 0000:6a:00.0: xHCI host
controller not responding, assume dead
May 03 01:53:44 angel-thesis kernel: xhci_hcd 0000:6a:00.0: HC died; cleaning
up
May 03 01:53:44 angel-thesis kernel: xhci_hcd 0000:6a:00.0: Timeout while
waiting for setup device command
May 03 01:53:44 angel-thesis kernel: usb 7-2: USB disconnect, device number 11
May 03 01:53:44 angel-thesis kernel: usb 7-2.3: USB disconnect, device number
12
May 03 01:53:44 angel-thesis kernel: usb 7-2.3.1: USB disconnect, device number
14
May 03 01:53:44 angel-thesis kernel: usb 7-2.3.2: USB disconnect, device number
15
May 03 01:53:44 angel-thesis kernel: usb 7-2.5: USB disconnect, device number
13
May 03 01:53:44 angel-thesis kernel: usb 7-3: USB disconnect, device number 16
May 03 01:53:44 angel-thesis kernel: usb 7-3.1: USB disconnect, device number
17
May 03 01:53:44 angel-thesis kernel: usb 7-3.3: USB disconnect, device number
18
May 03 01:53:44 angel-thesis kernel: usb 7-3.4: USB disconnect, device number
19
May 03 01:53:44 angel-thesis kernel: usb 7-3.4.2: USB disconnect, device number
21
May 03 01:53:44 angel-thesis kernel: usb 7-3.5: USB disconnect, device number
20
May 03 01:53:44 angel-thesis kernel: usb 7-5: USB disconnect, device number 2
May 03 01:53:44 angel-thesis kernel: usb 7-5.2: USB disconnect, device number 4
May 03 01:53:44 angel-thesis kernel: usb 8-3: device not accepting address 5,
error -62
May 03 01:53:44 angel-thesis kernel: usb 8-3: USB disconnect, device number 5
May 03 01:53:44 angel-thesis kernel: usb 8-3.4: USB disconnect, device number 6
May 03 01:53:44 angel-thesis kernel: usb usb8-port3: couldn't allocate
usb_device
May 03 01:53:44 angel-thesis kernel: usb 8-2: USB disconnect, device number 4
May 03 01:53:44 angel-thesis kernel: usb 8-5: USB disconnect, device number 2
May 03 01:53:44 angel-thesis kernel: usb 7-7: USB disconnect, device number 3
May 03 01:53:44 angel-thesis kernel: usb 7-11: USB disconnect, device number 5
```

Here's unbind:

```
May 03 02:16:07 angel-thesis kernel: xhci_hcd 0000:6a:00.0: remove, state 1
May 03 02:16:07 angel-thesis kernel: usb usb8: USB disconnect, device number 1
May 03 02:16:07 angel-thesis kernel: xhci_hcd 0000:6a:00.0: USB bus 8
deregistered
May 03 02:16:07 angel-thesis kernel: xhci_hcd 0000:6a:00.0: remove, state 1
May 03 02:16:07 angel-thesis kernel: usb usb7: USB disconnect, device number 1
May 03 02:16:07 angel-thesis kernel: xhci_hcd 0000:6a:00.0: USB bus 7
deregistered
```

Here's bind:

```
May 03 02:16:12 angel-thesis kernel: xhci_hcd 0000:6a:00.0: xHCI Host
Controller
May 03 02:16:12 angel-thesis kernel: xhci_hcd 0000:6a:00.0: new USB bus
registered, assigned bus number 7
May 03 02:16:12 angel-thesis kernel: xhci_hcd 0000:6a:00.0: hcc params
0x0200ef81 hci version 0x110 quirks 0x0000000200000010
May 03 02:16:12 angel-thesis kernel: xhci_hcd 0000:6a:00.0: xHCI Host
Controller
May 03 02:16:12 angel-thesis kernel: xhci_hcd 0000:6a:00.0: new USB bus
registered, assigned bus number 8
May 03 02:16:12 angel-thesis kernel: xhci_hcd 0000:6a:00.0: Host supports USB
3.2 Enhanced SuperSpeed
May 03 02:16:12 angel-thesis kernel: usb usb7: New USB device found,
idVendor=1d6b, idProduct=0002, bcdDevice= 6.14
May 03 02:16:12 angel-thesis kernel: usb usb7: New USB device strings: Mfr=3,
Product=2, SerialNumber=1
May 03 02:16:12 angel-thesis kernel: usb usb7: Product: xHCI Host Controller
May 03 02:16:12 angel-thesis kernel: usb usb7: Manufacturer: Linux
6.14.4-103.bazzite.fc42.x86_64 xhci-hcd
May 03 02:16:12 angel-thesis kernel: usb usb7: SerialNumber: 0000:6a:00.0
May 03 02:16:12 angel-thesis kernel: usb usb8: We don't know the algorithms for
LPM for this host, disabling LPM.
May 03 02:16:12 angel-thesis kernel: usb usb8: New USB device found,
idVendor=1d6b, idProduct=0003, bcdDevice= 6.14
May 03 02:16:12 angel-thesis kernel: usb usb8: New USB device strings: Mfr=3,
Product=2, SerialNumber=1
May 03 02:16:12 angel-thesis kernel: usb usb8: Product: xHCI Host Controller
May 03 02:16:12 angel-thesis kernel: usb usb8: Manufacturer: Linux
6.14.4-103.bazzite.fc42.x86_64 xhci-hcd
May 03 02:16:12 angel-thesis kernel: usb usb8: SerialNumber: 0000:6a:00.0
May 03 02:16:12 angel-thesis kernel: usb 7-2: new high-speed USB device number
2 using xhci_hcd
May 03 02:16:13 angel-thesis kernel: usb 7-2: New USB device found,
idVendor=2109, idProduct=4817, bcdDevice= 1.73
May 03 02:16:13 angel-thesis kernel: usb 7-2: New USB device strings: Mfr=1,
Product=2, SerialNumber=0
May 03 02:16:13 angel-thesis kernel: usb 7-2: Product: USB2.0 Hub             
May 03 02:16:13 angel-thesis kernel: usb 7-2: Manufacturer: VIA Labs, Inc.      
May 03 02:16:13 angel-thesis kernel: usb 8-2: new SuperSpeed USB device number
2 using xhci_hcd
May 03 02:16:13 angel-thesis kernel: usb 8-2: New USB device found,
idVendor=2109, idProduct=3817, bcdDevice= 1.73
May 03 02:16:13 angel-thesis kernel: usb 8-2: New USB device strings: Mfr=1,
Product=2, SerialNumber=0
May 03 02:16:13 angel-thesis kernel: usb 8-2: Product: USB3.0 Hub             
May 03 02:16:13 angel-thesis kernel: usb 8-2: Manufacturer: VIA Labs, Inc.      
May 03 02:16:13 angel-thesis kernel: usb 7-3: new high-speed USB device number
3 using xhci_hcd
May 03 02:16:13 angel-thesis kernel: usb 7-3: New USB device found,
idVendor=2109, idProduct=2817, bcdDevice= 7.74
May 03 02:16:14 angel-thesis kernel: usb 7-3: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
May 03 02:16:14 angel-thesis kernel: usb 7-3: Product: USB2.0 Hub             
May 03 02:16:14 angel-thesis kernel: usb 7-3: Manufacturer: VIA Labs, Inc.      
May 03 02:16:14 angel-thesis kernel: usb 7-3: SerialNumber: 000000000
May 03 02:16:14 angel-thesis kernel: usb 8-3: new SuperSpeed USB device number
3 using xhci_hcd
May 03 02:16:14 angel-thesis kernel: usb 8-3: New USB device found,
idVendor=2109, idProduct=0817, bcdDevice= 7.74
May 03 02:16:14 angel-thesis kernel: usb 8-3: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
May 03 02:16:14 angel-thesis kernel: usb 8-3: Product: USB3.0 Hub             
May 03 02:16:14 angel-thesis kernel: usb 8-3: Manufacturer: VIA Labs, Inc.      
May 03 02:16:14 angel-thesis kernel: usb 8-3: SerialNumber: 000000000
May 03 02:16:14 angel-thesis kernel: usb 7-5: new high-speed USB device number
4 using xhci_hcd
May 03 02:16:14 angel-thesis kernel: usb 7-5: New USB device found,
idVendor=174c, idProduct=2074, bcdDevice= 0.01
May 03 02:16:14 angel-thesis kernel: usb 7-5: New USB device strings: Mfr=2,
Product=3, SerialNumber=0
May 03 02:16:14 angel-thesis kernel: usb 7-5: Product: ASM107x
May 03 02:16:14 angel-thesis kernel: usb 7-5: Manufacturer: ASUS TEK.
May 03 02:16:14 angel-thesis kernel: usb 7-2.3: new high-speed USB device
number 5 using xhci_hcd
May 03 02:16:14 angel-thesis kernel: usb 7-2.3: New USB device found,
idVendor=1a40, idProduct=0801, bcdDevice= 1.00
May 03 02:16:14 angel-thesis kernel: usb 7-2.3: New USB device strings: Mfr=0,
Product=1, SerialNumber=0
May 03 02:16:14 angel-thesis kernel: usb 7-2.3: Product: USB 2.0 Hub
May 03 02:16:15 angel-thesis kernel: usb 8-5: new SuperSpeed USB device number
4 using xhci_hcd
May 03 02:16:15 angel-thesis kernel: usb 8-5: New USB device found,
idVendor=174c, idProduct=3074, bcdDevice= 0.01
May 03 02:16:15 angel-thesis kernel: usb 8-5: New USB device strings: Mfr=2,
Product=3, SerialNumber=0
May 03 02:16:15 angel-thesis kernel: usb 8-5: Product: ASM107x
May 03 02:16:15 angel-thesis kernel: usb 8-5: Manufacturer: ASUS TEK.
May 03 02:16:15 angel-thesis kernel: usb 7-7: new high-speed USB device number
6 using xhci_hcd
May 03 02:16:15 angel-thesis kernel: usb 7-7: New USB device found,
idVendor=1e71, idProduct=300e, bcdDevice= 2.00
May 03 02:16:15 angel-thesis kernel: usb 7-7: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
May 03 02:16:15 angel-thesis kernel: usb 7-7: Product: NZXT Kraken Base
May 03 02:16:15 angel-thesis kernel: usb 7-7: Manufacturer: NZXT Inc.
May 03 02:16:15 angel-thesis kernel: usb 7-7: SerialNumber:
E7474745ABA22D589754E50CB2A69D11
May 03 02:16:15 angel-thesis kernel: nzxt_kraken3 0003:1E71:300E.0016: hidraw1:
USB HID v1.11 Device [NZXT Inc. NZXT Kraken Base] on usb-0000:6a:00.0-7/input1
May 03 02:16:15 angel-thesis kernel: usb 7-3.1: new full-speed USB device
number 7 using xhci_hcd
May 03 02:16:15 angel-thesis kernel: usb 8-3.4: new SuperSpeed USB device
number 5 using xhci_hcd
May 03 02:16:15 angel-thesis kernel: usb 8-3.4: New USB device found,
idVendor=2109, idProduct=0211, bcdDevice= 5.84
May 03 02:16:15 angel-thesis kernel: usb 8-3.4: New USB device strings: Mfr=1,
Product=2, SerialNumber=0
May 03 02:16:15 angel-thesis kernel: usb 8-3.4: Product: USB3.0 Hub             
May 03 02:16:15 angel-thesis kernel: usb 8-3.4: Manufacturer: VIA Labs, Inc.    
May 03 02:16:15 angel-thesis kernel: usb 7-3.1: New USB device found,
idVendor=046d, idProduct=c548, bcdDevice= 5.01
May 03 02:16:16 angel-thesis kernel: usb 7-3.1: New USB device strings: Mfr=1,
Product=2, SerialNumber=0
May 03 02:16:16 angel-thesis kernel: usb 7-3.1: Product: USB Receiver
May 03 02:16:16 angel-thesis kernel: usb 7-3.1: Manufacturer: Logitech
May 03 02:16:16 angel-thesis kernel: input: Logitech USB Receiver as
/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:6a:00.0/usb7/7-3/7-3.1/7-3.1:1.0/0003:046D:C548.0017/input/input26
May 03 02:16:16 angel-thesis kernel: usb 7-2.5: new high-speed USB device
number 8 using xhci_hcd
May 03 02:16:16 angel-thesis kernel: hid-generic 0003:046D:C548.0017:
input,hidraw2: USB HID v1.11 Keyboard [Logitech USB Receiver] on
usb-0000:6a:00.0-3.1/input0
May 03 02:16:16 angel-thesis kernel: usb 7-2.5: New USB device found,
idVendor=2109, idProduct=8817, bcdDevice= 0.01
May 03 02:16:16 angel-thesis kernel: usb 7-2.5: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
May 03 02:16:16 angel-thesis kernel: usb 7-2.5: Product: USB Billboard Device   
May 03 02:16:16 angel-thesis kernel: usb 7-2.5: Manufacturer: VIA Labs, Inc.    
May 03 02:16:16 angel-thesis kernel: usb 7-2.5: SerialNumber: 0000000000000001
May 03 02:16:16 angel-thesis kernel: input: Logitech USB Receiver Mouse as
/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:6a:00.0/usb7/7-3/7-3.1/7-3.1:1.1/0003:046D:C548.0018/input/input27
May 03 02:16:16 angel-thesis kernel: input: Logitech USB Receiver Consumer
Control as
/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:6a:00.0/usb7/7-3/7-3.1/7-3.1:1.1/0003:046D:C548.0018/input/input28
May 03 02:16:16 angel-thesis kernel: input: Logitech USB Receiver System
Control as
/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:6a:00.0/usb7/7-3/7-3.1/7-3.1:1.1/0003:046D:C548.0018/input/input29
May 03 02:16:16 angel-thesis kernel: hid-generic 0003:046D:C548.0018:
input,hidraw3: USB HID v1.11 Mouse [Logitech USB Receiver] on
usb-0000:6a:00.0-3.1/input1
May 03 02:16:16 angel-thesis kernel: usb 7-5.2: new high-speed USB device
number 9 using xhci_hcd
May 03 02:16:16 angel-thesis kernel: hid-generic 0003:046D:C548.0019:
hiddev97,hidraw4: USB HID v1.11 Device [Logitech USB Receiver] on
usb-0000:6a:00.0-3.1/input2
May 03 02:16:16 angel-thesis kernel: usb 7-5.2: New USB device found,
idVendor=046d, idProduct=c54d, bcdDevice=14.02
May 03 02:16:16 angel-thesis kernel: usb 7-5.2: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
May 03 02:16:16 angel-thesis kernel: usb 7-5.2: Product: USB Receiver
May 03 02:16:16 angel-thesis kernel: usb 7-5.2: Manufacturer: Logitech
May 03 02:16:16 angel-thesis kernel: usb 7-5.2: SerialNumber: 327534813432
May 03 02:16:16 angel-thesis kernel: input: Logitech USB Receiver as
/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:6a:00.0/usb7/7-5/7-5.2/7-5.2:1.0/0003:046D:C54D.001A/input/input30
May 03 02:16:16 angel-thesis kernel: hid-generic 0003:046D:C54D.001A:
input,hidraw5: USB HID v1.11 Mouse [Logitech USB Receiver] on
usb-0000:6a:00.0-5.2/input0
May 03 02:16:16 angel-thesis kernel: usb 7-2.3.1: new full-speed USB device
number 10 using xhci_hcd
May 03 02:16:16 angel-thesis kernel: input: Logitech USB Receiver Keyboard as
/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:6a:00.0/usb7/7-5/7-5.2/7-5.2:1.1/0003:046D:C54D.001B/input/input31
May 03 02:16:16 angel-thesis kernel: hid-generic 0003:046D:C54D.001B:
input,hidraw7: USB HID v1.11 Keyboard [Logitech USB Receiver] on
usb-0000:6a:00.0-5.2/input1
May 03 02:16:16 angel-thesis kernel: hid-generic 0003:046D:C54D.001C:
hiddev98,hidraw8: USB HID v1.11 Device [Logitech USB Receiver] on
usb-0000:6a:00.0-5.2/input2
May 03 02:16:16 angel-thesis kernel: usb 7-2.3.1: config 1 has an invalid
interface number: 5 but max is 3
May 03 02:16:16 angel-thesis kernel: usb 7-2.3.1: config 1 has no interface
number 3
May 03 02:16:16 angel-thesis kernel: usb 7-2.3.1: New USB device found,
idVendor=19f7, idProduct=004e, bcdDevice= 1.54
May 03 02:16:16 angel-thesis kernel: usb 7-2.3.1: New USB device strings:
Mfr=1, Product=2, SerialNumber=3
May 03 02:16:16 angel-thesis kernel: usb 7-2.3.1: Product: RØDECaster Duo
May 03 02:16:16 angel-thesis kernel: usb 7-2.3.1: Manufacturer: RØDE
May 03 02:16:16 angel-thesis kernel: usb 7-11: new full-speed USB device number
11 using xhci_hcd
May 03 02:16:16 angel-thesis kernel: usb 7-2.3.1: 1:1: cannot get freq at ep
0x82
May 03 02:16:16 angel-thesis kernel: usb 7-2.3.1: 1:2: cannot get freq at ep
0x82
May 03 02:16:16 angel-thesis kernel: usb 7-2.3.1: 2:1: cannot get freq at ep
0x2
May 03 02:16:17 angel-thesis kernel: usb 7-11: config 1 has an invalid
interface number: 2 but max is 1
May 03 02:16:17 angel-thesis kernel: usb 7-11: config 1 has no interface number
1
May 03 02:16:17 angel-thesis kernel: usb 7-11: New USB device found,
idVendor=0b05, idProduct=18f3, bcdDevice= 1.00
May 03 02:16:17 angel-thesis kernel: usb 7-11: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
May 03 02:16:17 angel-thesis kernel: usb 7-11: Product: AURA LED Controller
May 03 02:16:17 angel-thesis kernel: usb 7-11: Manufacturer: AsusTek Computer
Inc.
May 03 02:16:17 angel-thesis kernel: usb 7-11: SerialNumber: 9876543210
May 03 02:16:17 angel-thesis kernel: hid-generic 0003:0B05:18F3.001D:
hiddev99,hidraw9: USB HID v1.11 Device [AsusTek Computer Inc. AURA LED
Controller] on usb-0000:6a:00.0-11/input2
May 03 02:16:17 angel-thesis mtp-probe[94519]: checking bus 7, device 11:
"/sys/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:6a:00.0/usb7/7-11"
May 03 02:16:17 angel-thesis mtp-probe[94520]: checking bus 7, device 6:
"/sys/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:6a:00.0/usb7/7-7"
May 03 02:16:17 angel-thesis kernel: usb 7-3.3: new high-speed USB device
number 12 using xhci_hcd
May 03 02:16:17 angel-thesis mtp-probe[94537]: checking bus 7, device 9:
"/sys/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:6a:00.0/usb7/7-5/7-5.2"
May 03 02:16:17 angel-thesis mtp-probe[94545]: checking bus 7, device 6:
"/sys/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:6a:00.0/usb7/7-7"
May 03 02:16:17 angel-thesis kernel: usb 7-3.3: New USB device found,
idVendor=2e1a, idProduct=4c03, bcdDevice= 2.00
May 03 02:16:17 angel-thesis kernel: usb 7-3.3: New USB device strings: Mfr=1,
Product=2, SerialNumber=0
May 03 02:16:17 angel-thesis kernel: usb 7-3.3: Product: Insta360 Link 2C
May 03 02:16:17 angel-thesis kernel: usb 7-3.3: Manufacturer: Insta360
May 03 02:16:17 angel-thesis kernel: usb 7-3.3: Found UVC 1.10 device Insta360
Link 2C (2e1a:4c03)
May 03 02:16:17 angel-thesis kernel: usb 7-2.3.2: new full-speed USB device
number 13 using xhci_hcd
May 03 02:16:17 angel-thesis kernel: usb 7-3.3: Warning! Unlikely big volume
range (=32767), cval->res is probably wrong.
May 03 02:16:17 angel-thesis kernel: usb 7-3.3: [9] FU [Mic Capture Volume] ch
= 1, val = -32768/-1/1
May 03 02:16:17 angel-thesis kernel: usb 7-2.3.2: New USB device found,
idVendor=31e3, idProduct=1322, bcdDevice= 2.30
May 03 02:16:18 angel-thesis kernel: usb 7-2.3.2: New USB device strings:
Mfr=1, Product=2, SerialNumber=3
May 03 02:16:18 angel-thesis kernel: usb 7-2.3.2: Product: Wooting 60HE+
May 03 02:16:18 angel-thesis kernel: usb 7-2.3.2: Manufacturer: Wooting
May 03 02:16:18 angel-thesis kernel: usb 7-2.3.2: SerialNumber:
A02B2422W05T01100S02H23388
May 03 02:16:18 angel-thesis kernel: usb 7-3.4: new high-speed USB device
number 14 using xhci_hcd
May 03 02:16:18 angel-thesis kernel: hid-generic 0003:31E3:1322.001E:
hiddev101,hidraw10: USB HID v1.11 Device [Wooting Wooting 60HE+] on
usb-0000:6a:00.0-2.3.2/input0
May 03 02:16:18 angel-thesis kernel: input: Wooting Wooting 60HE+ as
/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:6a:00.0/usb7/7-2/7-2.3/7-2.3.2/7-2.3.2:1.1/0003:31E3:1322.001F/input/input32
May 03 02:16:18 angel-thesis kernel: hid-generic 0003:31E3:1322.001F:
input,hidraw11: USB HID v1.11 Keyboard [Wooting Wooting 60HE+] on
usb-0000:6a:00.0-2.3.2/input1
May 03 02:16:18 angel-thesis kernel: usb 7-3.4: New USB device found,
idVendor=2109, idProduct=2211, bcdDevice= 5.84
May 03 02:16:18 angel-thesis kernel: usb 7-3.4: New USB device strings: Mfr=1,
Product=2, SerialNumber=0
May 03 02:16:18 angel-thesis kernel: usb 7-3.4: Product: USB2.0 Hub             
May 03 02:16:18 angel-thesis kernel: usb 7-3.4: Manufacturer: VIA Labs, Inc.    
May 03 02:16:18 angel-thesis kernel: hid-generic 0003:31E3:1322.0020:
hiddev102,hidraw12: USB HID v1.11 Device [Wooting Wooting 60HE+] on
usb-0000:6a:00.0-2.3.2/input2
May 03 02:16:18 angel-thesis kernel: input: Wooting Wooting 60HE+ System
Control as
/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:6a:00.0/usb7/7-2/7-2.3/7-2.3.2/7-2.3.2:1.3/0003:31E3:1322.0021/input/input33
May 03 02:16:18 angel-thesis kernel: input: Wooting Wooting 60HE+ Consumer
Control as
/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:6a:00.0/usb7/7-2/7-2.3/7-2.3.2/7-2.3.2:1.3/0003:31E3:1322.0021/input/input34
May 03 02:16:18 angel-thesis kernel: input: Wooting Wooting 60HE+ Mouse as
/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:6a:00.0/usb7/7-2/7-2.3/7-2.3.2/7-2.3.2:1.3/0003:31E3:1322.0021/input/input35
May 03 02:16:18 angel-thesis kernel: hid-generic 0003:31E3:1322.0021:
input,hidraw13: USB HID v1.11 Mouse [Wooting Wooting 60HE+] on
usb-0000:6a:00.0-2.3.2/input3
May 03 02:16:18 angel-thesis kernel: hid-generic 0003:31E3:1322.0022:
hiddev103,hidraw14: USB HID v1.11 Device [Wooting Wooting 60HE+] on
usb-0000:6a:00.0-2.3.2/input4
May 03 02:16:18 angel-thesis kernel: usb 7-3.5: new high-speed USB device
number 15 using xhci_hcd
May 03 02:16:18 angel-thesis mtp-probe[94588]: checking bus 7, device 10:
"/sys/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:6a:00.0/usb7/7-2/7-2.3/7-2.3.1"
May 03 02:16:18 angel-thesis mtp-probe[94589]: checking bus 7, device 13:
"/sys/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:6a:00.0/usb7/7-2/7-2.3/7-2.3.2"
May 03 02:16:18 angel-thesis mtp-probe[94633]: checking bus 7, device 10:
"/sys/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:6a:00.0/usb7/7-2/7-2.3/7-2.3.1"
May 03 02:16:18 angel-thesis kernel: usb 7-3.5: New USB device found,
idVendor=2109, idProduct=8884, bcdDevice= 0.01
May 03 02:16:18 angel-thesis kernel: usb 7-3.5: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
May 03 02:16:18 angel-thesis kernel: usb 7-3.5: Product: USB Billboard Device   
May 03 02:16:18 angel-thesis kernel: usb 7-3.5: Manufacturer: VIA Labs, Inc.    
May 03 02:16:18 angel-thesis kernel: usb 7-3.5: SerialNumber: 0000000000000001
May 03 02:16:18 angel-thesis mtp-probe[94639]: checking bus 7, device 7:
"/sys/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:6a:00.0/usb7/7-3/7-3.1"
May 03 02:16:18 angel-thesis mtp-probe[94640]: checking bus 7, device 12:
"/sys/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:6a:00.0/usb7/7-3/7-3.3"
May 03 02:16:18 angel-thesis mtp-probe[94679]: checking bus 7, device 12:
"/sys/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:6a:00.0/usb7/7-3/7-3.3"
May 03 02:16:18 angel-thesis mtp-probe[94686]: checking bus 7, device 9:
"/sys/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:6a:00.0/usb7/7-5/7-5.2"
May 03 02:16:18 angel-thesis mtp-probe[94687]: checking bus 7, device 11:
"/sys/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:6a:00.0/usb7/7-11"
```

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #24 from Michał Pecio ([email protected]) --- Great. By the way, did you suspend, reboot or unbind xhci_hcd after taking the working system debugfs dumps and before it died? Unfortunately, the "dead" dump is missing information about connected devices, because they got dropped after "HC died".

Below are the final commands executed by the HC. Their cycle bits are all set ("flags C") and there is no evidence of Stop Endpoint retries anywhere in the whole command ring dump, so this is not any of the known or obviously suspected problems, but something new and weird.

Stop Ring Command: slot 19 sp 0 ep 3 flags C
Set TR Dequeue Pointer Command: deq 00000000ffead3c0 stream 0 slot 19 ep 3 flags C
Stop Ring Command: slot 19 sp 1 ep 1 flags C
Stop Ring Command: slot 19 sp 0 ep 3 flags C
Set TR Dequeue Pointer Command: deq 00000000ffead3d0 stream 0 slot 19 ep 3 flags C
Stop Ring Command: slot 19 sp 1 ep 1 flags C
Stop Ring Command: slot 6 sp 0 ep 5 flags C
Set TR Dequeue Pointer Command: deq 00000000fffddbc1 stream 0 slot 6 ep 5 flags C
Stop Ring Command: slot 6 sp 0 ep 5 flags C
Set TR Dequeue Pointer Command: deq 00000000fffddbd1 stream 0 slot 6 ep 5 flags C
Stop Ring Command: slot 6 sp 0 ep 5 flags C
Set TR Dequeue Pointer Command: deq 00000000fffddbe1 stream 0 slot 6 ep 5 flags C
Stop Ring Command: slot 6 sp 0 ep 5 flags C
Set TR Dequeue Pointer Command: deq 00000000fffddbf1 stream 0 slot 6 ep 5 flags C
Stop Ring Command: slot 6 sp 0 ep 5 flags C
Set TR Dequeue Pointer Command: deq 00000000fffddc01 stream 0 slot 6 ep 5 flags C
Stop Ring Command: slot 6 sp 0 ep 5 flags C
Set TR Dequeue Pointer Command: deq 00000000fffddc11 stream 0 slot 6 ep 5 flags C
Stop Ring Command: slot 19 sp 0 ep 1 flags C
Reset Device Command: slot 16 flags C
Reset Device Command: slot 19 flags C
Reset Device Command: slot 19 flags C
Address Device Command: ctx 00000000fff42000 slot 19 flags b:C Disable Slot Command: slot 19 flags C
Enable Slot Command: flags C
Address Device Command: ctx 00000000fff42000 slot 20 flags b:C Stop Ring Command: slot 6 sp 0 ep 5 flags C

Initially, we see the familiar pattern of canceling a pending transfer on slot 19 ep 3 and stopping slot 19 ep 1 (the control endpoint) with "sp 1", which is a hint that the device will be suspended. This is probably the 8-3 hub again.

Then there is some action on slot 6 ep 5, which I don't understand because information about devices is not available. In the earlier debugfs dump from a working system slot 6 was the ASM107x hub, but endpoint id 5 was *not* enabled on it, so that makes no sense.

Things begin to get unusual now: stop endpoint on slot 19 ep 1 with "sp 0", then some devices are being reset. The last two commands fail to complete and the HC hangs when the driver tries to abort them.

Looking at the event ring, the "unknown event type 4" actually points to the Address Device command for slot 20, so maybe the HC completed this command (but was already fubared enough to produce a corrupted event) and then got stuck for real on the final command for slot 6.

But it was already fubared at this point, so something went wrong with those resets or it was the slot 6 ep 5 churn which broke it. That looks like repeatedly canceling a pending transfer before it completes and then resubmitting a similar transfer, and IME such pattern can break "ass media" HCs if they repeat fast enough... (no timestapms here, unfortunately).

Not entirely sure what to think about it yet, I will take a closer look at the whole event ring later.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #25 from Claudio Wunder ([email protected]) --- Some extra info:

- This time the computer was on idle when it happened, like I wasn't even close to the PC but noticed something odd happened, hence checked and saw it was dead
- Running usbreset of the controller and yavta on a loop for about one hour did not occur on any USB crash; So I doubt it is something related to heavy workloads on the controller.
- Afaik the ASM107x device is disabled on EFI;

Regarding the different slots, I'm not sure if the devices order/attachment can change on unbind/bind (I believe so) or just on a new boot, but here's the output of lspci and lsusb from the current boot (same as the crash)

```
❯ lspci -nn | grep USB
03:00.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 31
USB [1002:7446]
0f:00.0 USB controller [0c03]: Intel Corporation Thunderbolt 4 NHI [Maple Ridge
4C 2020] [8086:1137]
3b:00.0 USB controller [0c03]: Intel Corporation Thunderbolt 4 USB Controller
[Maple Ridge 4C 2020] [8086:1138]
68:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset USB 3.2 Controller [1022:43f7] (rev 01)
6a:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset USB 3.2 Controller [1022:43f7] (rev 01)
6c:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
Raphael/Granite Ridge USB 3.1 xHCI [1022:15b6]
6c:00.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
Raphael/Granite Ridge USB 3.1 xHCI [1022:15b7]
6d:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
Raphael/Granite Ridge USB 2.0 xHCI [1022:15b8]
❯ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 19f7:0050 RODE Microphones RODECaster Duo
Bus 005 Device 003: ID 8087:0032 Intel Corp. AX210 Bluetooth
Bus 005 Device 004: ID 0b05:1a53 ASUSTek Computer, Inc. USB Audio
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 004: ID 174c:2074 ASMedia Technology Inc. ASM1074 High-Speed hub
Bus 007 Device 006: ID 1e71:300e NZXT NZXT Kraken Base
Bus 007 Device 009: ID 046d:c54d Logitech, Inc. USB Receiver
Bus 007 Device 011: ID 0b05:18f3 ASUSTek Computer, Inc. AURA LED Controller
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 008 Device 004: ID 174c:3074 ASMedia Technology Inc. ASM1074 SuperSpeed hub
Bus 009 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 010 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 011 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 012 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 013 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 014 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
```

Also one extra info, I have an udev rule to prevent USB devices to wake up my PC from sleep. I doubt it has anything to do with it, but worth sharing:

```
❯ bat /etc/udev/rules.d/99-usb-wakeup.rules
───────┬───────────────────────────────────────────────────────────
       │ File: /etc/udev/rules.d/99-usb-wakeup.rules
───────┼───────────────────────────────────────────────────────────
   1   │ ACTION=="add", SUBSYSTEM=="usb", RUN+="/bin/sh -c 'echo di
       │ sabled > /sys/bus/usb/devices/%k/power/wakeup'"
───────┴───────────────────────────────────────────────────────────
```

(Note the issue was happening even before this rule existed afaik)

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #26 from Claudio Wunder ([email protected]) ---

Is there anything extra I could provide?

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #27 from Claudio Wunder ([email protected]) --- Another crash happened; Same condition, idle.

```
❯ lspci -nn | grep USB
03:00.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 31
USB [1002:7446]
0f:00.0 USB controller [0c03]: Intel Corporation Thunderbolt 4 NHI [Maple Ridge
4C 2020] [8086:1137]
3b:00.0 USB controller [0c03]: Intel Corporation Thunderbolt 4 USB Controller
[Maple Ridge 4C 2020] [8086:1138]
68:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset USB 3.2 Controller [1022:43f7] (rev 01)
6a:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset USB 3.2 Controller [1022:43f7] (rev 01)
6c:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
Raphael/Granite Ridge USB 3.1 xHCI [1022:15b6]
6c:00.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
Raphael/Granite Ridge USB 3.1 xHCI [1022:15b7]
6d:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
Raphael/Granite Ridge USB 2.0 xHCI [1022:15b8]
❯ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 002: ID 2109:4817 VIA Labs, Inc. USB2.0 Hub             
Bus 007 Device 003: ID 2109:2817 VIA Labs, Inc. USB2.0 Hub             
Bus 007 Device 004: ID 174c:2074 ASMedia Technology Inc. ASM1074 High-Speed hub
Bus 007 Device 005: ID 1a40:0801 Terminus Technology Inc. USB 2.0 Hub
Bus 007 Device 006: ID 1e71:300e NZXT NZXT Kraken Base
Bus 007 Device 007: ID 046d:c548 Logitech, Inc. Logi Bolt Receiver
Bus 007 Device 008: ID 2109:8817 VIA Labs, Inc. USB Billboard Device   
Bus 007 Device 009: ID 046d:c54d Logitech, Inc. USB Receiver
Bus 007 Device 010: ID 19f7:004e RODE Microphones RØDECaster Duo
Bus 007 Device 011: ID 0b05:18f3 ASUSTek Computer, Inc. AURA LED Controller
Bus 007 Device 012: ID 2e1a:4c03 Insta360 Insta360 Link 2C
Bus 007 Device 013: ID 31e3:1322 Wooting Wooting 60HE+
Bus 007 Device 014: ID 2109:2211 VIA Labs, Inc. USB2.0 Hub             
Bus 007 Device 015: ID 2109:8884 VIA Labs, Inc. USB Billboard Device   
Bus 007 Device 016: ID 0cf2:a201 ENE Technology, Inc. 6K7732
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 008 Device 002: ID 2109:3817 VIA Labs, Inc. USB3.0 Hub             
Bus 008 Device 003: ID 2109:0817 VIA Labs, Inc. USB3.0 Hub             
Bus 008 Device 004: ID 174c:3074 ASMedia Technology Inc. ASM1074 SuperSpeed hub
Bus 008 Device 005: ID 2109:0211 VIA Labs, Inc. USB3.0 Hub             
Bus 009 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 010 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 011 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 012 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 013 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 014 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
```

Interestingly enough, these last two crashes happened after a system update.

```
❯ rpm-ostree status
State: idle
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable
                   Digest:
sha256:91f041cd775526e8fe11089a1ca3433224cb9b5d1580c3ceb50973ec558f6dd9
                  Version: 42.20250430 (2025-05-01T19:32:10Z)
          LayeredPackages: android-tools
            LocalPackages: 1password-8.10.70-1.x86_64
sublime-text-4192-1.x86_64

  ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable
                   Digest:
sha256:1a7ae28b95fde42b976cc9aa159219c0aaaa0611f7416f4b3b30284e292b0875
                  Version: 42.20250417 (2025-04-17T07:35:37Z)
          LayeredPackages: android-tools
            LocalPackages: 1password-8.10.70-1.x86_64
sublime-text-4192-1.x86_64
```

I'm on

```
❯ uname -r
6.14.4-103.bazzite.fc42.x86_64
```

Zip file:
https://gist.github.com/ovflowd/0b0aa5c748683eca33909dc3ed7c66f7#file-debugfs-03-05-2025-zip

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #28 from Michał Pecio ([email protected]) --- Created attachment 308078
--> https://bugzilla.kernel.org/attachment.cgi?id=308078&action=edit
collect xhc crash data and reset the thing

Could you run this script?

It tries to catch debugfs after the controller hangs, but before the kernel "kills" it and forgets about all devices. It simply saves debugfs every few seconds, and packs the saved copy plus current debugfs and dmesg to a tgz archive when all devices disappear. Then it automatically resets the controller. Don't disconnect all devices by hand ;)

The outdir and tmpdir paths need to be set to point at existing directories, and PCI ID is passed as an argument - use lspci to know if it's currently 0000:6a:00.0 or 0000:6b:00.0.

I think it's somehow related to the 7-3/8-3 (USB 2.0/3.0 parts) hub, and its children - either the 7-3.4/8-3.4 hub or the 7-3.3 webcam. Would it be possible to move one of those child devices to another place so that it goes to a different bus? Perhaps bus 5, which is the first 600 chipset controller, so we could see if the problem moves to the first 600 controller or stays on the second one.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #29 from Claudio Wunder ([email protected]) ---

The webcam and another USB dongle are connected on the monitor's USB hub; That hub is connected directly to one of the rear USB ports; Do you want me to connect them to the other bus? (5) -- Note that these are also one of the rear USB ports.

Also note that if the problem is 8-3 I don't think there's much I can do, as ASM107x is an internal device from the Motherboard; Also the "6K7732" device is (7-3.4 hub only device) a LED (it is just a simple LED backlight, it has no USB functionality whatsoever; There is also the AURA Led Controller and NZXT Kraken Base all devices under (7) but connected directly to the Mobo, and that I could remove.

Anyhow, I can move the monitor Hub to another rear USB port and also run your script.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #30 from Michał Pecio ([email protected]) --- Sorry, I'm not talking about those device numbers from lsusb - they can change on reboot, suspend or xhci_hcd rebind, they are not reliable.

The only somewhat constant addressing scheme is the one in dmesg: 7-3 is a device on the 3rd port of bus 7, and if 7-3 is a hub then 7-3.4 is a device on the 4th port of this hub, and if 7-3.4 is also a hub, then 7-3.4.2 is its second port. This doesn't change until you actually move USB plugs around. So I'm referring to those addresses from dmesg.

If hubs can't be separated then fine, start with moving the webcam away.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #31 from Claudio Wunder ([email protected]) --- Noted. I will do the following:

- Update the System (as I rollbacked to 6.13.9; 6.14.3/6.14.4 seem to be more unstable (the bug occurs consistently way more often)
- Mount debugfs
- Run your script and keep it running
- Wait for a crash; Add attachments here (only now noticed I can add attachments here)
- Then try the change webcam and whatnot to different Hub
- Wait for another crash

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #32 from Claudio Wunder ([email protected]) --- Created attachment 308082
--> https://bugzilla.kernel.org/attachment.cgi?id=308082&action=edit
Autopsy Result

A new crash happened, added the autopsy!

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #33 from Claudio Wunder ([email protected]) --- Created attachment 308090
--> https://bugzilla.kernel.org/attachment.cgi?id=308090&action=edit
Autopsy Result (2)

A 2nd crash happened, sending another autopsy. After this crash I moved the Monitor Hub (Webcam etc) to Bus 5.

```
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 19f7:0050 RODE Microphones RODECaster Duo
Bus 005 Device 003: ID 8087:0032 Intel Corp. AX210 Bluetooth
Bus 005 Device 004: ID 0b05:1a53 ASUSTek Computer, Inc. USB Audio
Bus 005 Device 005: ID 2109:2817 VIA Labs, Inc. USB2.0 Hub             
Bus 005 Device 006: ID 046d:c548 Logitech, Inc. Logi Bolt Receiver
Bus 005 Device 007: ID 2e1a:4c03 Insta360 Insta360 Link 2C
Bus 005 Device 008: ID 2109:2211 VIA Labs, Inc. USB2.0 Hub             
Bus 005 Device 009: ID 2109:8884 VIA Labs, Inc. USB Billboard Device   
Bus 005 Device 010: ID 0cf2:a201 ENE Technology, Inc. 6K7732
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 006 Device 002: ID 2109:0817 VIA Labs, Inc. USB3.0 Hub             
Bus 006 Device 003: ID 2109:0211 VIA Labs, Inc. USB3.0 Hub             
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 004: ID 174c:2074 ASMedia Technology Inc. ASM1074 High-Speed hub
Bus 007 Device 006: ID 1e71:300e NZXT NZXT Kraken Base
Bus 007 Device 009: ID 046d:c54d Logitech, Inc. USB Receiver
Bus 007 Device 011: ID 0b05:18f3 ASUSTek Computer, Inc. AURA LED Controller
Bus 007 Device 027: ID 2109:4817 VIA Labs, Inc. USB2.0 Hub             
Bus 007 Device 028: ID 1a40:0801 Terminus Technology Inc. USB 2.0 Hub
Bus 007 Device 029: ID 2109:8817 VIA Labs, Inc. USB Billboard Device   
Bus 007 Device 030: ID 19f7:004e RODE Microphones RØDECaster Duo
Bus 007 Device 031: ID 31e3:1322 Wooting Wooting 60HE+
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 008 Device 004: ID 174c:3074 ASMedia Technology Inc. ASM1074 SuperSpeed hub
Bus 008 Device 008: ID 2109:3817 VIA Labs, Inc. USB3.0 Hub             
Bus 009 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 010 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 011 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 012 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 013 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 014 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
```

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #34 from Claudio Wunder ([email protected]) ---
Looks like a 3rd crash happened, interestingly enough, the script did not detect a 3rd crash and did not send an unbind/bind command; But the Bus (5) got completely disconnected, Bus (7) which previously had the webcam, now is still working. I did not have the autopsy command running for Bus (5) so no logs; But Ill start it now and keep an eye on it.

```
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Root Complex [1022:14d8]
00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge
IOMMU [1022:14d9]
00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Dummy Host Bridge [1022:14da]
00:01.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge GPP Bridge [1022:14db]
00:01.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge GPP Bridge [1022:14db]
00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Dummy Host Bridge [1022:14da]
00:02.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge GPP Bridge [1022:14db]
00:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Dummy Host Bridge [1022:14da]
00:04.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Dummy Host Bridge [1022:14da]
00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Dummy Host Bridge [1022:14da]
00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Internal GPP Bridge to Bus [C:A] [1022:14dd]
00:08.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Internal GPP Bridge to Bus [C:A] [1022:14dd]
00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller
[1022:790b] (rev 71)
00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge
[1022:790e] (rev 51)
00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Data Fabric; Function 0 [1022:14e0]
00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Data Fabric; Function 1 [1022:14e1]
00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Data Fabric; Function 2 [1022:14e2]
00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Data Fabric; Function 3 [1022:14e3]
00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Data Fabric; Function 4 [1022:14e4]
00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Data Fabric; Function 5 [1022:14e5]
00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Data Fabric; Function 6 [1022:14e6]
00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
Ridge Data Fabric; Function 7 [1022:14e7]
01:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL
Upstream Port of PCI Express Switch [1002:1478] (rev 10)
02:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL
Downstream Port of PCI Express Switch [1002:1479] (rev 10)
03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Navi 31 [Radeon RX 7900 XT/7900 XTX/7900 GRE/7900M] [1002:744c] (rev
c8)
03:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 31
HDMI/DP Audio [1002:ab30]
03:00.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 31
USB [1002:7446]
03:00.3 Serial bus controller [0c80]: Advanced Micro Devices, Inc. [AMD/ATI]
Device [1002:7444]
04:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe
SSD Controller S4LV008[Pascal] [144d:a80c]
05:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Upstream Port [1022:43f4] (rev 01)
06:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Downstream Port [1022:43f5] (rev 01)
06:08.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Downstream Port [1022:43f5] (rev 01)
06:0c.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Downstream Port [1022:43f5] (rev 01)
06:0d.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Downstream Port [1022:43f5] (rev 01)
08:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Upstream Port [1022:43f4] (rev 01)
09:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Downstream Port [1022:43f5] (rev 01)
09:01.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Downstream Port [1022:43f5] (rev 01)
09:02.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Downstream Port [1022:43f5] (rev 01)
09:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Downstream Port [1022:43f5] (rev 01)
09:08.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Downstream Port [1022:43f5] (rev 01)
09:0c.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Downstream Port [1022:43f5] (rev 01)
09:0d.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset PCIe Switch Downstream Port [1022:43f5] (rev 01)
0a:00.0 Network controller [0280]: Intel Corporation Wi-Fi 6E(802.11ax)
AX210/AX1675* 2x2 [Typhoon Peak] [8086:2725] (rev 1a)
0b:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller
I225-V [8086:15f3] (rev 03)
0d:00.0 PCI bridge [0604]: Intel Corporation Thunderbolt 4 Bridge [Maple Ridge
4C 2020] [8086:1136] (rev 02)
0e:00.0 PCI bridge [0604]: Intel Corporation Thunderbolt 4 Bridge [Maple Ridge
4C 2020] [8086:1136] (rev 02)
0e:01.0 PCI bridge [0604]: Intel Corporation Thunderbolt 4 Bridge [Maple Ridge
4C 2020] [8086:1136] (rev 02)
0e:02.0 PCI bridge [0604]: Intel Corporation Thunderbolt 4 Bridge [Maple Ridge
4C 2020] [8086:1136] (rev 02)
0e:03.0 PCI bridge [0604]: Intel Corporation Thunderbolt 4 Bridge [Maple Ridge
4C 2020] [8086:1136] (rev 02)
0f:00.0 USB controller [0c03]: Intel Corporation Thunderbolt 4 NHI [Maple Ridge
4C 2020] [8086:1137]
3b:00.0 USB controller [0c03]: Intel Corporation Thunderbolt 4 USB Controller
[Maple Ridge 4C 2020] [8086:1138]
68:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset USB 3.2 Controller [1022:43f7] (rev 01)
69:00.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset SATA Controller [1022:43f6] (rev 01)
6a:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset USB 3.2 Controller [1022:43f7] (rev 01)
6b:00.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] 600 Series
Chipset SATA Controller [1022:43f6] (rev 01)
6c:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Granite Ridge [Radeon Graphics] [1002:13c0] (rev cb)
6c:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt
Radeon High Definition Audio Controller [1002:1640]
6c:00.2 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Family
19h PSP/CCP [1022:1649]
6c:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
Raphael/Granite Ridge USB 3.1 xHCI [1022:15b6]
6c:00.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
Raphael/Granite Ridge USB 3.1 xHCI [1022:15b7]
6d:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
Raphael/Granite Ridge USB 2.0 xHCI [1022:15b8]
```

```
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 19f7:0050 RODE Microphones RODECaster Duo
Bus 005 Device 003: ID 2109:2817 VIA Labs, Inc. USB2.0 Hub             
Bus 005 Device 004: ID 8087:0032 Intel Corp. AX210 Bluetooth
Bus 005 Device 005: ID 046d:c548 Logitech, Inc. Logi Bolt Receiver
Bus 005 Device 006: ID 0b05:1a53 ASUSTek Computer, Inc. USB Audio
Bus 005 Device 009: ID 2109:2211 VIA Labs, Inc. USB2.0 Hub             
Bus 005 Device 010: ID 2109:8884 VIA Labs, Inc. USB Billboard Device   
Bus 005 Device 011: ID 0cf2:a201 ENE Technology, Inc. 6K7732
Bus 005 Device 012: ID 2e1a:4c03 Insta360 Insta360 Link 2C
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 006 Device 002: ID 2109:0817 VIA Labs, Inc. USB3.0 Hub             
Bus 006 Device 003: ID 2109:0211 VIA Labs, Inc. USB3.0 Hub             
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 004: ID 174c:2074 ASMedia Technology Inc. ASM1074 High-Speed hub
Bus 007 Device 006: ID 1e71:300e NZXT NZXT Kraken Base
Bus 007 Device 009: ID 046d:c54d Logitech, Inc. USB Receiver
Bus 007 Device 011: ID 0b05:18f3 ASUSTek Computer, Inc. AURA LED Controller
Bus 007 Device 027: ID 2109:4817 VIA Labs, Inc. USB2.0 Hub             
Bus 007 Device 028: ID 1a40:0801 Terminus Technology Inc. USB 2.0 Hub
Bus 007 Device 029: ID 2109:8817 VIA Labs, Inc. USB Billboard Device   
Bus 007 Device 030: ID 19f7:004e RODE Microphones RØDECaster Duo
Bus 007 Device 031: ID 31e3:1322 Wooting Wooting 60HE+
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 008 Device 004: ID 174c:3074 ASMedia Technology Inc. ASM1074 SuperSpeed hub
Bus 008 Device 008: ID 2109:3817 VIA Labs, Inc. USB3.0 Hub             
Bus 009 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 010 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 011 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 012 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 013 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 014 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
```

OOC -

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #35 from Claudio Wunder ([email protected]) ---
I found out my Monitor has an interesting setting that "puts USB devices to sleep"; I disabled that (and set the USB Hub on the monitor settings to USB 2.0 instead of 3.2); Something tells me maybe this "usb sleep setting" could be related.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #36 from Michał Pecio ([email protected]) --- Restricting power management may reduce occurrences of this problem, maybe even to nothing or almost nothing, because things are breaking while resuming a hub from autosuspend. However, I don't think that power management is the root cause or the only workload which could run into trouble, it's just the one which happens often enough to be regularly running into trouble on your system.

I see a few things being wrong or suspicious here.

1. The "average TRB length" properly of all Control Endpoint Contexts is set to zero, but it should be 8. This was recently reported as a violation of the xHCI spec with no known impact. It is probably irrelevant, but who knows - this should ideally be fixed for peace of mind. It can only be solved by a kernel patch.

2. The webcam driver regularly generates a burts of transfer cancellations, which is a known problem case. The command sequences and their completion events look OK, but IME ASMedia and Promontory can still behave weird under such conditions.

3. Sometimes when 8-3 hub resume happens some time after (or during) the webcam driver activity burst, it fails. And it fails weirdly: dmesg suggests that some control transfer to confirm the resumed hub's status times out, and when a Stop Endpoint command is issued to cancel the transfer, we suddenly get an event informing about a Transaction Error instead, and the Endpoint Context may or may not indicate that the control endpoint is halted (which it should be after an error), and yet the Stop Command succeeds (which it shouldn't), and we may get multiple "Stopped" events (we shouldn't) before the command's completion event.

This is similar to misbehaviors I have been seeing due to problem #2 in the past.

4. Then an odd sequence of Reset Device commands is issued, probably courtesy of

2c31b05c63cf usb: hub: lack of clearing xHC resources

which landed in 6.13.7 and 6.14+. I wouldn't be surprised if there are some spec violations in this commit, but I'm not sure if they would be harmful in this case.

We probably shouldn't be issuing Reset Device for the child 8-3.4 hub here. We don't need to (and probably shouldn't) be issuing Reset Device 8-3 twice.

5. Lastly, attempts to reset 8-3 are not improving the situation and the hub driver tries to disable and enable the device slot, and address the device again.

Hard to tell what's the outcome of this command, because it appears to generate a mangled completion event ("unknown event type <number>"). However, the event does contain a pointer to this command. It is possible that the HC progresses to the next command.

6. Very lastly, all unrelated transfers stop happening and a Stop Endpoint command issued to the webcam endpoint either never is reached, or hangs the HC for good.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #37 from Michał Pecio ([email protected]) ---
I would suggest to reenable power management, and try something else. If you moved the problematic hubs to bus 5, try to move the problematic webcam to bus 7.

If bus 5 crashes, the problem is only hubs and the webcam is harmless. If bus 7 crashes, the problem is the webcam.
If neither bus crashes for a few days, it looks like it takes two to the tango.

You could also try a quirk which seems to reduce some bizarre failures on my AMD B350 chipset. If your kernel has xhci_hcd and xhci_pci built as modules, run:

rmmod xhci_pci xhci_hcd ; modprobe xhci_hcd quirks=0x4000000 ; modprobe xhci_pci

If they are built into the kernel image, you need to figure out how to add

xhci_hcd.quirks=0x4000000

to the kernel boot parameters in your distribution's bootloader config.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #38 from Claudio Wunder ([email protected]) --- That's very useful (all the commentary)!

By the way,

Ignore this, I facepalmed myself afterwards, of course it would only unbind/bind and capture 6a since that's what I provided to the script. I modified the script adding support to "multiple" pci ids and generating the folders and dumps prefixed with the pciid.

Noted, Ill first keep it off for one more day to see a crash happens; Then Ill re-enable it afterwards.

If bus 7 crashes, the problem is the webcam.
If neither bus crashes for a few days, it looks like it takes two to the tango.

Ill attempt these distribution steps.

lsmod doesn't seem to list either xhci_pci and xhci_hcd as modules;

Seems the case. Can I add this flag via grub?

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #39 from Michał Pecio ([email protected]) --- (In reply to Claudio Wunder from comment #38)

Yes, if you use grub then add it to grub config. Like any other kernel parameter.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #40 from Claudio Wunder ([email protected]) --- Just to double check (unfortunately I'm not much familiar with GRUB), GRUB_CMDLINE_LINUX="quiet splash xhci_hcd.quirks=0x4000000"

Would that be enough?

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #41 from Michał Pecio ([email protected]) --- I don't use grub2, but it looks like you found the right place.

You can confirm by checking the /proc/cmdline file or running dmesg | grep xhci.*quirks

If the quirk is applied, this line
xhci_hcd 0000:6b:00.0: hcc params 0x0200ef81 hci version 0x110 quirks 0x0000000200000010

will become:
xhci_hcd 0000:6b:00.0: hcc params 0x0200ef81 hci version 0x110 quirks 0x0000000204000010

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #42 from Mathias Nyman ([email protected]) ---

The two Reset Device commands followed by an Address Device command that Michal pointed out earlier could very well be the reason for the issue.

Reset Device Command: slot 16 flags C
Reset Device Command: slot 19 flags C
Reset Device Command: slot 19 flags C
Address Device Command: ctx 00000000fff42000 slot 19 flags b:C

A Reset Device command will move the slot (device) to the Default address 0 state where only one device should be at a time. In default state the device waits for a address device commands to be given a unique address.

Here we have both slots 16 and 19 in default state at the same time, and both devices will try to respond to the address device command.

Xhci section 4.5.3.4 "Default" has a note stating that:
"Software shall ensure that only one Device Slot is in the Default state at time,otherwise undefined behavior may occur."

The commit 2b66ef84d0d2 "usb: hub: lack of clearing xHC resource" that Michal pointed out earlier looks like possible cause to me as well.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #43 from Alan Stern ([email protected]) --- Indeed, in that commit it looks like the call to hub_hc_release_resources() should be made _after_ the hcd->address0_mutex is acquired, not _before_. I didn't realize that the reset_device callback would put the slot or device into the default state. That's exactly what the mutex is intended to serialize.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #44 from Claudio Wunder ([email protected]) --- Created attachment 308097
--> https://bugzilla.kernel.org/attachment.cgi?id=308097&action=edit
Autopsy 68

Attaching another crash on 68; I haven't moved the webcam yet; Should I move the webcam to another Hub or simply disconnect it to verify the webcam is not related?

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #45 from Michał Pecio ([email protected]) --- If you disconnect it from bus 5, you might as well connect it to bus 7 then. This way the two buses will be simultaneously testing two different configurations and time is saved ;)

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #46 from Claudio Wunder ([email protected]) ---
FYI moving Webcam to a dedicated USB port (directly connected to a USB rear port) at least so far (a few hours) and haven't noticed anything.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #47 from Claudio Wunder ([email protected]) ---
Still nothing. When I put the Webcam back to the Hub, the issue persists. I will keep a couple more hours the Webcam on a dedicated port to see if anything at all changes.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #48 from Alan Stern ([email protected]) --- Did you make the change I recommended in comment #43? That is, in drivers/usb/core/hub.c, in the usb_reset_and_verify_device() routine, move the

        if (udev->reset_resume)
                hub_hc_release_resources(udev);

code _below_ the following

        mutex_lock(hcd->address0_mutex);

line.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #49 from Claudio Wunder ([email protected]) ---
Hmm, I assume I'd need to build Kernel from source or? I'm not sure I can change (easily and without possibly breaking other things) the kernel from the distro I use.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #50 from Claudio Wunder ([email protected]) --- (I'd appreciate some guidance here or if you could point me to docs; For reference, this is the flavor of the Kernel my distro uses is:
https://github.com/bazzite-org/kernel-bazzite)

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #51 from Claudio Wunder ([email protected]) --- (let me check with the maintainers of Bazzite)

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #52 from Claudio Wunder ([email protected]) ---
I wasn't able to get their attention with an issue, so I opened a PR directly on their "patchwork" repository (just to get their attention, I doubt they should merge such patch)

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #53 from Claudio Wunder ([email protected]) --- Bazzite's maintainer gave me a path forward, that will require me to first dualboot (with another distro) so I'm able to build the Kernel.

Meanwhile, I'll try the Kernel args that Michal provided first, to verify if they also work.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #54 from Michał Pecio ([email protected]) --- avg_trb_len doesn't seem to be an issue for my ASMedia/Promontory HCs, they still have their usual bugs after changing it to 8 as per spec.

By the way, the simplest way to break ASMedia chips is running
while true ; do ifconfig ethN up ; ifconfig ethN down ; done
on a SuperSpeed NIC (AX88179 and RTL8153 known to work). This is what the limit endpoint interval quirk appears to be helping with, though recently I found some case (NIC behind a SuperSpeed hub) where it didn't help.

I am also not convinced that the "clearing xHC resources" patch is relevant, because it's hard to explain why nothing bad happens when you run reset manually. I found no problems resetting devices on my AMD B350, ASM3142 and ASM1142, despite the dubious command sequence always being there. Your logs show malfunction before we even get to this point. Indeed, the reason the hub is being reset is because attempting to resume it normally suddenly failed.

So the outcome of testing is that the problem occurs if both the unlucky hub and the unlucky webcam are present on the same X670 bus, and disappears if they are on different X670 buses at the same time?

And it's happening on 6.13.9 or newer, but not on 6.13.7? I have no explanation for that...

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #55 from Claudio Wunder ([email protected]) ---

Well I can't say for 100% sure it wasn't on 6.13.7, but only that on the periods of time I've tested it didn't happen.

Also on the limited amount of time, that's right, it didn't happen at all during such circumstances (webcam on a separate bus); I didn't test webcam on same bus, but connected directly on the bus (without the monitor hub); my feeling is that the monitor hub is somehow the issue; I could focus on testing that aspect.

I also tested with the bootargs, this is the result:

```
bash-5.2# dmesg | grep xhci.*quirks
[    0.537829] xhci_hcd 0000:03:00.2: hcc params 0x0110ffc5 hci version 0x120
quirks 0x0000000200000010
[    0.539340] xhci_hcd 0000:3b:00.0: hcc params 0x20007fc1 hci version 0x110
quirks 0x0000000200009810
[    0.595976] xhci_hcd 0000:68:00.0: hcc params 0x0200ef81 hci version 0x110
quirks 0x0000000200000010
[    0.653978] xhci_hcd 0000:6a:00.0: hcc params 0x0200ef81 hci version 0x110
quirks 0x0000000200000010
[    0.656224] xhci_hcd 0000:6c:00.3: hcc params 0x0120ffc5 hci version 0x120
quirks 0x0000000200000010
[    0.657094] xhci_hcd 0000:6c:00.4: hcc params 0x0120ffc5 hci version 0x120
quirks 0x0000000200000010
[    0.658896] xhci_hcd 0000:6d:00.0: hcc params 0x0110ffc5 hci version 0x120
quirks 0x0000000200000010
```

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #56 from Claudio Wunder ([email protected]) ---
I forgot to mention that with bootargs I was still able to reproduce the crash, btw.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #57 from Michał Pecio ([email protected]) --- That didn't work. If you edited grub config /etc, you would apparently need to do some extra work to transfer the settings to /boot. See below. (That's why I don't like and don't use grub2).

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/configuring-kernel-command-line-parameters_managing-monitoring-and-updating-the-kernel

I would recommend option 4.5 instead, if possible. Select the menu entry and press 'e' to edit it for one boot.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #58 from Claudio Wunder ([email protected]) --- Afaik the changes are on /boot (contents of /boot/grub2/grub.cfg)

````
# This section was generated by a script. Do not modify the generated file -
all changes
# will be lost the next time file is regenerated. Instead edit the
BootLoaderSpec files.
#
# The blscfg command parses the BootLoaderSpec files stored in
/boot/loader/entries and
# populates the boot menu. Please refer to the Boot Loader Specification
documentation
# for the files format: https://systemd.io/BOOT_LOADER_SPECIFICATION/.

# The kernelopts variable should be defined in the grubenv file. But to ensure
that menu
# entries populated from BootLoaderSpec files that use this variable work
correctly even
# without a grubenv file, define a fallback kernelopts variable if this has not
been set.
#
# The kernelopts variable in the grubenv file can be modified using the grubby
tool or by
# executing the grub2-mkconfig tool. For the latter, the values of the
GRUB_CMDLINE_LINUX
# and GRUB_CMDLINE_LINUX_DEFAULT options from /etc/default/grub file are used
to set both
# the kernelopts variable in the grubenv file and the fallback kernelopts
variable.
if [ -z "${kernelopts}" ]; then
  set kernelopts="root=UUID=4349ca0b-5bb9-4ad2-83a9-78d7440c02f9 ro quiet
splash xhci_hcd.quirks=0x4000000 "
fi
```

But let me try 4.5 approach.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #59 from Claudio Wunder ([email protected]) --- Got it:

````
bash-5.2# dmesg | grep xhci.*quirks
[    0.000000] Command line:
BOOT_IMAGE=(hd0,gpt2)/ostree/default-5c836f8b9cf21db25d8ea8042cfcac18de42950e638fd2ab6f1bf522afe3bf57/vmlinuz-6.14.6-102.bazzite.fc42.x86_64
rhgb quiet root=UUID=4349ca0b-5bb9-4ad2-83a9-78d7440c02f9 rootflags=subvol=root
rw
ostree=/ostree/boot.0/default/5c836f8b9cf21db25d8ea8042cfcac18de42950e638fd2ab6f1bf522afe3bf57/0
bluetooth.disable_ertm=1 preempt=full xhci_hcd.quirks=0x4000000
[    0.064435] Kernel command line:
BOOT_IMAGE=(hd0,gpt2)/ostree/default-5c836f8b9cf21db25d8ea8042cfcac18de42950e638fd2ab6f1bf522afe3bf57/vmlinuz-6.14.6-102.bazzite.fc42.x86_64
rhgb quiet root=UUID=4349ca0b-5bb9-4ad2-83a9-78d7440c02f9 rootflags=subvol=root
rw
ostree=/ostree/boot.0/default/5c836f8b9cf21db25d8ea8042cfcac18de42950e638fd2ab6f1bf522afe3bf57/0
bluetooth.disable_ertm=1 preempt=full xhci_hcd.quirks=0x4000000
[    0.613780] xhci_hcd 0000:03:00.2: hcc params 0x0110ffc5 hci version 0x120
quirks 0x0000000204000010
[    0.615279] xhci_hcd 0000:3b:00.0: hcc params 0x20007fc1 hci version 0x110
quirks 0x0000000204009810
[    0.671965] xhci_hcd 0000:68:00.0: hcc params 0x0200ef81 hci version 0x110
quirks 0x0000000204000010
[    0.730414] xhci_hcd 0000:6a:00.0: hcc params 0x0200ef81 hci version 0x110
quirks 0x0000000204000010
[    0.733142] xhci_hcd 0000:6c:00.3: hcc params 0x0120ffc5 hci version 0x120
quirks 0x0000000204000010
[    0.734136] xhci_hcd 0000:6c:00.4: hcc params 0x0120ffc5 hci version 0x120
quirks 0x0000000204000010
[    0.736031] xhci_hcd 0000:6d:00.0: hcc params 0x0110ffc5 hci version 0x120
quirks 0x0000000204000010
````

Gonna wait for crashes to happen.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #60 from Claudio Wunder ([email protected]) ---
(I also found that I should use rpm-ostree kargs --editor for editing kernel args.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #61 from Claudio Wunder ([email protected]) --- The issue is still reproducible, unfortunately, even with the quirks. Is another dump log required?

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #62 from Claudio Wunder ([email protected]) --- (I'm also still pending on making the kernel changes to verify they work)

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

Stanislav Zaikin ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #63 from Stanislav Zaikin ([email protected]) --- I'm experiencing exactly the same issue - also X670E chipset (Gigabyte Aorus Master).

Any news on this issue, maybe potential workarounds, Claudio Wunder?

```
13769.621760] xhci_hcd 0000:0f:00.0: xHCI host controller not responding,
assume dead
[13769.621769] xhci_hcd 0000:0f:00.0: HC died; cleaning up
[13769.621801] usb 3-9: USB disconnect, device number 2
[13769.703541] amd_iommu_report_page_fault: 593 callbacks suppressed
[13769.703545] xhci_hcd 0000:0f:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT
domain=0x0015 address=0xfae4d544 flags=0x0000]
[13821.304263] igc 0000:0c:00.0 enp12s0: PCIe link lost, device now detached
[13863.687619] xhci_hcd 0000:0f:00.0: remove, state 4
[13863.687624] usb usb4: USB disconnect, device number 1
[13863.687824] xhci_hcd 0000:0f:00.0: USB bus 4 deregistered
[13863.687831] xhci_hcd 0000:0f:00.0: remove, state 1
[13863.687833] usb usb3: USB disconnect, device number 1
[13864.064774] xhci_hcd 0000:0f:00.0: USB bus 3 deregistered
[13864.321485] xhci_hcd 0000:0f:00.0: xHCI Host Controller
[13864.321492] xhci_hcd 0000:0f:00.0: new USB bus registered, assigned bus
number 3
[13864.494438] xhci_hcd 0000:0f:00.0: hcc params 0x0200ef81 hci version 0x110
quirks 0x0000000200000010
[13864.650361] xhci_hcd 0000:0f:00.0: xHCI Host Controller
[13864.650364] xhci_hcd 0000:0f:00.0: new USB bus registered, assigned bus
number 4
[13864.650366] xhci_hcd 0000:0f:00.0: Host supports USB 3.2 Enhanced SuperSpeed
[13864.650421] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002,
bcdDevice= 6.16
[13864.650423] usb usb3: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[13864.650424] usb usb3: Product: xHCI Host Controller
[13864.650425] usb usb3: Manufacturer: Linux 6.16.6-arch1-1 xhci-hcd
[13864.650426] usb usb3: SerialNumber: 0000:0f:00.0
[13864.650513] hub 3-0:1.0: USB hub found
[13864.650529] hub 3-0:1.0: 12 ports detected
[13864.650766] usb usb4: We don't know the algorithms for LPM for this host,
disabling LPM.
[13864.650785] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003,
bcdDevice= 6.16
[13864.650786] usb usb4: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[13864.650787] usb usb4: Product: xHCI Host Controller
[13864.650788] usb usb4: Manufacturer: Linux 6.16.6-arch1-1 xhci-hcd
[13864.650789] usb usb4: SerialNumber: 0000:0f:00.0
[13864.650942] hub 4-0:1.0: USB hub found
[13864.701188] hub 4-0:1.0: 5 ports detected
[13865.141830] usb 3-9: new full-speed USB device number 2 using xhci_hcd
[13866.346680] xhci_hcd 0000:0f:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT
domain=0x0015 address=0xfe1bd000 flags=0x0020]
[13866.346693] xhci_hcd 0000:0f:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT
domain=0x0015 address=0xfe1bd020 flags=0x0020]
[13866.346702] xhci_hcd 0000:0f:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT
domain=0x0015 address=0xfe1bd040 flags=0x0020]
[13866.346712] xhci_hcd 0000:0f:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT
domain=0x0015 address=0xfe1bd060 flags=0x0020]
[13866.346721] xhci_hcd 0000:0f:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT
domain=0x0015 address=0xfe1bd080 flags=0x0020]
[13866.346730] xhci_hcd 0000:0f:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT
domain=0x0015 address=0xfe1bd0a0 flags=0x0020]
[13866.346738] xhci_hcd 0000:0f:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT
domain=0x0015 address=0xfe1bd0c0 flags=0x0020]
[13866.346747] xhci_hcd 0000:0f:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT
domain=0x0015 address=0xfe1bd100 flags=0x0020]
[13866.346756] xhci_hcd 0000:0f:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT
domain=0x0015 address=0xfe1bd120 flags=0x0020]
[13866.346765] xhci_hcd 0000:0f:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT
domain=0x0015 address=0xfe1bd140 flags=0x0020]
[13866.485412] AMD-Vi: IOMMU Event log restarting
[13882.024157] watchdog: CPU4: Watchdog detected hard LOCKUP on cpu 4
[13882.024160] Modules linked in: btusb uinput snd_seq_dummy snd_hrtimer rfcomm
snd_seq snd_seq_device tun cmac algif_hash algif_skcipher af_alg bnep
typec_displayport vfat fat amd_atl intel_rapl_msr intel_rapl_common iwlmvm
snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component mac80211
snd_hda_codec_hdmi kvm_amd libarc4 snd_hda_intel snd_intel_dspcfg
snd_intel_sdw_acpi kvm snd_hda_codec iwlwifi btrtl nvidia_drm(OE) btintel
snd_hda_core irqbypass btbcm btmtk polyval_clmulni snd_hwdep nvidia_modeset(OE)
cfg80211 ucsi_ccg ghash_clmulni_intel ucsi_acpi bluetooth snd_pcm sha512_ssse3
typec_ucsi igc sp5100_tco sha1_ssse3 typec snd_timer aesni_intel i2c_piix4 ptp
rapl wmi_bmof gigabyte_wmi joydev mousedev pcspkr k10temp ccp i2c_smbus rfkill
pps_core snd roles soundcore nvidia_uvm(OE) apple_mfi_fastcharge i2c_nvidia_gpu
thunderbolt gpio_amdpt gpio_generic mac_hid nvidia(OE) i2c_dev crypto_user loop
dm_mod nfnetlink ip_tables x_tables hid_logitech_hidpp hid_apple
hid_logitech_dj amdgpu amdxcp i2c_algo_bit
[13882.024200]  drm_ttm_helper ttm drm_exec gpu_sched drm_suballoc_helper nvme
drm_panel_backlight_quirks drm_buddy nvme_core drm_display_helper nvme_keyring
cec nvme_auth video wmi [last unloaded: btusb]
[13882.024208] CPU: 4 UID: 0 PID: 49632 Comm: kworker/4:0 Tainted: G        W 
OEL      6.16.6-arch1-1 #1 PREEMPT(full) 
4a67af4a252a87f07f21d480c3d8b2609e933916
[13882.024212] Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE,
[L]=SOFTLOCKUP
[13882.024212] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS
MASTER/X670E AORUS MASTER, BIOS F37 07/31/2025
[13882.024214] Workqueue: events xhci_handle_command_timeout
[13882.024218] RIP: 0010:delay_halt_mwaitx+0x1f/0x40
[13882.024221] Code: 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00
00 53 65 48 8b 05 46 ff fb 01 31 d2 89 d1 48 05 00 a0 4e 9c 0f 01 fa <b8> ff ff
ff ff b9 02 00 00 00 48 39 f0 0f 42 f0 b8 f0 00 00 00 89
[13882.024222] RSP: 0018:ffffd2c4a335fbb8 EFLAGS: 00000087
[13882.024224] RAX: ffff8a6bbe105000 RBX: 0000000000001194 RCX:
0000000000000000
[13882.024224] RDX: 0000000000000000 RSI: 0000000000001194 RDI:
000039119a3d8918
[13882.024225] RBP: 000039119a3d8918 R08: 8080808080808080 R09:
0000000000000001
[13882.024226] R10: ffff8a5cc0050cc0 R11: fefefefefefefeff R12:
00000000004c4b40
[13882.024226] R13: ffffd2c4a6e10038 R14: 0000000000000000 R15:
ffff8a5d55ee2201
[13882.024227] FS:  0000000000000000(0000) GS:ffff8a6c21c1b000(0000)
knlGS:0000000000000000
[13882.024228] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[13882.024228] CR2: 00007f0c017b9000 CR3: 000000013eb0b000 CR4:
0000000000f50ef0
[13882.024229] PKRU: 55555554
[13882.024230] Call Trace:
[13882.024231]  <TASK>
[13882.024232]  delay_halt+0x3c/0x70
[13882.024235]  xhci_handshake+0x67/0xc0
[13882.024238]  xhci_handle_command_timeout+0x3d7/0x520
[13882.024245]  process_one_work+0x190/0x350
[13882.024249]  worker_thread+0x2d7/0x410
[13882.024251]  ? __pfx_worker_thread+0x10/0x10
[13882.024253]  kthread+0xf9/0x240
[13882.024254]  ? __pfx_kthread+0x10/0x10
[13882.024256]  ? __pfx_kthread+0x10/0x10
[13882.024257]  ret_from_fork+0x197/0x1d0
[13882.024259]  ? __pfx_kthread+0x10/0x10
[13882.024260]  ret_from_fork_asm+0x1a/0x30
[13882.024264]  </TASK>
[13889.257466] xhci_hcd 0000:0f:00.0: Abort failed to stop command ring: -110
[13889.257533] xhci_hcd 0000:0f:00.0: xHCI host controller not responding,
assume dead
[13889.257539] xhci_hcd 0000:0f:00.0: HC died; cleaning up
```

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=220069

--- Comment #64 from Michał Pecio ([email protected]) --- There was a workaround: don't connect a particular pair of devices to the same xHCI controller at the same time.

But your logs are different (see comment 6), so it doesn't look like the same thing. And it seems you only had one device there (besides root hubs).

Could you open a new bug, and be sure to specify what kernel you are running, if any versions were free of this problem in the past, how often it happens, what seems to cause it, what device(s) are connected, etc?d

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.