linux-kernel - Re: xhci: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <14197657-0a0f-45a8-ac36-dd37b16a1565@rowland.harvard.edu>
Date: Sun, 6 Apr 2025 15:26:41 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Michał Pecio <michal.pecio@...il.com>
Cc: Paul Menzel <pmenzel@...gen.mpg.de>,
	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	Mathias Nyman <mathias.nyman@...el.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-usb@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: xhci: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep
 state.

On Sun, Apr 06, 2025 at 05:50:32PM +0200, Michał Pecio wrote:
> On Sun, 6 Apr 2025 09:50:08 +0200, Michał Pecio wrote:
> > What I found suspicious is that there is also endpoint_disable() and
> > I'm not sure where it comes from. Looking at core code, it seems to
> > often be followed by endpoint_reset(), but the log doesn't show that.
> 
> There might be something to it. I went through my collection of card
> readers and found a reproducible case where endpoint_reset() is called
> with NULL host_ep->hcpriv and it bails out without even an xhci_dbg().
> 
> Reloading ums-realtek with the reader already connected and no card:
> 
> [ 6kwi 17:30] usbcore: deregistering interface driver ums-realtek
> [  +0,679251] ums-realtek 14-1:1.0: USB Mass Storage device detected
> [  +0,161730] scsi host9: usb-storage 14-1:1.0
> [  +0,000193] usbcore: registered new interface driver ums-realtek
> [  +1,018198] scsi 9:0:0:0: Direct-Access     Generic- Multi-Card       1.00 PQ: 0 ANSI: 0 CCS
> [  +0,000241] sd 9:0:0:0: Attached scsi generic sg1 type 0
> [  +0,001182] sd 9:0:0:0: [sdb] Media removed, stopped polling
> [  +0,000517] sd 9:0:0:0: [sdb] Attached SCSI removable disk
> [  +0,000952] usb 14-1: XXX ep 4 is now EP_STALLED
> [  +0,000907] xhci_hcd 0000:0a:00.0: xhci_endpoint_reset ep 4 udev 0000000000000000 slot_id -1 vdev ffffffffffffffff
> [  +0,000030] usb 14-1: XXX URB ffff88811af85f00 queued before clearing halt
> [ +30,400178] xhci_hcd 0000:0a:00.0: xhci_endpoint_reset ep 0 udev 0000000000000000 slot_id -1 vdev ffffffffffffffff
> [  +0,112403] usb 14-1: reset high-speed USB device number 3 using xhci_hcd
> [  +0,124145] xhci_hcd 0000:0a:00.0: xhci_endpoint_reset ep 0 udev 0000000000000000 slot_id -1 vdev ffffffffffffffff
> [  +0,027202] usb 14-1: XXX ep 4 still EP_STALLED on init, clearing
> [  +0,000995] xhci_hcd 0000:0a:00.0: xhci_endpoint_reset ep 1 udev 0000000000000000 slot_id -1 vdev ffffffffffffffff
> [  +0,000013] xhci_hcd 0000:0a:00.0: xhci_endpoint_reset ep 4 udev 0000000000000000 slot_id -1 vdev ffffffffffffffff
> 
> Not sure what's happening, but at least it shows that EP_STALLED can
> still be set when the endpoint is re-enabled and my patch clears it.

I'd guess that you're seeing the result of the

		usb_disable_interface(udev, intf, true);

call in usb_reset_and_verify_device().  This call is made following the 
actual reset, as part of the procedure for putting everything back to the 
way it was before the reset.

Alan Stern