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

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

[wakasio]

Summary
=======

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).

I patched a local kernel to add ASM4242's PCI ID to the existing XHCI_ASMEDIA_MODIFY_FLOWCONTROL quirk (currently only applied to PCI_DEVICE_ID_ASMEDIA_1042A_XHCI) as a plausible hypothesis, confirmed via dmesg that the quirk was actually applied, and re-ran the exact same test: no improvement -- identical failure signature. That specific hypothesis is therefore ruled out; I'm reporting the raw data in case it's useful to someone who knows this controller/quirk code better than I do.


System information
===================

- Motherboard: MSI MPG X870E EDGE TI WIFI (MS-7E59), BIOS version 1.A82 (2026-03-17). Latest vendor BIOS available at time of writing is 7E59v1A90 (2026-05-25) -- not yet tested, see "Current understanding / open question" below.
- CPU: AMD Ryzen 7 9800X3D
- Kernel: gentoo-sources-7.2.2 (essentially vanilla kernel.org 7.2.2 with Gentoo's minimal patch set), custom-built, CONFIG_USB_XHCI_PCI=y (built-in, not a module)
- uname -r: 7.2.2-gentoo-rikka
- IOMMU: AMD-Vi enabled, iommu= default (Translated domain type, lazy DMA TLB invalidation), not explicitly tuned

Kernel tested: gentoo-sources 7.2.2 (all data above, including the usbmon capture). Reproduced with the same userspace-visible failure signature on vanilla Linux 7.2.3 (sys-kernel/vanilla-sources-7.2.3, i.e. plain upstream kernel.org source, no Gentoo or other distro patches, CONFIG_LOCALVERSION set to a distinct value only for identification): same device (BU40N), same bus 6/ASM4242 port, same cdrecord invocation, same cdrecord/SG-level failure signature (resid=23552, SCSI status 0x0), this time at ~52 MB into the write. usbmon was not re-captured for this run, so I can't yet confirm the underlying URB-level mechanism (-EPROTO at the same point) is identical on 7.2.3, only that the symptom cdrecord sees is. The 7.2.2->7.2.3 changelog contains no commits touching xhci, xhci-pci, any USB host controller code, ASMedia, or usb-storage quirks, so this result is expected, but is included as direct confirmation rather than an inference from the changelog alone.


Hardware topology
==================

  $ lspci -nnk -s 77:00.0
  77:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM4242 USB 3.2 xHCI Controller [1b21:2426] (rev 01)
          Subsystem: ASMedia Technology Inc. ASM4242 USB 3.2 xHCI Controller
          Kernel driver in use: xhci_hcd
          Kernel modules: xhci_pci

  $ lspci -nnk -s 78:00.0
  78:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM4242 USB 4 / Thunderbolt 3 Host Router [1b21:2425] (rev 01)
          Kernel driver in use: thunderbolt
          Kernel modules: thunderbolt

77:00.0 is the xHCI function handling USB 3.x traffic on the two USB4-capable rear ports; 78:00.0 is the same physical chip's Thunderbolt/USB4 router function. Two rear-panel USB-C ports (the board's "USB-C 40G" ports, confirmed by the board vendor's own port labeling) are wired to this controller as usb6-1 and usb6-2 in Linux's enumeration. This is a third-party (non-Intel) discrete USB4/TB3 host controller, not part of the CPU or chipset silicon.

Boot-time xhci_hcd log for this controller:

  xhci_hcd 0000:77:00.0: xHCI Host Controller
  xhci_hcd 0000:77:00.0: new USB bus registered, assigned bus number 6
  xhci_hcd 0000:77:00.0: hcc params 0x0200ef81 hci version 0x120 quirks 0x0000000200000010
  xhci_hcd 0000:77:00.0: Host supports USB 3.2 Enhanced SuperSpeed
  usb usb6: We don't know the algorithms for LPM for this host, disabling LPM.

Decoded quirks 0x0000000200000010 (bit numbers per current drivers/usb/host/xhci.h):

  - bit 4  XHCI_SPURIOUS_SUCCESS -- set generically for any controller with hci_version > 0x96 (xhci.c, not ASMedia-specific)
  - bit 33 XHCI_DEFAULT_PM_RUNTIME_ALLOW -- set generically for any controller with hci_version >= 0x120 (xhci-pci.c, not ASMedia-specific)

drivers/usb/host/xhci-pci.c's ASMedia-specific quirk table has no entry at all for PCI device ID 0x2426 (ASM4242). Every other ASMedia xHCI device ID the driver knows about -- 0x1042, 0x1142, 0x1242, 0x2142, 0x3042, 0x3242 -- has at least one dedicated quirk (XHCI_NO_64BIT_SUPPORT, XHCI_ASMEDIA_MODIFY_FLOWCONTROL, XHCI_BROKEN_STREAMS, XHCI_RESET_ON_RESUME, in various combinations). ASM4242, being newer, is currently treated as a fully generic/untuned xHCI 1.0+ controller.


Devices involved
=================

Failing device: physically an HL-DT-ST BD-RE BP71N (a slimline BD-RE drive, MT1959-based controller) that has been cross-flashed to "OmniDrive v1.0.4" third-party firmware built on a BU40N donor image -- a well-known community re-flash for this MT1959-family hardware (BP71N and the retail BU40N are the same underlying board/chipset; OmniDrive unlocks raw disc-image dumping and other features). Post-flash, the drive identifies itself over SCSI INQUIRY as "HL-DT-ST BD-RE BU40N 1.00", which is why it's referred to as "BU40N" throughout this report -- anyone trying to reproduce this should be aware the reporting drive is not a stock retail BU40N, it's a re-flashed BP71N, though the two are believed to be hardware-identical. The failing commands are standard MMC WRITE(10), but because the firmware is non-stock, a firmware-specific interaction cannot currently be ruled out.

Connected via a USB enclosure/bridge, specifically a Logitec LBD-PWB6U3ZCSWH external Type-C BD/DVD drive enclosure (Logitec is a Japanese peripheral vendor, unrelated to Logitech):

  Product: LBD USB Device
  Manufacturer: Logitec
  idVendor=0789, idProduct=0308
  bInterfaceClass=8 (Mass Storage), bInterfaceSubClass=6 (SCSI), bInterfaceProtocol=80 (Bulk-Only Transport)
  Endpoints: 1x Bulk IN (0x81), 1x Bulk OUT (0x02), wMaxPacketSize=0x0400, bMaxBurst=15 (both directions)
  BOS SuperSpeed capability: wSpeedsSupported=0x000e (Full/High/SuperSpeed -- Low Speed only bit not set)
  Self-powered, MaxPower declared 8mA

Working comparison device: HL-DT-ST DVDRAM GUD1N (an internal drive normally used over SATA, tested here externally via a USB-to-SATA bridge dongle), also DVD+-RW/DVD-RAM capable:

  Manufacturer: Ugreen
  usb-storage quirk match: vid 174c pid 55aa (ASMedia-family SATA bridge chipset), quirks=0x400000


Reproduction
============

Software: cdrtools (Schily) cdrecord 3.02a09 (ProDVD build). Example command used throughout (DVD+RW media, single-track .iso data write, no audio -- this class of bug is unrelated to CD-DA/audio-track handling):

  cdrecord dev=/dev/sgN speed=8 -v driveropts=burnfree -data "<3.9GB PS2 disc image>.iso"

cdrecord itself reports the write mode explicitly, so "SAO" below is taken directly from its output rather than assumed:

  Starting to write CD/DVD/BD at speed 8 in real SAO mode for single session.

Every failure has the same signature reported by cdrecord/the SG driver:

  cdrecord: I/O error. write_g1: scsi sendcmd: retryable error
  CDB:  2A 00 00 00 <LBA:4B> 00 00 10 00      (WRITE(10), 16 blocks = 32768 bytes)
  status: 0x0 (GOOD STATUS)
  resid: 23552

32768 - 23552 = 9216 -- i.e. only 9216 of the requested 32768 bytes were actually transferred. cdrecord reports a SCSI status byte of 0x0 together with a non-zero residual count and a transport error; this does not represent successful completion of the command. Failures have occurred at wildly different points in the write: as little as ~350 KB in, as much as ~64 MB in, over six independent attempts -- there is no fixed offset, no fixed LBA, strongly arguing against a fixed media defect or fixed-LBA/content trigger.


Controlled-variable test matrix
================================

All burns below wrote either DVD+RW media, a blank CD-R, or DVD-RAM media, with known-good disc images (PS1/PS2 titles) whose SHA-1 was independently verified against redump.org reference hashes both before and, on success, after burning. "Bus" numbers are this system's Linux USB bus enumeration.

 1. BU40N, DVD+RW (cdrecord, SAO), original bundled Type-C cable, bus 6 port 1 (ASM4242), SuperSpeed -> FAIL (~26 MB)

 2. BU40N, DVD+RW speed=6 instead of 8, same cable, bus 6 port 1 (ASM4242), SuperSpeed -> FAIL, faster (~0.35 MB)

 3. BU40N, DVD+RW (usbmon capture, see below), same cable, bus 6 port 1 (ASM4242), SuperSpeed -> FAIL (~64 MB)

 4. BU40N, CD-R (cdrdao, SAO, mixed-mode data+audio), same cable, bus 6 port 1 (ASM4242), SuperSpeed -> OK, byte-perfect (both a --simulate dry run and a real burn)

 5. BU40N, DVD-RAM (cdrecord, random-access write, forced to 2x by media/drive), same cable, bus 6 port 1 (ASM4242), SuperSpeed -> OK, byte-perfect, 1.39 GB, 17.5 min

 6. BU40N, DVD+RW, 3rd-party Type-C->USB-A cable via a USB 2.0 High-Speed-only hub, rear USB-A (via hub, not ASM4242), High-Speed -> OK, byte-perfect

 7. BU40N, DVD+RW, same 3rd-party cable direct, rear USB-A (not ASM4242), SuperSpeed -> OK, byte-perfect

 8. BU40N, DVD+RW, same cable + USB-A->Type-C adapter, bus 6 port 1 (ASM4242), SuperSpeed -> FAIL (~21 MB)

 9. BU40N, DVD+RW, same cable+adapter, front-panel Type-C (not ASM4242), SuperSpeed -> OK, byte-perfect

10. BU40N, DVD+RW, same cable+adapter, bus 6 port 1 (ASM4242) again, SuperSpeed -> FAIL, reproduced (~20 MB)

11. BU40N, DVD+RW with connector flipped 180 degrees, same cable+adapter, bus 6 port 1 (ASM4242), SuperSpeed -> FAIL (~9 MB) -- rules out a single-pin/orientation-specific contact fault

12. BU40N, DVD+RW, same cable+adapter, bus 6 port 2 (ASM4242, 2nd port), SuperSpeed -> FAIL (~21 MB) -- rules out "just this one physical port"

13. BU40N, DVD+RW, same cable+adapter, separate USB-C 10G controller (not ASM4242), SuperSpeed -> OK, byte-perfect

14. BU40N, DVD+RW, original bundled cable (the one from test #1), separate USB-C 10G controller (not ASM4242), SuperSpeed -> OK, byte-perfect -- the originally-suspected cable was never actually at fault

15. GUD1N, DVD+RW (same physical disc as tests #1-3 and #6-14), Ugreen USB-SATA bridge, separate USB-C 10G controller, SuperSpeed -> OK, byte-perfect

16. GUD1N, DVD+RW (same physical disc), same bridge, bus 6 port 1 (ASM4242) -- the exact port that fails for BU40N, SuperSpeed -> OK, byte-perfect -- same media/workload, same problem port, different drive+bridge stack

Tests 4 and 5 are the important negative controls: the same device, the same cable, and the same problem controller/port, but a different media type and write mode, both completed without error. This is evidence that neither the device nor the controller is unconditionally broken for writes -- whatever is going wrong is specific to some property of the higher-rate, real-time DVD+RW recording (SAO) workload that CD-R recording (also SAO, but a lower data rate) and DVD-RAM (random-access, no real-time constraint) don't share.

Test 16 holds media and host port fixed while swapping the drive: the same physical DVD+RW disc (confirmed via matching sector count in -media-info) used in the DVD+RW tests above, on the same bus 6/ASM4242 port, with the failing drive+bridge -- BU40N behind the Logitec 0789:0308 bridge -- replaced by a different drive behind a different bridge -- GUD1N behind an Ugreen/ASMedia-174c:55aa bridge -- and it succeeds. This is *not* a single-variable substitution: both the optical drive and its USB bridge chipset changed together, so this result alone cannot separate "something about the BU40N drive itself" from "something about the Logitec 0789:0308 bridge" as the necessary ingredient on the device side. What it does establish, combined with test 5 (BU40N itself succeeding at a different, non-SAO write mode on the same port/controller), is that "this port/controller" alone is not sufficient to cause the fault -- some property of the {BU40N, Logitec bridge} pair, together with the DVD+RW SAO write mode, is also required. Exactly what that property is -- and whether it belongs to the drive or the bridge -- is still open; none of these have been isolated yet.

Read-only workloads (large sequential Bulk-IN, i.e. disc dumping/ripping with this same drive through this same controller) have been run successfully many times over several days prior to this investigation -- the fault has only ever been observed on writes.


usbmon capture: exact failure mechanism
========================================

usbmon (/sys/kernel/debug/usb/usbmon/6u) was captured across a live failure (test #3 above). Reconstructing the Bulk-Only-Transport command/data/status sequence (Bo = bulk-out on this device's endpoint 2, Bi = bulk-in on endpoint 1):

Two immediately preceding, fully successful WRITE(10) commands (16 blocks / 32768 bytes each), shown for contrast -- CBW sent, full 32768-byte data stage transferred, CSW with residue=0 and status=0 returned:

  S Bo:6:004:2 -115 31 = 55534243 db0b0000 00800000 00000a2a 00000080 50000010 00000000 000000
      <- CBW, tag db0b0000, LBA=0x8050, 16 blocks
  C Bo:6:004:2 0 31 >
  S Bo:6:004:2 -115 32768 = 00000000 00000000 ...
      <- data-out stage begins
  C Bo:6:004:2 0 32768 >
      <- completes in full
  S Bi:6:004:1 -115 13 <
  C Bi:6:004:1 0 13 = 55534253 db0b0000 00000000 00
      <- CSW: "USBS", tag matches, residue=0, status=0 (success)

  S Bo:6:004:2 -115 31 = 55534243 dc0b0000 00800000 00000a2a 00000080 60000010 00000000 000000
      <- next CBW, LBA=0x8060
  C Bo:6:004:2 0 31 >
  S Bo:6:004:2 -115 32768 = 00000020 60606060 00801474 be60c23e ...
  C Bo:6:004:2 0 32768 >
  S Bi:6:004:1 -115 13 <
  C Bi:6:004:1 0 13 = 55534253 dc0b0000 00000000 00
      <- again residue=0

The failing command immediately after:

  S Bo:6:004:2 -115 31 = 55534243 dd0b0000 00800000 00000a2a 00000080 70000010 00000000 000000
      <- CBW, tag dd0b0000, LBA=0x8070 (matches cdrecord's failing CDB exactly)
  C Bo:6:004:2 0 31 >
      <- CBW itself transmits fine
  S Bo:6:004:2 -115 32768 = 28cc113f 98f95a3f 9acc113f 00000000 10000000 0b001400 01000000 00000000
      <- data-out stage begins
  C Bo:6:004:2 -71 9216 >
      <- completes with -EPROTO after only 9216 of 32768 bytes

32768 - 9216 = 23552, exactly matching the resid cdrecord/SG reported. The Bulk-OUT data-stage URB itself is torn down mid-transfer with -EPROTO; there is no CSW for this command at all -- this is a real transport-layer failure on the OUT direction, not a device politely reporting a short/partial write via a normal CSW.

Immediately following the -71, the driver performs port-level recovery (hub port status/feature requests on the root hub, device 1) -- this is what produces the "usb 6-1: reset SuperSpeed USB device" line seen in dmesg. The reset is initiated by usb-storage's own error-recovery path reacting to the -EPROTO, not something visibly flagged by xhci_hcd itself before that point -- no xhci_hcd-level error/warning is printed anywhere near the failure (I checked journalctl -k with sub-second precision across the exact failure window both times).

The same capture also contains four earlier Bulk-IN URB completions with -32 (-EPIPE, endpoint STALL), all of which were recovered transparently by usb-storage without the error surfacing to cdrecord. Their relationship, if any, to the later fatal Bulk-OUT -EPROTO is currently unknown.


Hypothesis tested and falsified: XHCI_ASMEDIA_MODIFY_FLOWCONTROL
==================================================================

Given ASM4242 has zero ASMedia-specific quirks applied, and the name of the existing XHCI_ASMEDIA_MODIFY_FLOWCONTROL quirk (currently gated to PCI_DEVICE_ID_ASMEDIA_1042A_XHCI only, calling usb_asmedia_modifyflowcontrol() which writes ASMedia's own ASMT_FLOWCTL_ADDR vendor register via PCI config space at controller reset/resume time -- see drivers/usb/host/pci-quirks.c) sounded like a plausible match for a "loses data under sustained OUT throughput" symptom, I patched a local kernel to test it:

  --- a/drivers/usb/host/xhci-pci.c
  +++ b/drivers/usb/host/xhci-pci.c
  @@
   #define PCI_DEVICE_ID_ASMEDIA_3042_XHCI			0x3042
   #define PCI_DEVICE_ID_ASMEDIA_3242_XHCI			0x3242
  +#define PCI_DEVICE_ID_ASMEDIA_4242_XHCI			0x2426
  @@
   	if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA &&
  -		pdev->device == PCI_DEVICE_ID_ASMEDIA_1042A_XHCI)
  +		(pdev->device == PCI_DEVICE_ID_ASMEDIA_1042A_XHCI ||
  +		 pdev->device == PCI_DEVICE_ID_ASMEDIA_4242_XHCI))
   		xhci->quirks |= XHCI_ASMEDIA_MODIFY_FLOWCONTROL;

Built and booted a separate kernel (distinct CONFIG_LOCALVERSION, so the known-good kernel remained untouched/bootable in parallel via GRUB). Confirmed via dmesg the quirk actually took effect before testing:

  xhci_hcd 0000:77:00.0: hcc params 0x0200ef81 hci version 0x120 quirks 0x0000000210000010

(quirks value gained bit 28, 0x10000000, exactly XHCI_ASMEDIA_MODIFY_FLOWCONTROL -- this bit has no other setter anywhere in the tree, so this is unambiguous confirmation the patched code path ran).

Re-ran the identical test (test #3/#8's exact configuration: BU40N, bus 6 port 1, same cdrecord invocation). Result: identical failure, resid=23552, this time at ~33 MB. No improvement whatsoever.

Conclusion: XHCI_ASMEDIA_MODIFY_FLOWCONTROL does not address this issue. Whatever causes this ASM4242/device interoperability failure, it is not the same class of problem that quirk fixes for the ASM1042A.


Current understanding / open question
======================================

Symptom boundary established via controlled substitution across device, cable, adapter, connector orientation, port, and host controller (see matrix above), refined further by the media/write-mode negative controls (tests 4-5):

The failure has so far only been observed with this device/controller combination during sustained higher-rate DVD+RW recording workloads (SAO real-time mode). Bulk-OUT direction is necessary for the observed failure, but is not by itself sufficient: CD-R (also SAO, lower data rate) and DVD-RAM (random-access, no real-time constraint) writes on the exact same device/cable/controller/port completed successfully every time. Cable, adapter, and USB-C connector orientation have all been positively ruled out through direct substitution. The ASM4242 controller path has been shown to be a necessary condition (BU40N behind the same drive+bridge succeeds on every other controller tested). The "device" side has only been substituted as a unit -- BU40N plus its Logitec 0789:0308 bridge, swapped for GUD1N plus an unrelated Ugreen/ASMedia-174c:55aa bridge -- so while something about that pairing is necessary (removing it, while holding the controller/port fixed, eliminates the fault), whether that something belongs to the BU40N drive itself or to the Logitec bridge chipset has not been isolated. Neither the controller nor the {BU40N, Logitec bridge} pairing is unconditionally broken for all writes (see the CD-R/DVD-RAM negative controls above).

I don't have the expertise to go further than this without more knowledge of either the ASM4242 xHCI silicon/firmware internals, or of what's different about the transfer cadence/timing of a real-time DVD+RW SAO write versus CD-R SAO or DVD-RAM writes, or of what's unusual about this particular device's Bulk-OUT endpoint behavior that a "more standard" mass-storage bridge (the ASMedia-SATA-bridge-based GUD1N setup, which succeeds on the identical controller) doesn't trigger. Firmware/BIOS updates for the board and for the ASM4242 chip itself exist and are newer than what's currently installed, but I have not yet tested them (would need to move to Windows for the ASM4242-specific firmware updater tool). I'm filing this now because the usbmon data and the controlled-variable matrix seemed worth recording regardless of whether the eventual fix turns out to be firmware-side.

Happy to test further patches, gather more usbmon captures, or provide the full raw usbmon binary capture if useful.


Data available on request
==========================

  - Full usbmon text capture spanning the failure shown above
  - lsusb -v for both the Logitec/BU40N bridge and the Ugreen/GUD1N bridge
  - Full dmesg/journalctl -k boot log for both the unpatched and patched kernel
  - The two-line kernel patch described above (trivial, included in full above)

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

[Michal Pecio]

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

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

[wakasio]

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

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

[Michal Pecio]

On Sat,  5 Sep 2026 12:10:11 +0900, wakasio wrote:
> 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

Seems unrelated.

> 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.

Short fraction of a second, I suppose. Timestamps would help.

4 is the number of retries without ep->err_count reset, so it seems
they all happened in the same URB, possibly in the same place.

Let's add more debug logging and see if it's some transient stupid
problem that we can wait out or plow through with more retries.

One more dynamic debug will be needed with this patch:

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

--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2511,6 +2511,8 @@ static void process_bulk_intr_td(struct xhci_hcd *xhci, struct xhci_virt_ep *ep,
 
 	switch (trb_comp_code) {
 	case COMP_SUCCESS:
+		if (ep->err_count)
+			xhci_dbg(xhci, "clear err_count at %px\n", ep_trb);
 		ep->err_count = 0;
 		/* handle success with untransferred data as short packet */
 		if (ep_trb != td->end_trb || remaining) {
@@ -2522,6 +2524,8 @@ static void process_bulk_intr_td(struct xhci_hcd *xhci, struct xhci_virt_ep *ep,
 		td->status = 0;
 		break;
 	case COMP_SHORT_PACKET:
+		if (ep->err_count)
+			xhci_dbg(xhci, "clear err_count short at %px\n", ep_trb);
 		ep->err_count = 0;
 		td->status = 0;
 		break;
@@ -2534,9 +2538,10 @@ static void process_bulk_intr_td(struct xhci_hcd *xhci, struct xhci_virt_ep *ep,
 		goto finish_td;
 	case COMP_USB_TRANSACTION_ERROR:
 		if (xhci->quirks & XHCI_NO_SOFT_RETRY ||
-		    (ep->err_count++ > MAX_SOFT_RETRY) ||
+		    (ep->err_count++ > 10) ||
 		    le32_to_cpu(slot_ctx->tt_info) & TT_SLOT)
 			break;
+		udelay(5 << ep->err_count);
 
 		td->status = 0;
 
@@ -2706,8 +2711,8 @@ static int handle_tx_event(struct xhci_hcd *xhci,
 		status = -EPROTO;
 		break;
 	case COMP_USB_TRANSACTION_ERROR:
-		xhci_dbg(xhci, "Transfer error for slot %u ep %u on endpoint\n",
-			 slot_id, ep_index);
+		xhci_dbg(xhci, "Transfer error for slot %u ep %u on endpoint at %px resid %u\n",
+			 slot_id, ep_index, ep_trb, EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)));
 		status = -EPROTO;
 		break;
 	case COMP_BABBLE_DETECTED_ERROR:

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

[wakasio]

Hi Michal,

I applied your patch and reproduced the failure with all three debug
functions enabled. Result:

Cluster 1 (ep 2, at the very start of the write, unrelated as you
said): same as before, 4 Stall/Hard-reset pairs, spread over about
323 ms, roughly 22 seconds before the real failure.

Cluster 2 (ep 3, the real failure), with full timestamps this time:

  17:38:44.749474 Transfer error, ep 3, at ffffd52c40703f40, resid 23552
  17:38:44.749743 Soft-reset ep 3
  17:38:44.758367 Transfer error, ep 3, at ffffd52c40703f40, resid 23552
  17:38:44.758454 Soft-reset ep 3
  17:38:44.768370 Transfer error, ep 3, at ffffd52c40703f40, resid 23552
  17:38:44.768577 Soft-reset ep 3
  17:38:44.775052 Transfer error, ep 3, at ffffd52c40703f40, resid 23552
  17:38:44.775217 Soft-reset ep 3
  17:38:44.785047 Transfer error, ep 3, at ffffd52c40703f40, resid 23552
  17:38:44.785313 Soft-reset ep 3
  17:38:44.790469 Transfer error, ep 3, at ffffd52c40703f40, resid 23552
  17:38:44.790732 Soft-reset ep 3
  17:38:44.799187 Transfer error, ep 3, at ffffd52c40703f40, resid 23552
  17:38:44.799346 Soft-reset ep 3
  17:38:44.808558 Transfer error, ep 3, at ffffd52c40703f40, resid 23552
  17:38:44.808720 Soft-reset ep 3
  17:38:44.819176 Transfer error, ep 3, at ffffd52c40703f40, resid 23552
  17:38:44.819317 Soft-reset ep 3
  17:38:44.832378 Transfer error, ep 3, at ffffd52c40703f40, resid 23552
  17:38:44.832552 Soft-reset ep 3
  17:38:44.850677 Transfer error, ep 3, at ffffd52c40703f40, resid 23552
  17:38:44.850815 Soft-reset ep 3
  17:38:44.861706 Transfer error, ep 3, at ffffd52c40703f40, resid 23552
  17:38:44.861938 Hard-reset ep 3
  17:38:44.981704 usb 6-1: reset SuperSpeed USB device number 2
  17:38:44.998378 Stopped on No-op or Link TRB, slot 1 ep 2
  17:38:46.645044 clear err_count at ffffd52c40707000

It survived 11 soft-resets this time instead of 4, then hit the raised
limit and hard-reset on the 12th. The gap between retries grows from
about 9 ms near the start to about 18 ms near the end.

All 12 Transfer error events, the 11 soft-reset ones and the final
hard-reset one, show the exact same TRB address (ffffd52c40703f40)
and the exact same resid (23552).

About 1.8 seconds after the port reset, a different TRB address
(ffffd52c40707000) cleared err_count. cdrecord had already aborted on
the -EPROTO from the first failing URB by that point.

This time the failure also happened much earlier in the write than
last time, at about 12.9 MB instead of 64 MB or 103 MB. Still no
fixed offset.

I still have the full log if you want to see it, and I can also try
capturing usbmon at the same time as this dynamic debug next, if that
would help correlate the two.

Thanks,
wakasio