Re: correctly handling EPROTO

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

On Mon, 30 Mar 2026 14:36:00 +0200, Michal Pecio wrote:
> UVC allows both isoc and bulk transport. I have one bulk device and I
> found that if I randomly change urb->status to -EPROTO, the URB is not
> resubmitted but (on xHCI) the endpoint keeps going, until it stops after
> 5 errors (no URBs left). EHCI would presumably never restart at all.

I tried this again with real transaction errors (dodgy cable) on EHCI
with disabled XactErr retries and I see identical result. Failed URBs
are never submitted again (checked with usbmon) but the endpoint keeps 
going as long as there are other URBs remaining.

[285740.194700] usb 4-4: new high-speed USB device number 3 using ehci-pci
[285740.243438] usb 4-4: New USB device found, idVendor=345f, idProduct=2130, bcdDevice=21.00
[285740.243448] usb 4-4: New USB device strings: Mfr=1, Product=2, SerialNumber=7
[285740.243452] usb 4-4: Product: USB3 Video
[285740.243455] usb 4-4: Manufacturer: UltraSemi
[285740.243457] usb 4-4: SerialNumber: 20210621
[285740.263078] uvcvideo 4-4:1.0: Found UVC 1.00 device USB3 Video (345f:2130)
[285745.210034] uvcvideo 4-4:1.0: Allocated 5 URB buffers of 30x512 bytes each
[285745.563613] ehci-pci 0000:08:00.2: devpath 4 ep3in 3strikes
[285745.563667] uvcvideo 4-4:1.1: Non-zero status (-71) in video completion handler.
[285745.830190] ehci-pci 0000:08:00.2: devpath 4 ep3in 3strikes
[285745.830233] uvcvideo 4-4:1.1: Non-zero status (-71) in video completion handler.
[285746.145090] ehci-pci 0000:08:00.2: devpath 4 ep3in 3strikes
[285746.145112] uvcvideo 4-4:1.1: Non-zero status (-71) in video completion handler.
[285746.500756] ehci-pci 0000:08:00.2: devpath 4 ep3in 3strikes
[285746.500778] uvcvideo 4-4:1.1: Non-zero status (-71) in video completion handler.
[285746.771547] ehci-pci 0000:08:00.2: devpath 4 ep3in 3strikes
[285746.771571] uvcvideo 4-4:1.1: Non-zero status (-71) in video completion handler.

# urb1
ffff8881a653ab40 3478085173 C Bi:4:003:3 0 15360 = 0c8d8a89 cd94dc59 d1941900 10801080 10801080 10801080 10801080 10801080
ffff8881a653ab40 3478085194 S Bi:4:003:3 -115 15360 <
# urb2
ffff8881be27dd80 3478085930 C Bi:4:003:3 0 15360 = 0c8d8a89 cd943acd d2941a00 10801080 10801080 10801080 10801080 10801080
ffff8881be27dd80 3478085955 S Bi:4:003:3 -115 15360 <
# urb3
ffff88814746f840 3478086931 C Bi:4:003:3 0 15360 = 0c8d8a89 cd94fe45 d4941b00 10801080 10801080 10801080 10801080 10801080
ffff88814746f840 3478086995 S Bi:4:003:3 -115 15360 <
# urb4
ffff8881617b3480 3478087544 C Bi:4:003:3 0 15360 = 0c8d8a89 cd94fab6 d5941c00 10801080 10801080 10801080 10801080 10801080
ffff8881617b3480 3478087563 S Bi:4:003:3 -115 15360 <
# urb1 errors out
ffff8881a653ab40 3478087703 C Bi:4:003:3 -71 0
# urb2
ffff8881be27dd80 3478088803 C Bi:4:003:3 0 15360 = 0c8d8a89 cd94f730 d7941d00 10801080 10801080 10801080 10801080 10801080
ffff8881be27dd80 3478088813 S Bi:4:003:3 -115 15360 <
# urb3
ffff88814746f840 3478089546 C Bi:4:003:3 0 15360 = 0c8d8a89 cd949cc4 d8941d00 10801080 10801080 10801080 10801080 10801080
ffff88814746f840 3478089554 S Bi:4:003:3 -115 15360 <
...

Not sure why it happens, maybe it's just the async giveback race,
but it worked like that reliably several times.