Consultation on the issue of digital headphones freezing

Consultation on the issue of digital headphones freezing

[胡连勤]

Hello linux experts:

I have a question. My device freezes when using it with digital headphones. 
The stack trace is as follows:

[192165.107937][    C0] xhci-hcd xhci-hcd.3.auto: Error: Failed finding new dequeue state
[192165.107946][    C0] xhci-hcd xhci-hcd.3.auto: Failed to clear cancelled cached URB 000000002d756eab, mark clear anyway
[192165.108387][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd
[192165.225904][T17454] usb 1-1: device descriptor read/64, error -71
[192165.442224][T17454] usb 1-1: Device not responding to setup address.
[192165.642107][T17454] usb 1-1: Device not responding to setup address.
[192165.845879][T17454] usb 1-1: device not accepting address 2, error -71
[192165.846031][T17454] usb 1-1: WARN: invalid context state for evaluate context command.
[192165.957927][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd
[192165.958032][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup context command completion code 0x11.
[192165.958040][T17454] usb 1-1: hub failed to enable device, error -22
[192165.958165][T17454] usb 1-1: WARN: invalid context state for evaluate context command.
[192166.070623][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd
[192166.070728][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup address command completion code 0x11.
[192166.273835][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup address command completion code 0x11.
[192166.473788][T17454] usb 1-1: device not accepting address 2, error -22
[192166.473943][T17454] usb 1-1: WARN: invalid context state for evaluate context command.
[192166.585802][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd
[192166.585901][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup address command completion code 0x11.
[192166.785850][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup address command completion code 0x11.
[192166.985829][T17454] usb 1-1: device not accepting address 2, error -22
[192166.986836][T17454] usb 1-1: USB disconnect, device number 2
[192166.990744][T17170] pc : xhci_initialize_ring_info+0x0/0x30
[192166.990754][T17170] lr : xhci_sideband_remove_endpoint+0x84/0xb8
[192166.990760][T17170] sp : ffffffc0f2d6ba10
[192166.990763][T17170] x29: ffffffc0f2d6ba10 x28: ffffff884082a7c0 x27: ffffff89e4e43c00
[192166.990772][T17170] x26: ffffff8a689d2c00 x25: 0000000000000000 x24: 0000000000000000
[192166.990780][T17170] x23: ffffffe881212e50 x22: ffffff88feaad210 x21: 00000000ffffffed
[192166.990788][T17170] x20: ffffff8880dd6200 x19: ffffff88feaad200 x18: ffffffe883debf00
[192166.990795][T17170] x17: 00000000e11f7a81 x16: 00000000e11f7a81 x15: 0000000000000000
[192166.990803][T17170] x14: 0000000000000000 x13: 0000000000000000 x12: ffffff89a7dcfc60
[192166.990811][T17170] x11: 0000000000000029 x10: 0000000000000000 x9 : 03f28220e26a0a00
[192166.990818][T17170] x8 : 0000000000000003 x7 : 0000000000000000 x6 : 0000000000000000
[192166.990826][T17170] x5 : ffffffe88253eda8 x4 : fffffffee69f73e0 x3 : 00000000802a0029
[192166.990834][T17170] x2 : ffffff89a7dcfc60 x1 : 00000000802a002a x0 : 0000000000000000
[192166.990841][T17170] Call trace:
[192166.990843][T17170]  xhci_initialize_ring_info+0x0/0x30
[192166.990853][T17170]  handle_uaudio_stream_req+0xacc/0xda0 [snd_usb_audio_qmi 0fac57c02f06d038d015e5719390f9b3eda86e61]
[192166.990865][T17170]  qmi_invoke_handler+0xd8/0x144 [qmi_helpers 4e26e13e3f77f3f53f00b1285e47dea9167ec3b4]
[192166.990878][T17170]  qmi_data_ready_work+0x2ec/0x764 [qmi_helpers 4e26e13e3f77f3f53f00b1285e47dea9167ec3b4]
[192166.990891][T17170]  process_scheduled_works+0x1c4/0x45c
[192166.990897][T17170]  worker_thread+0x32c/0x3e8
[192166.990903][T17170]  kthread+0x11c/0x1b0
[192166.990912][T17170]  ret_from_fork+0x10/0x20
[192166.990921][T17170] Code: a8c37bfd d50323bf d65f03c0 cee7796a (f9400009) 
[192166.990924][T17170] ---[ end trace 0000000000000000 ]---
[192166.990929][T17170] Kernel panic - not syncing: Oops: Fatal exception
[192166.990932][T17170] SMP: stopping secondary CPUs

Trace 32 analysis revealed that the crash was caused by ep->ring being null when calling the xhci_sideband_remove_endpoint function. 
I haven't come up with a better solution than this one.
diff --git a/drivers/usb/host/xhci-sideband.c b/drivers/usb/host/xhci-sideband.c
index a85f62a73313..04ae2cbba838 100644
--- a/drivers/usb/host/xhci-sideband.c
+++ b/drivers/usb/host/xhci-sideband.c
@@ -206,7 +206,7 @@ xhci_sideband_remove_endpoint(struct xhci_sideband *sb,
 	ep_index = xhci_get_endpoint_index(&host_ep->desc);
 	ep = sb->eps[ep_index];
 
-	if (!ep || !ep->sideband || ep->sideband != sb)
+	if (!ep || !ep->sideband || !ep->ring || ep->sideband != sb)
 		return -ENODEV;
 
 	__xhci_sideband_remove_endpoint(sb, ep);
-- 
2.39.0

I would like to ask for advice from experts on effective ways to fix this problem.

Thanks

Re: Consultation on the issue of digital headphones freezing

[Mathias Nyman]

Hi

On 1/4/26 14:44, 胡连勤 wrote:
> Hello linux experts:
> 
> I have a question. My device freezes when using it with digital headphones.
> The stack trace is as follows:
> 
> [192165.107937][    C0] xhci-hcd xhci-hcd.3.auto: Error: Failed finding new dequeue state
> [192165.107946][    C0] xhci-hcd xhci-hcd.3.auto: Failed to clear cancelled cached URB 000000002d756eab, mark clear anyway
> [192165.108387][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd
> [192165.225904][T17454] usb 1-1: device descriptor read/64, error -71
> [192165.442224][T17454] usb 1-1: Device not responding to setup address.
> [192165.642107][T17454] usb 1-1: Device not responding to setup address.
> [192165.845879][T17454] usb 1-1: device not accepting address 2, error -71
> [192165.846031][T17454] usb 1-1: WARN: invalid context state for evaluate context command.
> [192165.957927][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd
> [192165.958032][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup context command completion code 0x11.
> [192165.958040][T17454] usb 1-1: hub failed to enable device, error -22
> [192165.958165][T17454] usb 1-1: WARN: invalid context state for evaluate context command.
> [192166.070623][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd
> [192166.070728][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup address command completion code 0x11.
> [192166.273835][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup address command completion code 0x11.
> [192166.473788][T17454] usb 1-1: device not accepting address 2, error -22
> [192166.473943][T17454] usb 1-1: WARN: invalid context state for evaluate context command.
> [192166.585802][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd
> [192166.585901][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup address command completion code 0x11.
> [192166.785850][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup address command completion code 0x11.
> [192166.985829][T17454] usb 1-1: device not accepting address 2, error -22
> [192166.986836][T17454] usb 1-1: USB disconnect, device number 2
> [192166.990744][T17170] pc : xhci_initialize_ring_info+0x0/0x30
> [192166.990754][T17170] lr : xhci_sideband_remove_endpoint+0x84/0xb8
> [192166.990760][T17170] sp : ffffffc0f2d6ba10
> [192166.990763][T17170] x29: ffffffc0f2d6ba10 x28: ffffff884082a7c0 x27: ffffff89e4e43c00
> [192166.990772][T17170] x26: ffffff8a689d2c00 x25: 0000000000000000 x24: 0000000000000000
> [192166.990780][T17170] x23: ffffffe881212e50 x22: ffffff88feaad210 x21: 00000000ffffffed
> [192166.990788][T17170] x20: ffffff8880dd6200 x19: ffffff88feaad200 x18: ffffffe883debf00
> [192166.990795][T17170] x17: 00000000e11f7a81 x16: 00000000e11f7a81 x15: 0000000000000000
> [192166.990803][T17170] x14: 0000000000000000 x13: 0000000000000000 x12: ffffff89a7dcfc60
> [192166.990811][T17170] x11: 0000000000000029 x10: 0000000000000000 x9 : 03f28220e26a0a00
> [192166.990818][T17170] x8 : 0000000000000003 x7 : 0000000000000000 x6 : 0000000000000000
> [192166.990826][T17170] x5 : ffffffe88253eda8 x4 : fffffffee69f73e0 x3 : 00000000802a0029
> [192166.990834][T17170] x2 : ffffff89a7dcfc60 x1 : 00000000802a002a x0 : 0000000000000000
> [192166.990841][T17170] Call trace:
> [192166.990843][T17170]  xhci_initialize_ring_info+0x0/0x30
> [192166.990853][T17170]  handle_uaudio_stream_req+0xacc/0xda0 [snd_usb_audio_qmi 0fac57c02f06d038d015e5719390f9b3eda86e61]
> [192166.990865][T17170]  qmi_invoke_handler+0xd8/0x144 [qmi_helpers 4e26e13e3f77f3f53f00b1285e47dea9167ec3b4]
> [192166.990878][T17170]  qmi_data_ready_work+0x2ec/0x764 [qmi_helpers 4e26e13e3f77f3f53f00b1285e47dea9167ec3b4]
> [192166.990891][T17170]  process_scheduled_works+0x1c4/0x45c
> [192166.990897][T17170]  worker_thread+0x32c/0x3e8
> [192166.990903][T17170]  kthread+0x11c/0x1b0
> [192166.990912][T17170]  ret_from_fork+0x10/0x20
> [192166.990921][T17170] Code: a8c37bfd d50323bf d65f03c0 cee7796a (f9400009)
> [192166.990924][T17170] ---[ end trace 0000000000000000 ]---
> [192166.990929][T17170] Kernel panic - not syncing: Oops: Fatal exception
> [192166.990932][T17170] SMP: stopping secondary CPUs
> 
> Trace 32 analysis revealed that the crash was caused by ep->ring being null when calling the xhci_sideband_remove_endpoint function.
> I haven't come up with a better solution than this one.
> diff --git a/drivers/usb/host/xhci-sideband.c b/drivers/usb/host/xhci-sideband.c
> index a85f62a73313..04ae2cbba838 100644
> --- a/drivers/usb/host/xhci-sideband.c
> +++ b/drivers/usb/host/xhci-sideband.c
> @@ -206,7 +206,7 @@ xhci_sideband_remove_endpoint(struct xhci_sideband *sb,
>   	ep_index = xhci_get_endpoint_index(&host_ep->desc);
>   	ep = sb->eps[ep_index];
>   
> -	if (!ep || !ep->sideband || ep->sideband != sb)
> +	if (!ep || !ep->sideband || !ep->ring || ep->sideband != sb)
>   		return -ENODEV;

We can't return yet if endpoint and sideband are valid, but ring is missing.
We should still set

ep->sideband = NULL;
sb->eps[ep->ep_index] = NULL;

in __xhci_sideband_remove() for this sideband and endpoint.

Was xhci_sideband_notify_ep_ring_free() called for this endpoint?
We can in that case possibly avoid calling both xhci_stop_endpoint_sync()
and xhci_initialize_ring_info() during this xhci_sideband_remove_endpoint()
call.


The failure to find new dequeue states also look worrying:
[192165.107937][    C0] xhci-hcd xhci-hcd.3.auto: Error: Failed finding new dequeue state
[192165.107946][    C0] xhci-hcd xhci-hcd.3.auto: Failed to clear cancelled cached URB 000000002d756eab, mark clear anyway

If this endpoint is offloaded (sideband) then xhci driver shouldn't try
to find a new dequeue position.

Thanks
Mathias

答复: Consultation on the issue of digital headphones freezing

[胡连勤]

Hi  Mathias:

> > [192165.107937][    C0] xhci-hcd xhci-hcd.3.auto: Error: Failed finding new dequeue state
> > [192165.107946][    C0] xhci-hcd xhci-hcd.3.auto: Failed to clear cancelled cached URB 000000002d756eab, mark clear anyway
> > [192165.108387][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd
> > [192165.225904][T17454] usb 1-1: device descriptor read/64, error -71
> > [192165.442224][T17454] usb 1-1: Device not responding to setup address.
> > [192165.642107][T17454] usb 1-1: Device not responding to setup address.
> > [192165.845879][T17454] usb 1-1: device not accepting address 2, error -71
> > [192165.846031][T17454] usb 1-1: WARN: invalid context state for evaluate context command.
> > [192165.957927][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd
> > [192165.958032][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup context command completion code 0x11.
> > [192165.958040][T17454] usb 1-1: hub failed to enable device, error -22
> > [192165.958165][T17454] usb 1-1: WARN: invalid context state for evaluate context command.
> > [192166.070623][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd
> > [192166.070728][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup address command completion code 0x11.
> > [192166.273835][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup address command completion code 0x11.
> > [192166.473788][T17454] usb 1-1: device not accepting address 2, error -22
> > [192166.473943][T17454] usb 1-1: WARN: invalid context state for evaluate context command.
> > [192166.585802][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd
> > [192166.585901][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup address command completion code 0x11.
> > [192166.785850][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup address command completion code 0x11.
> > [192166.985829][T17454] usb 1-1: device not accepting address 2, error -22
> > [192166.986836][T17454] usb 1-1: USB disconnect, device number 2
> > [192166.990744][T17170] pc : xhci_initialize_ring_info+0x0/0x30
> > [192166.990754][T17170] lr : xhci_sideband_remove_endpoint+0x84/0xb8
> > [192166.990760][T17170] sp : ffffffc0f2d6ba10
> > [192166.990763][T17170] x29: ffffffc0f2d6ba10 x28: ffffff884082a7c0 x27: ffffff89e4e43c00
> > [192166.990772][T17170] x26: ffffff8a689d2c00 x25: 0000000000000000 x24: 0000000000000000
> > [192166.990780][T17170] x23: ffffffe881212e50 x22: ffffff88feaad210 x21: 00000000ffffffed
> > [192166.990788][T17170] x20: ffffff8880dd6200 x19: ffffff88feaad200 x18: ffffffe883debf00
> > [192166.990795][T17170] x17: 00000000e11f7a81 x16: 00000000e11f7a81 x15: 0000000000000000
> > [192166.990803][T17170] x14: 0000000000000000 x13: 0000000000000000 x12: ffffff89a7dcfc60
> > [192166.990811][T17170] x11: 0000000000000029 x10: 0000000000000000 x9 : 03f28220e26a0a00
> > [192166.990818][T17170] x8 : 0000000000000003 x7 : 0000000000000000 x6 : 0000000000000000
> > [192166.990826][T17170] x5 : ffffffe88253eda8 x4 : fffffffee69f73e0 x3 : 00000000802a0029
> > [192166.990834][T17170] x2 : ffffff89a7dcfc60 x1 : 00000000802a002a x0 : 0000000000000000
> > [192166.990841][T17170] Call trace:
> > [192166.990843][T17170]  xhci_initialize_ring_info+0x0/0x30
> > [192166.990853][T17170]  handle_uaudio_stream_req+0xacc/0xda0 [snd_usb_audio_qmi 0fac57c02f06d038d015e5719390f9b3eda86e61]
> > [192166.990865][T17170]  qmi_invoke_handler+0xd8/0x144 [qmi_helpers 4e26e13e3f77f3f53f00b1285e47dea9167ec3b4]
> > [192166.990878][T17170]  qmi_data_ready_work+0x2ec/0x764 [qmi_helpers 4e26e13e3f77f3f53f00b1285e47dea9167ec3b4]
> > [192166.990891][T17170]  process_scheduled_works+0x1c4/0x45c
> > [192166.990897][T17170]  worker_thread+0x32c/0x3e8
> > [192166.990903][T17170]  kthread+0x11c/0x1b0
> > [192166.990912][T17170]  ret_from_fork+0x10/0x20
> > [192166.990921][T17170] Code: a8c37bfd d50323bf d65f03c0 cee7796a (f9400009)
> > [192166.990924][T17170] ---[ end trace 0000000000000000 ]---
> > [192166.990929][T17170] Kernel panic - not syncing: Oops: Fatal exception
> > [192166.990932][T17170] SMP: stopping secondary CPUs
> >
> > Trace 32 analysis revealed that the crash was caused by ep->ring being null when calling the xhci_sideband_remove_endpoint function.
> > I haven't come up with a better solution than this one.
> > diff --git a/drivers/usb/host/xhci-sideband.c b/drivers/usb/host/xhci-sideband.c
> > index a85f62a73313..04ae2cbba838 100644
> > --- a/drivers/usb/host/xhci-sideband.c
> > +++ b/drivers/usb/host/xhci-sideband.c
> > @@ -206,7 +206,7 @@ xhci_sideband_remove_endpoint(struct xhci_sideband *sb,
> >   	ep_index = xhci_get_endpoint_index(&host_ep->desc);
> >   	ep = sb->eps[ep_index];
> >
> > -	if (!ep || !ep->sideband || ep->sideband != sb)
> > +	if (!ep || !ep->sideband || !ep->ring || ep->sideband != sb)
> >   		return -ENODEV;
> 
> We can't return yet if endpoint and sideband are valid, but ring is missing.
> We should still set
> 
> ep->sideband = NULL;
> sb->eps[ep->ep_index] = NULL;
> 
> in __xhci_sideband_remove() for this sideband and endpoint.
> 
> Was xhci_sideband_notify_ep_ring_free() called for this endpoint?

The code logic was checked and found not to call the `xhci_sideband_notify_ep_ring_free` function.
Actual code calls:
The `xhci_sideband_stop_endpoint` function was called previously:
handle_uaudio_stream_req()
{
    ...
   xhci_sideband_stop_endpoint(uadev[pcm_card_num].sb, ep); 
    xhci_sideband_remove_endpoint(uadev[pcm_card_num].sb, ep);   ----> crash
    ...
}

> We can in that case possibly avoid calling both xhci_stop_endpoint_sync()
> and xhci_initialize_ring_info() during this xhci_sideband_remove_endpoint()
> call.
> 
> 
> The failure to find new dequeue states also look worrying:
> [192165.107937][    C0] xhci-hcd xhci-hcd.3.auto: Error: Failed finding new dequeue state
> [192165.107946][    C0] xhci-hcd xhci-hcd.3.auto: Failed to clear cancelled cached URB 000000002d756eab, mark clear anyway
> 
> If this endpoint is offloaded (sideband) then xhci driver shouldn't try
> to find a new dequeue position.

Thanks
Lianqin

答复: Consultation on the issue of digital headphones freezing

[胡连勤]

Hi  Mathias:

> > > [192165.107937][    C0] xhci-hcd xhci-hcd.3.auto: Error: Failed finding new dequeue state
> > > [192165.107946][    C0] xhci-hcd xhci-hcd.3.auto: Failed to clear cancelled cached URB 000000002d756eab, mark clear anyway
> > > [192165.108387][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd              --> 1st  reset
> > > [192165.225904][T17454] usb 1-1: device descriptor read/64, error -71
> > > [192165.442224][T17454] usb 1-1: Device not responding to setup address.
> > > [192165.642107][T17454] usb 1-1: Device not responding to setup address.
> > > [192165.845879][T17454] usb 1-1: device not accepting address 2, error -71
> > > [192165.846031][T17454] usb 1-1: WARN: invalid context state for evaluate context command.
> > > [192165.957927][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd             --> 2st reset
> > > [192165.958032][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup context command completion code 0x11.
> > > [192165.958040][T17454] usb 1-1: hub failed to enable device, error -22
> > > [192165.958165][T17454] usb 1-1: WARN: invalid context state for evaluate context command.
> > > [192166.070623][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd            --> 3st reset
> > > [192166.070728][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup address command completion code 0x11.
> > > [192166.273835][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup address command completion code 0x11.
> > > [192166.473788][T17454] usb 1-1: device not accepting address 2, error -22
> > > [192166.473943][T17454] usb 1-1: WARN: invalid context state for evaluate context command.
> > > [192166.585802][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd           -->  4st reset

Upon checking the exception log again, four device reset operations were observed.
Analyzing the code flow, after each of the four resets, the `xhci_free_endpoint_ring` function is called,
setting `ep->ring` to null.

The specific call is as follows:
>usb_reset_device
>->usb_reset_and_verify_device
>->->usb_hcd_alloc_bandwidth
>->->->hcd->driver->check_bandwidth(hcd, udev)
>->->->->xhci_check_bandwidth
>->->->->->xhci_free_endpoint_ring

void xhci_free_endpoint_ring(struct xhci_hcd *xhci,
		struct xhci_virt_device *virt_dev,
		unsigned int ep_index)
{
	xhci_ring_free(xhci, virt_dev->eps[ep_index].ring);
	virt_dev->eps[ep_index].ring = NULL;     ---> ep->rings = NULL
}

static int usb_reset_and_verify_device(struct usb_device *udev)
{
...
	-> The device will undergo four reset operations here.
	for (i = 0; i < PORT_INIT_TRIES; ++i) {
		if (hub_port_stop_enumerate(parent_hub, port1, i)) {
			ret = -ENODEV;
			break;
		}

		/* ep0 maxpacket size may change; let the HCD know about it.
		 * Other endpoints will be handled by re-enumeration. */
		usb_ep0_reinit(udev);
		ret = hub_port_init(parent_hub, udev, port1, i, &descriptor);     ----> reset devices
		if (ret >= 0 || ret == -ENOTCONN || ret == -ENODEV)
			break;
	}
...
}

> > > [192166.585901][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup address command completion code 0x11.
> > > [192166.785850][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup address command completion code 0x11.
> > > [192166.985829][T17454] usb 1-1: device not accepting address 2, error -22
> > > [192166.986836][T17454] usb 1-1: USB disconnect, device number 2
> > > [192166.990744][T17170] pc : xhci_initialize_ring_info+0x0/0x30
> > > [192166.990754][T17170] lr : xhci_sideband_remove_endpoint+0x84/0xb8
> > > [192166.990760][T17170] sp : ffffffc0f2d6ba10
> > > [192166.990763][T17170] x29: ffffffc0f2d6ba10 x28: ffffff884082a7c0 x27: ffffff89e4e43c00
> > > [192166.990772][T17170] x26: ffffff8a689d2c00 x25: 0000000000000000 x24: 0000000000000000
> > > [192166.990780][T17170] x23: ffffffe881212e50 x22: ffffff88feaad210 x21: 00000000ffffffed
> > > [192166.990788][T17170] x20: ffffff8880dd6200 x19: ffffff88feaad200 x18: ffffffe883debf00
> > > [192166.990795][T17170] x17: 00000000e11f7a81 x16: 00000000e11f7a81 x15: 0000000000000000
> > > [192166.990803][T17170] x14: 0000000000000000 x13: 0000000000000000 x12: ffffff89a7dcfc60
> > > [192166.990811][T17170] x11: 0000000000000029 x10: 0000000000000000 x9 : 03f28220e26a0a00
> > > [192166.990818][T17170] x8 : 0000000000000003 x7 : 0000000000000000 x6 : 0000000000000000
> > > [192166.990826][T17170] x5 : ffffffe88253eda8 x4 : fffffffee69f73e0 x3 : 00000000802a0029
> > > [192166.990834][T17170] x2 : ffffff89a7dcfc60 x1 : 00000000802a002a x0 : 0000000000000000
> > > [192166.990841][T17170] Call trace:
> > > [192166.990843][T17170]  xhci_initialize_ring_info+0x0/0x30
> > > [192166.990853][T17170]  handle_uaudio_stream_req+0xacc/0xda0 [snd_usb_audio_qmi 0fac57c02f06d038d015e5719390f9b3eda86e61]
> > > [192166.990865][T17170]  qmi_invoke_handler+0xd8/0x144 [qmi_helpers 4e26e13e3f77f3f53f00b1285e47dea9167ec3b4]
> > > [192166.990878][T17170]  qmi_data_ready_work+0x2ec/0x764 [qmi_helpers 4e26e13e3f77f3f53f00b1285e47dea9167ec3b4]
> > > [192166.990891][T17170]  process_scheduled_works+0x1c4/0x45c
> > > [192166.990897][T17170]  worker_thread+0x32c/0x3e8
> > > [192166.990903][T17170]  kthread+0x11c/0x1b0
> > > [192166.990912][T17170]  ret_from_fork+0x10/0x20
> > > [192166.990921][T17170] Code: a8c37bfd d50323bf d65f03c0 cee7796a (f9400009)
> > > [192166.990924][T17170] ---[ end trace 0000000000000000 ]---
> > > [192166.990929][T17170] Kernel panic - not syncing: Oops: Fatal exception
> > > [192166.990932][T17170] SMP: stopping secondary CPUs
> > >
> > > Trace 32 analysis revealed that the crash was caused by ep->ring being null when calling the xhci_sideband_remove_endpoint function.
> > > I haven't come up with a better solution than this one.
> > > diff --git a/drivers/usb/host/xhci-sideband.c b/drivers/usb/host/xhci-sideband.c
> > > index a85f62a73313..04ae2cbba838 100644
> > > --- a/drivers/usb/host/xhci-sideband.c
> > > +++ b/drivers/usb/host/xhci-sideband.c
> > > @@ -206,7 +206,7 @@ xhci_sideband_remove_endpoint(struct xhci_sideband *sb,
> > >   	ep_index = xhci_get_endpoint_index(&host_ep->desc);
> > >   	ep = sb->eps[ep_index];
> > >
> > > -	if (!ep || !ep->sideband || ep->sideband != sb)
> > > +	if (!ep || !ep->sideband || !ep->ring || ep->sideband != sb)
> > >   		return -ENODEV;
> >
> > We can't return yet if endpoint and sideband are valid, but ring is missing.
> > We should still set
> >
> > ep->sideband = NULL;
> > sb->eps[ep->ep_index] = NULL;
> >
> > in __xhci_sideband_remove() for this sideband and endpoint.
> >
> > Was xhci_sideband_notify_ep_ring_free() called for this endpoint?
> 
> The code logic was checked and found not to call the `xhci_sideband_notify_ep_ring_free` function.
> Actual code calls:
> The `xhci_sideband_stop_endpoint` function was called previously:
> handle_uaudio_stream_req()
> {
>     ...
>    xhci_sideband_stop_endpoint(uadev[pcm_card_num].sb, ep);
>     xhci_sideband_remove_endpoint(uadev[pcm_card_num].sb, ep);   ----> crash
>     ...
> }
> 
> > We can in that case possibly avoid calling both xhci_stop_endpoint_sync()
> > and xhci_initialize_ring_info() during this xhci_sideband_remove_endpoint()
> > call.
> >
> >
> > The failure to find new dequeue states also look worrying:
> > [192165.107937][    C0] xhci-hcd xhci-hcd.3.auto: Error: Failed finding new dequeue state
> > [192165.107946][    C0] xhci-hcd xhci-hcd.3.auto: Failed to clear cancelled cached URB 000000002d756eab, mark clear anyway
> >
> > If this endpoint is offloaded (sideband) then xhci driver shouldn't try
> > to find a new dequeue position.

Thanks
Lianqin

Re: 答复: Consultation on the issue of digital headphones freezing

[Mathias Nyman]

Hi Lianqin

On 1/7/26 12:08, 胡连勤 wrote:
> Hi  Mathias:
> 
>>>> [192165.107937][    C0] xhci-hcd xhci-hcd.3.auto: Error: Failed finding new dequeue state
>>>> [192165.107946][    C0] xhci-hcd xhci-hcd.3.auto: Failed to clear cancelled cached URB 000000002d756eab, mark clear anyway
>>>> [192165.108387][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd              --> 1st  reset
>>>> [192165.225904][T17454] usb 1-1: device descriptor read/64, error -71
>>>> [192165.442224][T17454] usb 1-1: Device not responding to setup address.
>>>> [192165.642107][T17454] usb 1-1: Device not responding to setup address.
>>>> [192165.845879][T17454] usb 1-1: device not accepting address 2, error -71
>>>> [192165.846031][T17454] usb 1-1: WARN: invalid context state for evaluate context command.
>>>> [192165.957927][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd             --> 2st reset
>>>> [192165.958032][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup context command completion code 0x11.
>>>> [192165.958040][T17454] usb 1-1: hub failed to enable device, error -22
>>>> [192165.958165][T17454] usb 1-1: WARN: invalid context state for evaluate context command.
>>>> [192166.070623][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd            --> 3st reset
>>>> [192166.070728][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup address command completion code 0x11.
>>>> [192166.273835][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup address command completion code 0x11.
>>>> [192166.473788][T17454] usb 1-1: device not accepting address 2, error -22
>>>> [192166.473943][T17454] usb 1-1: WARN: invalid context state for evaluate context command.
>>>> [192166.585802][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd           -->  4st reset
> 
> Upon checking the exception log again, four device reset operations were observed.
> Analyzing the code flow, after each of the four resets, the `xhci_free_endpoint_ring` function is called,
> setting `ep->ring` to null.
> 
> The specific call is as follows:
>> usb_reset_device
>> ->usb_reset_and_verify_device
>> ->->usb_hcd_alloc_bandwidth
>> ->->->hcd->driver->check_bandwidth(hcd, udev)
>> ->->->->xhci_check_bandwidth
>> ->->->->->xhci_free_endpoint_ring
> 
> void xhci_free_endpoint_ring(struct xhci_hcd *xhci,
> 		struct xhci_virt_device *virt_dev,
> 		unsigned int ep_index)
> {
> 	xhci_ring_free(xhci, virt_dev->eps[ep_index].ring);
> 	virt_dev->eps[ep_index].ring = NULL;     ---> ep->rings = NULL
> }
> 
> static int usb_reset_and_verify_device(struct usb_device *udev)
> {
> ...
> 	-> The device will undergo four reset operations here.
> 	for (i = 0; i < PORT_INIT_TRIES; ++i) {
> 		if (hub_port_stop_enumerate(parent_hub, port1, i)) {
> 			ret = -ENODEV;
> 			break;
> 		}
> 
> 		/* ep0 maxpacket size may change; let the HCD know about it.
> 		 * Other endpoints will be handled by re-enumeration. */
> 		usb_ep0_reinit(udev);
> 		ret = hub_port_init(parent_hub, udev, port1, i, &descriptor);     ----> reset devices
> 		if (ret >= 0 || ret == -ENOTCONN || ret == -ENODEV)
> 			break;
> 	}
> ...
> }

Ok, looks like we don't call xhci_sideband_notify_ep_ring_free() in all places we should.

That being said, to solve this crash we need to make xhci_sideband_remove_endpoint() work
in cases where device is being reset or disconnected, and endpoint is being dropped.

Looks like xhci_initialize_ring_info(ep->ring) was added to xhci_sideband_remove_endpoint()
in v8 of the original patch series due to a comment about leaving the endpoint in a messy state.

https://lore.kernel.org/linux-usb/20231011002146.1821-1-quic_wcheng@quicinc.com/

Calling  xhci_initialize_ring_info() does not really clean up anything, it just sets the
software dequeue and enqueue pointers to the beginning of the ring. The xHC hardware
dequeue pointer is still untouched, and the whole ring buffer is still uncleared.

I think we can drop xhci_initialize_ring_info() call completely here.
The class driver still needs to set up and reinit the endpoint properly if it wants to continue
using it after it is removed from sideband usage.

We do want to make sure endpoint is stopped when removing it, but take into account that endpoint
might be stopped, disabled or already dropped by then.

Does the code below solve your crash?

diff --git a/drivers/usb/host/xhci-sideband.c b/drivers/usb/host/xhci-sideband.c
index a85f62a73313..2bd77255032b 100644
--- a/drivers/usb/host/xhci-sideband.c
+++ b/drivers/usb/host/xhci-sideband.c
@@ -210,7 +210,6 @@ xhci_sideband_remove_endpoint(struct xhci_sideband *sb,
  		return -ENODEV;
  
  	__xhci_sideband_remove_endpoint(sb, ep);
-	xhci_initialize_ring_info(ep->ring);
  
  	return 0;
  }
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index a148a1280126..4161c8c7721d 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -2891,16 +2891,25 @@ int xhci_stop_endpoint_sync(struct xhci_hcd *xhci, struct xhci_virt_ep *ep, int
  			    gfp_t gfp_flags)
  {
  	struct xhci_command *command;
+	struct xhci_ep_ctx *ep_ctx;
  	unsigned long flags;
-	int ret;
+	int ret = -ENODEV;
  
  	command = xhci_alloc_command(xhci, true, gfp_flags);
  	if (!command)
  		return -ENOMEM;
  
  	spin_lock_irqsave(&xhci->lock, flags);
-	ret = xhci_queue_stop_endpoint(xhci, command, ep->vdev->slot_id,
-				       ep->ep_index, suspend);
+
+	/* make sure endpoint exists and is running before stopping it */
+	if (ep->ring) {
+		ep_ctx = xhci_get_ep_ctx(xhci, ep->vdev->out_ctx, ep->ep_index);
+		if (GET_EP_CTX_STATE(ep_ctx) == EP_STATE_RUNNING)
+			ret = xhci_queue_stop_endpoint(xhci, command,
+						       ep->vdev->slot_id,
+						       ep->ep_index, suspend);
+	}
+
  	if (ret < 0) {
  		spin_unlock_irqrestore(&xhci->lock, flags);
  		goto out

答复: 答复: Consultation on the issue of digital headphones freezing

[胡连勤]

Hi  Mathias:

> >>>> [192165.107937][    C0] xhci-hcd xhci-hcd.3.auto: Error: Failed finding new dequeue state
> >>>> [192165.107946][    C0] xhci-hcd xhci-hcd.3.auto: Failed to clear cancelled cached URB 000000002d756eab, mark clear anyway
> >>>> [192165.108387][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd              --> 1st  reset
> >>>> [192165.225904][T17454] usb 1-1: device descriptor read/64, error -71
> >>>> [192165.442224][T17454] usb 1-1: Device not responding to setup address.
> >>>> [192165.642107][T17454] usb 1-1: Device not responding to setup address.
> >>>> [192165.845879][T17454] usb 1-1: device not accepting address 2, error -71
> >>>> [192165.846031][T17454] usb 1-1: WARN: invalid context state for evaluate context command.
> >>>> [192165.957927][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd             --> 2st reset
> >>>> [192165.958032][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup context command completion code 0x11.
> >>>> [192165.958040][T17454] usb 1-1: hub failed to enable device, error -22
> >>>> [192165.958165][T17454] usb 1-1: WARN: invalid context state for evaluate context command.
> >>>> [192166.070623][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd            --> 3st reset
> >>>> [192166.070728][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup address command completion code 0x11.
> >>>> [192166.273835][T17454] xhci-hcd xhci-hcd.3.auto: ERROR: unexpected setup address command completion code 0x11.
> >>>> [192166.473788][T17454] usb 1-1: device not accepting address 2, error -22
> >>>> [192166.473943][T17454] usb 1-1: WARN: invalid context state for evaluate context command.
> >>>> [192166.585802][T17454] usb 1-1: reset full-speed USB device number 2 using xhci-hcd           -->  4st reset
> >
> > Upon checking the exception log again, four device reset operations were observed.
> > Analyzing the code flow, after each of the four resets, the `xhci_free_endpoint_ring` function is called,
> > setting `ep->ring` to null.
> >
> > The specific call is as follows:
> >> usb_reset_device
> >> ->usb_reset_and_verify_device
> >> ->->usb_hcd_alloc_bandwidth
> >> ->->->hcd->driver->check_bandwidth(hcd, udev)
> >> ->->->->xhci_check_bandwidth
> >> ->->->->->xhci_free_endpoint_ring
> >
> > void xhci_free_endpoint_ring(struct xhci_hcd *xhci,
> >             struct xhci_virt_device *virt_dev,
> >             unsigned int ep_index)
> > {
> >     xhci_ring_free(xhci, virt_dev->eps[ep_index].ring);
> >     virt_dev->eps[ep_index].ring = NULL;     ---> ep->rings = NULL
> > }
> >
> > static int usb_reset_and_verify_device(struct usb_device *udev)
> > {
> > ...
> >     -> The device will undergo four reset operations here.
> >     for (i = 0; i < PORT_INIT_TRIES; ++i) {
> >             if (hub_port_stop_enumerate(parent_hub, port1, i)) {
> >                     ret = -ENODEV;
> >                     break;
> >             }
> >
> >             /* ep0 maxpacket size may change; let the HCD know about it.
> >              * Other endpoints will be handled by re-enumeration. */
> >             usb_ep0_reinit(udev);
> >             ret = hub_port_init(parent_hub, udev, port1, i, &descriptor);     ----> reset devices
> >             if (ret >= 0 || ret == -ENOTCONN || ret == -ENODEV)
> >                     break;
> >     }
> > ...
> > }
>
> Ok, looks like we don't call xhci_sideband_notify_ep_ring_free() in all places we should.
>
> That being said, to solve this crash we need to make xhci_sideband_remove_endpoint() work
> in cases where device is being reset or disconnected, and endpoint is being dropped.
>
> Looks like xhci_initialize_ring_info(ep->ring) was added to xhci_sideband_remove_endpoint()
> in v8 of the original patch series due to a comment about leaving the endpoint in a messy state.
>
> https://lore.kernel.org/linux-usb/20231011002146.1821-1-
> quic_wcheng%40quicinc.com%2F&data=05%7C02%7Chulianqin%40vivo.com%7C683997639e6e446a330408de4ebdc2d3%7C923e42dc4
> 8d54cbeb5821a797a6412ed%7C0%7C0%7C639034774157625174%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiI
> wLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OS0feNyVaHoHa7TEfXLL%2F42Lvju
> Xt6WOkJTnkMspM7o%3D&reserved=0
>
> Calling  xhci_initialize_ring_info() does not really clean up anything, it just sets the
> software dequeue and enqueue pointers to the beginning of the ring. The xHC hardware
> dequeue pointer is still untouched, and the whole ring buffer is still uncleared.
>
> I think we can drop xhci_initialize_ring_info() call completely here.
> The class driver still needs to set up and reinit the endpoint properly if it wants to continue
> using it after it is removed from sideband usage.
>
> We do want to make sure endpoint is stopped when removing it, but take into account that endpoint
> might be stopped, disabled or already dropped by then.
>
> Does the code below solve your crash?
>
> diff --git a/drivers/usb/host/xhci-sideband.c b/drivers/usb/host/xhci-sideband.c
> index a85f62a73313..2bd77255032b 100644
> --- a/drivers/usb/host/xhci-sideband.c
> +++ b/drivers/usb/host/xhci-sideband.c
> @@ -210,7 +210,6 @@ xhci_sideband_remove_endpoint(struct xhci_sideband *sb,
>               return -ENODEV;
>
>       __xhci_sideband_remove_endpoint(sb, ep);
> -     xhci_initialize_ring_info(ep->ring);
>
>       return 0;
>   }
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index a148a1280126..4161c8c7721d 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -2891,16 +2891,25 @@ int xhci_stop_endpoint_sync(struct xhci_hcd *xhci, struct xhci_virt_ep *ep, int
>                           gfp_t gfp_flags)
>   {
>       struct xhci_command *command;
> +     struct xhci_ep_ctx *ep_ctx;
>       unsigned long flags;
> -     int ret;
> +     int ret = -ENODEV;
>
>       command = xhci_alloc_command(xhci, true, gfp_flags);
>       if (!command)
>               return -ENOMEM;
>
>       spin_lock_irqsave(&xhci->lock, flags);
> -     ret = xhci_queue_stop_endpoint(xhci, command, ep->vdev->slot_id,
> -                                    ep->ep_index, suspend);
> +
> +     /* make sure endpoint exists and is running before stopping it */
> +     if (ep->ring) {
> +             ep_ctx = xhci_get_ep_ctx(xhci, ep->vdev->out_ctx, ep->ep_index);
> +             if (GET_EP_CTX_STATE(ep_ctx) == EP_STATE_RUNNING)
> +                     ret = xhci_queue_stop_endpoint(xhci, command,
> +                                                    ep->vdev->slot_id,
> +                                                    ep->ep_index, suspend);
> +     }
> +
>       if (ret < 0) {
>               spin_unlock_irqrestore(&xhci->lock, flags);
>               goto out

This patch looks like good.
I believe this can solve the crash problem I'm currently experiencing.
I'll do a stress test and see.

Thanks
Lianqin

答复: 答复: Consultation on the issue of digital headphones freezing

[胡连勤]

Hi  Mathias:

> > Ok, looks like we don't call xhci_sideband_notify_ep_ring_free() in all places we should.
> >
> > That being said, to solve this crash we need to make xhci_sideband_remove_endpoint() work
> > in cases where device is being reset or disconnected, and endpoint is being dropped.
> >
> > Looks like xhci_initialize_ring_info(ep->ring) was added to xhci_sideband_remove_endpoint()
> > in v8 of the original patch series due to a comment about leaving the endpoint in a messy state.
> >
> >https://lore.kernel.org/linux-usb/20231011002146.1821-1-quic_wcheng@quicinc.com/> >
> > Calling  xhci_initialize_ring_info() does not really clean up anything, it just sets the
> > software dequeue and enqueue pointers to the beginning of the ring. The xHC hardware
> > dequeue pointer is still untouched, and the whole ring buffer is still uncleared.
> >
> > I think we can drop xhci_initialize_ring_info() call completely here.
> > The class driver still needs to set up and reinit the endpoint properly if it wants to continue
> > using it after it is removed from sideband usage.
> >
> > We do want to make sure endpoint is stopped when removing it, but take into account that endpoint
> > might be stopped, disabled or already dropped by then.
> >
> > Does the code below solve your crash?
> >
> > diff --git a/drivers/usb/host/xhci-sideband.c b/drivers/usb/host/xhci-sideband.c
> > index a85f62a73313..2bd77255032b 100644
> > --- a/drivers/usb/host/xhci-sideband.c
> > +++ b/drivers/usb/host/xhci-sideband.c
> > @@ -210,7 +210,6 @@ xhci_sideband_remove_endpoint(struct xhci_sideband *sb,
> >   		return -ENODEV;
> >
> >   	__xhci_sideband_remove_endpoint(sb, ep);
> > -	xhci_initialize_ring_info(ep->ring);
> >
> >   	return 0;
> >   }
> > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> > index a148a1280126..4161c8c7721d 100644
> > --- a/drivers/usb/host/xhci.c
> > +++ b/drivers/usb/host/xhci.c
> > @@ -2891,16 +2891,25 @@ int xhci_stop_endpoint_sync(struct xhci_hcd *xhci, struct xhci_virt_ep *ep, int
> >   			    gfp_t gfp_flags)
> >   {
> >   	struct xhci_command *command;
> > +	struct xhci_ep_ctx *ep_ctx;
> >   	unsigned long flags;
> > -	int ret;
> > +	int ret = -ENODEV;
> >
> >   	command = xhci_alloc_command(xhci, true, gfp_flags);
> >   	if (!command)
> >   		return -ENOMEM;
> >
> >   	spin_lock_irqsave(&xhci->lock, flags);
> > -	ret = xhci_queue_stop_endpoint(xhci, command, ep->vdev->slot_id,
> > -				       ep->ep_index, suspend);
> > +
> > +	/* make sure endpoint exists and is running before stopping it */
> > +	if (ep->ring) {
> > +		ep_ctx = xhci_get_ep_ctx(xhci, ep->vdev->out_ctx, ep->ep_index);
> > +		if (GET_EP_CTX_STATE(ep_ctx) == EP_STATE_RUNNING)
> > +			ret = xhci_queue_stop_endpoint(xhci, command,
> > +						       ep->vdev->slot_id,
> > +						       ep->ep_index, suspend);
> > +	}
> > +
> >   	if (ret < 0) {
> >   		spin_unlock_irqrestore(&xhci->lock, flags);
> >   		goto out
> 
> This patch looks like good.
> I believe this can solve the crash problem I'm currently experiencing.
> I'll do a stress test and see.

After merging the above patch, the load test results are as follows:
1. The digital headset was connected to a  phone , and a total of three rounds of sleep and wake-up stress tests were conducted, 
     with 3,000 sleep and wake-up cycles in each round.
2. No system crashes occurred.

Thanks
Lianqin

Re: 答复: 答复: Consultation on the issue of digital headphones freezing

[Mathias Nyman]

On 1/14/26 12:27, 胡连勤 wrote:
> Hi  Mathias:
> 
>>> Ok, looks like we don't call xhci_sideband_notify_ep_ring_free() in all places we should.
>>>
>>> That being said, to solve this crash we need to make xhci_sideband_remove_endpoint() work
>>> in cases where device is being reset or disconnected, and endpoint is being dropped.
>>>
>>> Looks like xhci_initialize_ring_info(ep->ring) was added to xhci_sideband_remove_endpoint()
>>> in v8 of the original patch series due to a comment about leaving the endpoint in a messy state.
>>>
>>> https://lore.kernel.org/linux-usb/20231011002146.1821-1-quic_wcheng@quicinc.com/> >
>>> Calling  xhci_initialize_ring_info() does not really clean up anything, it just sets the
>>> software dequeue and enqueue pointers to the beginning of the ring. The xHC hardware
>>> dequeue pointer is still untouched, and the whole ring buffer is still uncleared.
>>>
>>> I think we can drop xhci_initialize_ring_info() call completely here.
>>> The class driver still needs to set up and reinit the endpoint properly if it wants to continue
>>> using it after it is removed from sideband usage.
>>>
>>> We do want to make sure endpoint is stopped when removing it, but take into account that endpoint
>>> might be stopped, disabled or already dropped by then.
>>>
>>> Does the code below solve your crash?
>>>
>>> diff --git a/drivers/usb/host/xhci-sideband.c b/drivers/usb/host/xhci-sideband.c
>>> index a85f62a73313..2bd77255032b 100644
>>> --- a/drivers/usb/host/xhci-sideband.c
>>> +++ b/drivers/usb/host/xhci-sideband.c
>>> @@ -210,7 +210,6 @@ xhci_sideband_remove_endpoint(struct xhci_sideband *sb,
>>>    		return -ENODEV;
>>>
>>>    	__xhci_sideband_remove_endpoint(sb, ep);
>>> -	xhci_initialize_ring_info(ep->ring);
>>>
>>>    	return 0;
>>>    }
>>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
>>> index a148a1280126..4161c8c7721d 100644
>>> --- a/drivers/usb/host/xhci.c
>>> +++ b/drivers/usb/host/xhci.c
>>> @@ -2891,16 +2891,25 @@ int xhci_stop_endpoint_sync(struct xhci_hcd *xhci, struct xhci_virt_ep *ep, int
>>>    			    gfp_t gfp_flags)
>>>    {
>>>    	struct xhci_command *command;
>>> +	struct xhci_ep_ctx *ep_ctx;
>>>    	unsigned long flags;
>>> -	int ret;
>>> +	int ret = -ENODEV;
>>>
>>>    	command = xhci_alloc_command(xhci, true, gfp_flags);
>>>    	if (!command)
>>>    		return -ENOMEM;
>>>
>>>    	spin_lock_irqsave(&xhci->lock, flags);
>>> -	ret = xhci_queue_stop_endpoint(xhci, command, ep->vdev->slot_id,
>>> -				       ep->ep_index, suspend);
>>> +
>>> +	/* make sure endpoint exists and is running before stopping it */
>>> +	if (ep->ring) {
>>> +		ep_ctx = xhci_get_ep_ctx(xhci, ep->vdev->out_ctx, ep->ep_index);
>>> +		if (GET_EP_CTX_STATE(ep_ctx) == EP_STATE_RUNNING)
>>> +			ret = xhci_queue_stop_endpoint(xhci, command,
>>> +						       ep->vdev->slot_id,
>>> +						       ep->ep_index, suspend);
>>> +	}
>>> +
>>>    	if (ret < 0) {
>>>    		spin_unlock_irqrestore(&xhci->lock, flags);
>>>    		goto out
>>
>> This patch looks like good.
>> I believe this can solve the crash problem I'm currently experiencing.
>> I'll do a stress test and see.
> 
> After merging the above patch, the load test results are as follows:
> 1. The digital headset was connected to a  phone , and a total of three rounds of sleep and wake-up stress tests were conducted,
>       with 3,000 sleep and wake-up cycles in each round.
> 2. No system crashes occurred.
> 

Thanks for testing this,
I'll turn it into a proper patch, add Reported-by and Tested-by tags, and send it forward

Thanks
Mathias