public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: "Michał Pecio" <michal.pecio@gmail.com>
To: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Mathias Nyman <mathias.nyman@linux.intel.com>,
	Mathias Nyman <mathias.nyman@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: xhci: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
Date: Sat, 5 Apr 2025 11:49:24 +0200	[thread overview]
Message-ID: <20250405114924.7aa7f3a1@foxbook> (raw)
In-Reply-To: <7ec5ba1d-1de7-409d-882c-2efab4922ed4@molgen.mpg.de>

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.

  reply	other threads:[~2025-04-05  9:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-03 18:02 xhci: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state Paul Menzel
2025-04-04 14:26 ` Mathias Nyman
2025-04-04 14:29   ` Paul Menzel
2025-04-05  5:23   ` Paul Menzel
2025-04-05 22:23     ` Michał Pecio
2025-04-06  2:40       ` Alan Stern
2025-04-06  7:50         ` Michał Pecio
2025-04-06 15:50           ` Michał Pecio
2025-04-06 19:26             ` Alan Stern
2025-04-07  5:49               ` Michał Pecio
2025-04-07 16:11                 ` Alan Stern
2025-04-08 10:18                   ` [PATCH RFC RFT] usb: hcd: Add a usb_device argument to hc_driver.endpoint_reset() Michał Pecio
2025-04-08 13:55                     ` Mathias Nyman
2025-04-09 10:18                       ` Michał Pecio
2025-04-09 14:13                         ` Alan Stern
2025-04-15  8:38                           ` Michał Pecio
2025-04-07  7:15         ` xhci: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state Mathias Nyman
2025-04-05  6:43 ` Michał Pecio
2025-04-05  7:36   ` Paul Menzel
2025-04-05  9:49     ` Michał Pecio [this message]
2025-04-05 14:08       ` Paul Menzel
2025-04-05 18:13         ` Paul Menzel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250405114924.7aa7f3a1@foxbook \
    --to=michal.pecio@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=mathias.nyman@linux.intel.com \
    --cc=pmenzel@molgen.mpg.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox