CM4/VL805 UAS read stalls: USB3 Streams failure (AI-assisted analysis)

Start with the VL805 quirk handling in xhci-ring.c and xhci-mem.c, focusing on the reported Streams and bulk IN observations. Reproduce the UAS + Streams read failure and compare it with the XHCI_BROKEN_STREAMS and BOT fallback results. Done means establishing whether the VL805-specific handling accounts for the failure and validating a maintainer-approved fix or narrower workaround.

AI-generated / AI-assisted update

Disclosure: This update and the analysis below were drafted with AI assistance, then tested on the affected device. Measurements and kernel logs are from the device. The root-cause hypothesis still needs maintainer confirmation.

Working conclusion

The camera/H.264 workload is an amplifier, not the necessary trigger. The reproducible failure is in the UAS USB3 Streams read (IN) path on this CM4/BCM2711 + VL805 setup. Disabling Streams (or falling back to USB Mass Storage BOT) eliminates the errors and restores full read throughput.

Tested setup

• Raspberry Pi Compute Module 4 Rev 1.0 (BCM2711, 4 GB)
• Kernel: 6.18.39+rpt-rpi-v8
• xHCI: VIA VL805, PCI ID 1106:3483, firmware register 0x00013705
• Storage: JMicron JMS583 USB-to-NVMe bridge, 152d:0583
• Disk is connected directly to the VL805 USB3 root hub.

Reproduction and results

I temporarily removed usb-storage.quirks=152d:0583:u, rebooted, and confirmed that uas had bound to the JMS583. The failure appeared at boot before the camera/spyglass process started:

[   35.829807] sd 0:0:0:0: [sda] tag#27 uas_eh_abort_handler 0 uas-tag 1 inflight: IN
[   35.845801] scsi host0: uas_eh_device_reset_handler start
[   35.991939] ... cmd_age=31s
[   35.991968] I/O error, dev sda, sector 6394112 op 0x0:(READ)

All observed errors were READ / inflight: IN; writes remained fast. 200 MiB direct-I/O results:

Configuration	Read	Write	UAS errors
UAS + Streams	2.5-5 MB/s	250-271 MB/s	abort/reset about every 10 s
UAS + memory-bandwidth load	about 1.1 MB/s	n/a	20 during test
xhci_hcd.quirks=524288 (XHCI_BROKEN_STREAMS)	286 MB/s	231 MB/s	0
usb-storage.quirks=152d:0583:u (BOT fallback)	285 MB/s	n/a	0

The XHCI_BROKEN_STREAMS test made UAS decline to bind, so the device used usb-storage/BOT. That is still a useful discriminating result: disabling Streams completely removes the issue.

Checks performed

• PCIe link stable at 5.0 GT/s x1; correctable/fatal/nonfatal AER counters all zero.
• vcgencmd get_throttled=0x0; no evidence of power throttling.
• SWIOTLB usage stayed zero; the BCM2711 early-3GB PCIe integration erratum does not fit this setup (dma-ranges supplies a 4GB window).
• Disabling U1/U2 LPM with usbcore.quirks=152d:0583:k did not help; reads were worse, so LPM is unlikely to be the root cause.

Why this may be a VL805 Streams quirk gap

The current VL805 quirk set already contains several controller workarounds (XHCI_EP_CTX_BROKEN_DCS, XHCI_TRB_OVERFETCH, XHCI_AVOID_DQ_ON_LINK, and XHCI_VLI_SS_BULK_OUT_BUG), but does not set XHCI_BROKEN_STREAMS. Two code observations appear relevant:

1. xhci-ring.c only applies the XHCI_EP_CTX_BROKEN_DCS workaround when !(ep->ep_state & EP_HAS_STREAMS).
2. xhci-mem.c applies the VL805 SuperSpeed bulk burst clamp only to bulk OUT endpoints. This failure is entirely IN/read-side.

I am not claiming this proves a hardware fault by itself, but it is consistent with a VL805 stream/DCS or IN-burst handling problem under the BCM2711 memory/PCIe traffic pattern. An upstream fix may be to mark VL805 Streams as broken, or add a narrower Streams/IN-specific workaround if one exists.

Current workaround

I restored the original, targeted workaround:

usb-storage.quirks=152d:0583:u

It forces only this 152d:0583 enclosure to use BOT instead of UAS and is stable at about 285 MB/s reads on this CM4.

The root filesystem is on this USB disk, so every UAS timeout makes the entire machine appear unresponsive for the SCSI timeout interval. Moving the root filesystem off this device would limit the impact while investigating.

---

Original report and system details follow below for historical context.

Original report

I encounter random USB hard disk I/O errors whenever I use the MIPI RPi camera and spyglass (which depends on python3-picamera2). Turning off WebRTC/H.264 encoding alleviates the issue. With H.264 enabled, very few read/write operations are needed to trigger the error; with it disabled, many reads/writes are needed. The error disappears after unplugging the camera or stopping spyglass. The power supply is a 5V/10A PSU and the CM4 carrier is not limited to 1.2A.

Device: Raspberry Pi CM4.

Earlier kernel: 6.12.62+rpt-rpi-v8 (the controlled retest above used 6.18.39+rpt-rpi-v8).