[Bug 220069] [6.13.9] regression USB controller dies

[bugzilla-daemon@kernel.org]

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

--- Comment #24 from Michał Pecio (michal.pecio@gmail.com) ---
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.