[Bug 220069] [6.13.9] regression USB controller dies

[bugzilla-daemon@kernel.org]

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

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