All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Hui Wang <hui.wang@canonical.com>,
	Nirmal Patel <nirmal.patel@linux.intel.com>,
	Jonathan Derrick <jonathan.derrick@linux.dev>
Cc: linux-pci@vger.kernel.org, bhelgaas@google.com,
	raphael.norwitz@nutanix.com, alay.shah@nutanix.com,
	suresh.gumpula@nutanix.com, ilpo.jarvinen@linux.intel.com,
	"Chaitanya Kumar Borah" <chaitanya.kumar.borah@intel.com>,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>
Subject: Re: [PATCH] PCI: Disable RRS polling for Intel SSDPE2KX020T8 nvme
Date: Wed, 8 Oct 2025 11:53:45 -0500	[thread overview]
Message-ID: <20251008165345.GA627277@bhelgaas> (raw)
In-Reply-To: <20250821163936.GA681451@bhelgaas>

Nirmal, Jonathan, can you confirm that when RRS SV is enabled for VMD
Root Ports, we should actually see the 0x0001 value when a device
downstream of VMD responds with RRS?  From the log below, it appears
that we actually get 0xffffffff when reading Device ID after a reset.

On Thu, Aug 21, 2025 at 11:39:36AM -0500, Bjorn Helgaas wrote:
> On Thu, Jul 03, 2025 at 08:05:05AM +0800, Hui Wang wrote:
> > On 7/2/25 17:43, Hui Wang wrote:
> > > On 7/2/25 07:23, Bjorn Helgaas wrote:
> ...

> > > > Thank you!  It seems like we get 0xffffffff (probably PCIe error) for
> > > > a long time after we think the device should be able to respond with
> > > > RRS.
> > > > 
> > > > I always thought the spec required that after the delays, a device
> > > > should respond with RRS if it's not ready, but now I guess I'm not
> > > > 100% sure.  Maybe it's allowed to just do nothing, which would lead to
> > > > the Root Port timing out and logging an Unsupported Request error.
> > > > 
> > > > Can I trouble you to try the patch below?  I think we might have to
> > > > start explicitly checking for that error.  That probably would require
> > > > some setup to enable the error, check for it, and clear it.  I hacked
> > > > in some of that here, but ultimately some of it should go elsewhere.
> ...

The patch is here:
https://lore.kernel.org/r/20250701232341.GA1859056@bhelgaas
and the log with that patch is here:

> > This is the testing result and log.
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2111521/comments/65

> We're waiting for 01:00.0, and we're seeing the poll message for about
> 375 ms:

[   10.177356] pci 10000:00:02.0: PCI bridge to [bus 01]
[   10.182278] pci 10000:01:00.0: [8086:0a54] type 00 class 0x010802 PCIe Endpoint
[   10.195247] pci 10000:00:02.0: pci_reset_secondary_bus: PCI_BRIDGE_CTL_BUS_RESET deasserted
[   10.195464] pci 10000:00:02.0: waiting 100 ms for downstream link, after activation
[   10.195467] pci 10000:00:02.0: pcie_wait_for_link_delay: active 1 delay 100 link_active_reporting 1
[   10.229269] pci 10000:00:02.0: pcie_wait_for_link_status: LNKSTA 0xb043
[   10.334784] pci 10000:00:02.0: pcie_wait_for_link_delay: waited 100ms

>   [   10.334786] pci 10000:01:00.0: pci_dev_wait: VF- bus reset timeout 59900
>   [   10.334792] pci 10000:00:02.0: pci_dev_wait: read 0xffffffff DEVSTA 0x0000
>   ...
>   [   10.708367] pci 10000:00:02.0: pci_dev_wait: read 0xffffffff DEVSTA 0x0000
> 
> The 00:02.0 Root Port has RRS SV enabled, but the config reads of the
> 01:00.0 Vendor ID did not return the RRS value (0x0001).  Instead,
> they returned 0xffffffff, which typically means an error on PCIe.

  reply	other threads:[~2025-10-08 16:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-11 10:14 [PATCH] PCI: Disable RRS polling for Intel SSDPE2KX020T8 nvme Hui Wang
2025-06-12 16:48 ` Bjorn Helgaas
2025-06-16 11:55   ` Hui Wang
2025-06-16 13:38     ` Hui Wang
2025-06-17 20:12       ` Bjorn Helgaas
2025-06-23 22:58         ` Bjorn Helgaas
2025-06-24  0:58           ` Hui Wang
2025-07-01 23:23             ` Bjorn Helgaas
2025-07-02  9:43               ` Hui Wang
2025-07-03  0:05                 ` Hui Wang
2025-08-08  2:23                   ` Hui Wang
2025-08-11 23:04                     ` Bjorn Helgaas
2025-09-11  9:24                       ` Vitaly Chikunov
2025-08-21 16:39                   ` Bjorn Helgaas
2025-10-08 16:53                     ` Bjorn Helgaas [this message]
2026-01-06 13:30                       ` Linux regression tracking (Thorsten Leemhuis)
2026-02-08 21:30                         ` Linux-Fan
2026-02-09  9:37                           ` Thorsten Leemhuis
2026-02-09 16:34                           ` Bjorn Helgaas
2026-02-13 19:37                             ` Linux-Fan
2025-08-14 15:55 ` Bjorn Helgaas

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=20251008165345.GA627277@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=alay.shah@nutanix.com \
    --cc=bhelgaas@google.com \
    --cc=chaitanya.kumar.borah@intel.com \
    --cc=hui.wang@canonical.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=jonathan.derrick@linux.dev \
    --cc=linux-pci@vger.kernel.org \
    --cc=nirmal.patel@linux.intel.com \
    --cc=raphael.norwitz@nutanix.com \
    --cc=suresh.gumpula@nutanix.com \
    --cc=ville.syrjala@linux.intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.