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

[wakasio <scarabeeta@gmail.com>]

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)