Re: xhci_hcd / ASMedia ASM4242: Bulk-OUT -EPROTO with Logitec 0789:0308 during DVD+RW recording

Hi Michal,

Thanks for the reply, and sorry about the line wrapping. (I did use an
LLM to help translate my report). I'm not a native English speaker, so
please do tell me if anything I write is unclear.

On the cable suggestion: I should clarify that cable/adapter/connector
orientation substitution was already tested quite extensively before
I sent the report (see the "Controlled-variable test matrix" section,
tests 6-14), the original suspect cable turned out to be fine on
every other controller/port, and a completely different known-good
cable+adapter still fails on this specific ASM4242 port. So at this
point I'm fairly confident it isn't the cable itself, though I can't
rule out something specific to the SuperSpeed lanes on this particular
ASM4242 port's physical connector.

I ran the dynamic debug you suggested and reproduced the failure while
it was active. Result:

There were two separate clusters, and they look qualitatively
different:

Cluster 1, right at the very start of the cdrecord invocation
(before any error is visible to userspace), ~45 seconds before the
actual failure:

  Stalled endpoint for slot 1 ep 2
  Hard-reset ep 2, slot 1

repeated 4 times back to back, all within about 1 second. I suspect
this is benign startup housekeeping (drive power calibration / initial
TEST UNIT READY polling by cdrecord) rather than part of the actual
failure mechanism, since a STALL condition is a normal completion code
that requires a Reset Endpoint per spec anyway. Let me know if you
think this is worth digging into further.

Cluster 2, at the exact moment cdrecord reported the write error
(matches the timestamp of "write track data: error after 103088128
bytes" in cdrecord's own log):

  Transfer error for slot 1 ep 3 on endpoint
  Soft-reset ep 3, slot 1
  Transfer error for slot 1 ep 3 on endpoint
  Soft-reset ep 3, slot 1
  Transfer error for slot 1 ep 3 on endpoint
  Soft-reset ep 3, slot 1
  Transfer error for slot 1 ep 3 on endpoint
  Soft-reset ep 3, slot 1
  Transfer error for slot 1 ep 3 on endpoint
  Hard-reset ep 3, slot 1
  usb 6-1: reset SuperSpeed USB device number 2 using xhci_hcd
  xhci_hcd 0000:77:00.0: Stopped on No-op or Link TRB for slot 1 ep 2

So to answer your question directly: it is not constant background
noise throughout the write. It's a single, tight burst of 5 "Transfer
error" events on the same endpoint within about one second. The first
4 were recovered with a soft-reset and the write continued; the 5th
one failed to recover with a soft-reset and escalated to a hard-reset,
which is what triggers the port-level reset that ultimately kills the
transfer (matches the -EPROTO / resid=23552 I described in the
original usbmon capture, that URB is the one hitting this 5th
error).

If it's useful I can capture the full raw dynamic debug log (this was
just the relevant grep) and/or a fresh usbmon capture with this
tracing enabled at the same time, so you can correlate the URB-level
and TRB-level views of the exact same failure. Just let me know what
would help.

Thanks,
wakasio