[RFC PATCH 0/1] media: uvcvideo: reset interface on bulk stream stop

[RFC PATCH 0/1] media: uvcvideo: reset interface on bulk stream stop

[Henry Lin]

Hi,

I would like to revive an old UVC bulk-streaming issue originally reported
by Hans Yang. I am sending this RFC on his behalf for discussion before
submitting a non-RFC patch.

Hans previously proposed making uvcvideo call usb_set_interface(..., 0)
when stopping a bulk-based stream, before clearing halt on the bulk endpoint.
The issue was discussed here:

  https://www.spinics.net/lists/linux-usb/msg171584.html

The current upstream stop path calls usb_set_interface(..., 0) only when the
streaming interface has more than one alternate setting. For single-altsetting
bulk devices, uvcvideo only sends CLEAR_FEATURE(ENDPOINT_HALT) to the bulk
endpoint.

The patch in this RFC changes uvc_video_stop_streaming() to always call
usb_set_interface(..., 0) to reset the streaming interface first. For
bulk devices, the existing CLEAR_FEATURE(ENDPOINT_HALT) request is still
sent afterwards.

On the affected devices, current upstream stop/start sequence can leave
the next bulk stream failing immediately with transfer errors such as:

  uvcvideo: Non-zero status (-71) in video completion handler.

USB bus traces show that, without usb_set_interface(..., 0), the host
continues the next bulk stream with the previous stream's sequence state,
while the device expects the new stream to start from the initial sequence
state. With usb_set_interface(..., 0), the host and device sequence states
match again and repeated stop/start cycles complete successfully.

The affected devices we have seen include:

  - ID 8086:0b07 Intel Corp. RealSense D435
  - ID 2560:c1d0 e-con Systems See3CAM_CU130
  - ID 2b03:f582 STEREOLABS ZED camera

I understand that the earlier discussion raised two important concerns:

  1. Whether this should be fixed in uvcvideo or lower in the USB/xHCI stack,
     since CLEAR_FEATURE(ENDPOINT_HALT) should normally reset the endpoint
     halt condition and data toggle/sequence state.

  2. Whether calling usb_set_interface(..., 0) for single-altsetting bulk UVC
     devices could regress existing devices.

For the first point, my understanding is that the kernel helper
usb_set_interface(..., 0) issues SET_INTERFACE and lets the USB core
reinitialize the endpoints for the selected alternate setting, including their
data toggle/sequence state. The traces suggest that, in this stop/start path,
CLEAR_FEATURE(ENDPOINT_HALT) alone is not enough to make the host and device
restart the next bulk stream from the same sequence state. The additional
usb_set_interface(..., 0) call makes repeated stop/start cycles reliable on
the affected hardware.

For the second point, I can provide before/after test results from the
affected hardware listed above. I can also test a quirk-based version if that
would be preferred over changing the generic bulk-stream stop path.

I would appreciate guidance on whether this one-patch RFC is the preferred
direction, or whether upstream would prefer a UVC quirk-based change for the
affected devices listed above.

Thanks,
Henry

[RFC PATCH 1/1] media: uvcvideo: reset interface on bulk stream stop

[Henry Lin]

From: Hans Yang <hansy@nvidia.com>

Some bulk-based UVC devices expect the stream sequence number to be
reset when the video stream is stopped. The driver currently issues
CLEAR_FEATURE(ENDPOINT_HALT) for bulk endpoints, but does not reset the
streaming interface alternate setting to 0 in that path.

When streaming is started again, the device may expect packets to
start from sequence number 0 while the host continues from the
previous transaction, leading to transfer errors such as:

  uvcvideo: Non-zero status (-71) in video completion handler.

Reset the streaming interface alternate setting to 0 before clearing
halt, matching the stop path used for isochronous endpoints.

Signed-off-by: Hans Yang <hansy@nvidia.com>
Signed-off-by: Henry Lin <henryl@nvidia.com>
---
 drivers/media/usb/uvc/uvc_video.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
index 2094e059d7d3..20cae606f463 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -2319,9 +2319,8 @@ void uvc_video_stop_streaming(struct uvc_streaming *stream)
 {
 	uvc_video_stop_transfer(stream, 1);
 
-	if (stream->intf->num_altsetting > 1) {
-		usb_set_interface(stream->dev->udev, stream->intfnum, 0);
-	} else {
+	usb_set_interface(stream->dev->udev, stream->intfnum, 0);
+	if (stream->intf->num_altsetting == 1) {
 		/*
 		 * UVC doesn't specify how to inform a bulk-based device
 		 * when the video stream is stopped. Windows sends a
-- 
2.43.0

Re: [RFC PATCH 0/1] media: uvcvideo: reset interface on bulk stream stop

[Alan Stern]

On Mon, May 25, 2026 at 06:20:27PM +0000, Henry Lin wrote:
> Hi,
> 
> I would like to revive an old UVC bulk-streaming issue originally reported
> by Hans Yang. I am sending this RFC on his behalf for discussion before
> submitting a non-RFC patch.
> 
> Hans previously proposed making uvcvideo call usb_set_interface(..., 0)
> when stopping a bulk-based stream, before clearing halt on the bulk endpoint.
> The issue was discussed here:
> 
>   https://www.spinics.net/lists/linux-usb/msg171584.html
> 
> The current upstream stop path calls usb_set_interface(..., 0) only when the
> streaming interface has more than one alternate setting. For single-altsetting
> bulk devices, uvcvideo only sends CLEAR_FEATURE(ENDPOINT_HALT) to the bulk
> endpoint.

How does it send this request?  By calling usb_clear_halt()?  Or some 
other way?

> The patch in this RFC changes uvc_video_stop_streaming() to always call
> usb_set_interface(..., 0) to reset the streaming interface first. For
> bulk devices, the existing CLEAR_FEATURE(ENDPOINT_HALT) request is still
> sent afterwards.
> 
> On the affected devices, current upstream stop/start sequence can leave
> the next bulk stream failing immediately with transfer errors such as:
> 
>   uvcvideo: Non-zero status (-71) in video completion handler.
> 
> USB bus traces show that, without usb_set_interface(..., 0), the host
> continues the next bulk stream with the previous stream's sequence state,
> while the device expects the new stream to start from the initial sequence
> state.

(I assume by "sequence state" you mean the USB-3 sequence number 
associated with the endpoint.)

Are you certain about this?  The usb_clear_halt() routine has reset 
the endpoint state, including the sequence number, ever since commit 
3444b26afa14 ("USB: add reset endpoint operations") was added in 2009.

If uvcvideo isn't using usb_clear_halt(), the simplest solution might be 
to make it do so.

Alan Stern

Re: [RFC PATCH 0/1] media: uvcvideo: reset interface on bulk stream stop

[Henry Lin]

Hi Alan,

> How does it send this request?  By calling usb_clear_halt()?  Or some
> other way?

Yes, it is using usb_clear_halt(). In uvc_video_stop_streaming(), the
single-altsetting bulk path builds the bulk pipe from
stream->header.bEndpointAddress and then calls:

	  usb_clear_halt(stream->dev->udev, pipe);

> Are you certain about this?  The usb_clear_halt() routine has reset
> the endpoint state, including the sequence number, ever since commit
> 3444b26afa14 ("USB: add reset endpoint operations") was added in 2009.
>
> If uvcvideo isn't using usb_clear_halt(), the simplest solution might be
> to make it do so.

Michal pointed me to this xHCI fix:

	  25e531b422dc ("usb: xhci: Make usb_host_endpoint.hcpriv
	  survive endpoint_disable()")

I tested that change on the affected setup, and it fixes the issue.
With that patch applied, repeated stop/start cycles complete
successfully, and I no longer see:

	  uvcvideo: Non-zero status (-71) in video completion handler.

So my previous conclusion was incomplete. uvcvideo is already calling
usb_clear_halt(); the issue appears to be covered by the xHCI fix
above, and the uvcvideo workaround in this RFC is not needed.

Thanks,
Henry

Re: [RFC PATCH 0/1] media: uvcvideo: reset interface on bulk stream stop

[Michal Pecio]

On Mon, 25 May 2026 18:20:27 +0000, Henry Lin wrote:
> I would like to revive an old UVC bulk-streaming issue originally
> reported by Hans Yang. I am sending this RFC on his behalf for
> discussion before submitting a non-RFC patch.
> 
> Hans previously proposed making uvcvideo call usb_set_interface(...,
> 0) when stopping a bulk-based stream, before clearing halt on the
> bulk endpoint. The issue was discussed here:
> 
>   https://www.spinics.net/lists/linux-usb/msg171584.html
> 
> The current upstream stop path calls usb_set_interface(..., 0) only
> when the streaming interface has more than one alternate setting. For
> single-altsetting bulk devices, uvcvideo only sends
> CLEAR_FEATURE(ENDPOINT_HALT) to the bulk endpoint.

You are referring to uvc_video_stop_streaming() here, right? This calls
usb_clear_halt(), which is supposed to reset both ends of the pipe.

> The patch in this RFC changes uvc_video_stop_streaming() to always
> call usb_set_interface(..., 0) to reset the streaming interface
> first. For bulk devices, the existing CLEAR_FEATURE(ENDPOINT_HALT)
> request is still sent afterwards.
> 
> On the affected devices, current upstream stop/start sequence can
> leave the next bulk stream failing immediately with transfer errors
> such as:
> 
>   uvcvideo: Non-zero status (-71) in video completion handler.
> 
> USB bus traces show that, without usb_set_interface(..., 0), the host
> continues the next bulk stream with the previous stream's sequence
> state, while the device expects the new stream to start from the
> initial sequence state. With usb_set_interface(..., 0), the host and
> device sequence states match again and repeated stop/start cycles
> complete successfully.

I suppose you mean SuperSpeed and xHCI, so that's a little mysterious
because xhci_hcd resets host sequence state on Transaction Error 
completions and hence it should recover from such mismatch after the
first error. Of course, no mismatch should exist in the first place. 

But xhci_hcd was broken for years and failed to clear host sequence
state when requested by usb_clear_halt() in some cases. This recent
commit fixed the most blatant bug and was motivated precisely by this
UVC issue, which I encountered myself.

25e531b422dc usb: xhci: Make usb_host_endpoint.hcpriv survive endpoint_disable()

Please check if this works for you, it's included in 7.1 RCs and some
latest stable kernels. If not, you might be affected by other bugs.

> The affected devices we have seen include:
> 
>   - ID 8086:0b07 Intel Corp. RealSense D435
>   - ID 2560:c1d0 e-con Systems See3CAM_CU130
>   - ID 2b03:f582 STEREOLABS ZED camera

I think all bulk devices were affected, and all SuperSpeed bulk devices
were affected particularly badly.

Regards,
Michal

Re: [RFC PATCH 0/1] media: uvcvideo: reset interface on bulk stream stop

[Henry Lin]

Hi Michal,

> Please check if this works for you, it's included in 7.1 RCs and some
> latest stable kernels. If not, you might be affected by other bugs.

I tested 25e531b422dc ("usb: xhci: Make usb_host_endpoint.hcpriv
survive endpoint_disable()") on the affected setup, and it fixes the
issue.

With that change applied, repeated stop/start cycles complete
successfully, and I no longer see the uvcvideo -71 transfer errors.

So I think the uvcvideo workaround in this RFC is not needed. The issue
is covered by the xHCI fix.

Thanks,
Henry

Re: [RFC PATCH 0/1] media: uvcvideo: reset interface on bulk stream stop

[Michal Pecio]

On Tue, 26 May 2026 09:55:19 +0000, Henry Lin wrote:
> I tested 25e531b422dc ("usb: xhci: Make usb_host_endpoint.hcpriv
> survive endpoint_disable()") on the affected setup, and it fixes the
> issue.

Good.
 
> With that change applied, repeated stop/start cycles complete
> successfully, and I no longer see the uvcvideo -71 transfer errors.

Were you seeing one such error for each restart, followed by uvcvideo
dropping a few frames and continuing to stream normally, or multiple
transaction errors and complete functional failure?

I was seeing the formrer on several tested HCs, except for those from
ASMedia which never completed the affected URB at all (IMO a HW bug).

I think multiple errors would also be an indication of some bug,
possibly in HW, possibly worth looking into in its own right.

Regards,
Michal

Re: [RFC PATCH 0/1] media: uvcvideo: reset interface on bulk stream stop

[Henry Lin]

Hi Michal,

> Were you seeing one such error for each restart, followed by uvcvideo
> dropping a few frames and continuing to stream normally, or multiple
> transaction errors and complete functional failure?

On the NVIDIA xHCI host controller, I see the former.

After each stop/start cycle, uvcvideo reports one -71 completion error,
and only the first frame is broken. Streaming then continues normally. I
do not see multiple transaction errors or a complete functional failure.

With 25e531b422dc applied, the -71 completion error no longer appears in
the same test.

Thanks,
Henry

Re: [RFC PATCH 0/1] media: uvcvideo: reset interface on bulk stream stop

[Michal Pecio]

On Thu, 28 May 2026 08:36:12 +0000, Henry Lin wrote:
> > Were you seeing one such error for each restart, followed by
> > uvcvideo dropping a few frames and continuing to stream normally,
> > or multiple transaction errors and complete functional failure?  
> 
> On the NVIDIA xHCI host controller, I see the former.
> 
> After each stop/start cycle, uvcvideo reports one -71 completion
> error, and only the first frame is broken. Streaming then continues
> normally. I do not see multiple transaction errors or a complete
> functional failure.
> 
> With 25e531b422dc applied, the -71 completion error no longer appears
> in the same test.

No worries then, this is expected behavior and a known bug, now fixed.

Regards,
Michal