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: <20a4400e-a175-47e2-91ce-a6b475a14b33@molgen.mpg.de>
Date: Sat, 5 Apr 2025 16:08:24 +0200
From: Paul Menzel <pmenzel@...gen.mpg.de>
To: Michał Pecio <michal.pecio@...il.com>
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.

Dear Michał,


Thank you for your reply.

Am 05.04.25 um 11:49 schrieb Michał Pecio:
> 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.

That’d be awesome.

>> 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.

After this morning I wasn’t able to reproduce it by un-/replugging. 
Maybe I am lucky to find a reproducer (reboot needed?).


Kind regards,

Paul