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

Paul Menzel
2025-04-05T14:09:05Z

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