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: <20250405114924.7aa7f3a1@foxbook>
Date: Sat, 5 Apr 2025 11:49:24 +0200
From: Michał Pecio <michal.pecio@...il.com>
To: Paul Menzel <pmenzel@...gen.mpg.de>
Cc: 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 Sat, 5 Apr 2025 09:36:03 +0200, Paul Menzel wrote:
> > And the problem appears to be that some USB device gets reset
> > periodically, probably /dev/sda, whatever it is. This reset loop is
> > also visible in your new log today.  
> I guess it’s the SD/eMMC card slot, which I do not use though.

Yep, I just realized that your dmesg shows it clearly:

[   37.517985] usb 4-1.4: new SuperSpeed USB device number 5 using xhci_hcd
[   37.535773] usb 4-1.4: New USB device found, idVendor=058f, idProduct=8468, bcdDevice= 1.00
[   37.535780] usb 4-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   37.535782] usb 4-1.4: Product: Mass Storage Device
[   37.535783] usb 4-1.4: Manufacturer: Generic
[   37.535785] usb 4-1.4: SerialNumber: 058F84688461
[   37.552531] usb-storage 4-1.4:1.0: USB Mass Storage device detected

> > 3. is it reproducible on 6.14, 6.13, ...
>
> As written, from my logs it happened sporadically in the past, but
> since at least commit a2cc6ff5ec8f it happens almost always. I didn’t
> see it with commit 08733088b566, and after that I didn’t use any
> USB-C adapters for three days.

To be exact, I'm wondering if the reset loop itself is a regression, or
business as usual. So simply look for this repeating every few seconds:

[   74.898485] usb 4-1.4: reset SuperSpeed USB device number 5 using xhci_hcd

Relevant commits in your range are:

0c74d232578b xhci: Avoid queuing redundant Stop Endpoint command for stalled endpoint
860f5d0d3594 xhci: Prevent early endpoint restart when handling STALL errors.

Reverting 0c74d232578b will remove the warning, but this means that
860f5d0d3594 isn't having the intended effect. Not sure  if reverting
the latter will solve the reset loop or if it was always there. And
these commits look alright, so IDK what's going wrong.

I could send a debug patch which might clear some things up.

> PS: Hints on how to try to reproduce this in QEMU would be welcome. 
> (Passing the controller and device to the VM.)

If you need help setting up PCI passthrough, I'm afraid I can't help.
As for reproduction, simply booting a buggy kernel should give those
repeating resets and xHCI warnings if you are lucky.