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

[Michal Pecio <michal.pecio@gmail.com>]

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