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

Hi,

Please wrap your lines at 72 characters and maybe ask your LLM to write
something that a human can read within reasonable timeframe ;)

On Sat,  5 Sep 2026 00:46:52 +0900, wakasio wrote:

On an AMD X870E system with an onboard ASMedia ASM4242
USB4/Thunderbolt host controller (PCI ID 1b21:2426), a specific USB
Bulk-Only-Transport optical drive (HL-DT-ST BD-RE BU40N, running
"OmniDrive" third-party firmware) reliably fails during sustained
large writes (optical disc burning, i.e. SCSI WRITE(10) with large
multi-block data-out phases) when connected through this controller's
ports. The Bulk-OUT data-stage URB completes with -EPROTO after
transferring only part of the requested data, at an unpredictable
byte offset, well before completion.

The exact same physical cable, adapter, and drive succeed 100% of the
time (byte-perfect, verified via SHA-1 against known-good reference
images) on every other USB controller in the same machine (a separate
10Gbps Type-C host path/controller, the chipset's own rear USB-A
ports, and a front-panel Type-C port). A second, completely different
USB mass-storage device (an internal DVD-RAM drive, HL-DT-ST DVDRAM
GUD1N, attached via an unrelated ASMedia USB-to-SATA bridge dongle)
succeeds 100% of the time on the same problem controller/port that
fails for the BU40N drive.

Read operations (large Bulk-IN transfers, e.g. ripping discs with the
same drive through the same controller) have never failed in several
days of prior use. The failure has so far only been observed with
this device/controller combination during sustained higher-rate
DVD+RW recording workloads. Bulk-OUT is necessary for the observed
failure, but is not by itself sufficient: CD-R and 2x DVD-RAM writes
on the same device/controller combination completed successfully (see
test matrix below).

EPROTO would typically be bad link quality or some protocol violation
by one or another end of the link. I guess you could try other cables;
gigabit serial links are practically voodo magic.

One quick check worth trying would be to see if xHCI "soft retries" are
being used and to what effect. Run:

  echo 'func handle_tx_event +p' >/proc/dynamic_debug/control
  echo 'func xhci_reset_halted_ep +p' >/proc/dynamic_debug/control

and see how much "Transfer error" and "Soft-reset ep" spam you get. Is
it constant background noise or only one burst and then "Hard-reset"?

Regards,
Michal