[Bug 220069] [6.13.9] regression USB controller dies

[bugzilla-daemon@kernel.org]

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

--- Comment #4 from Michał Pecio (michal.pecio@gmail.com) ---
(In reply to Claudio Wunder from comment #2)
> 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

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.

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

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.