mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Alexander Gruhlke <gruhlke@mailbox.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Lukas Wunner <lukas@wunner.de>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Alex Williamson <alex@shazbot.org>,
	Hui Wang <hui.wang@canonical.com>, Linux-Fan <info@masysma.net>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	regressions@lists.linux.dev
Subject: Re: [PATCH v3 0/2] PCI: Wait after FLR for devices that don't honor Immediate Readiness
Date: Thu, 15 Oct 2026 11:11:43 -0500	[thread overview]
Message-ID: <20261015161143.GA1772020@bhelgaas> (raw)
In-Reply-To: <20261012222331.GA1411603@bhelgaas>

On Mon, Oct 12, 2026 at 05:23:31PM -0500, Bjorn Helgaas wrote:
> On Sun, Oct 11, 2026 at 09:01:43PM +0200, Alexander Gruhlke wrote:
> > Since v7.2, VFIO passthrough of a Samsung 990 PRO NVMe [144d:a80c] fails
> > on the second VM start, and the device is inaccessible until reboot.  The
> > drive advertises Immediate Readiness but returns ~0 for up to 7 ms after
> > FLR, so since 10baa9b4df40 ("PCI: Drop unnecessary retries when restoring
> > BARs") the config restore after FLR is lost.
> > 
> > Patch 1 ignores Immediate Readiness on that drive.  Firmware 8B2QJXD7
> > fixes it, but the Revision ID and Subsystem ID don't change, so the
> > quirk can't tell firmware versions apart.  A 990 EVO Plus [144d:a80d]
> > reports the same errors [1], but it isn't confirmed to advertise
> > Immediate Readiness, so it's not included.
> > 
> > Patch 2 is independent and keeps pci_dev_wait() from treating ~0 as
> > ready with RRS Software Visibility, which also affects the Intel
> > [8086:0a54] in the open d591f6804e7e regression.  Hui, Linux-Fan: testing
> > patch 2 on that drive would be appreciated.
> > 
> > Tested on v7.2.9 (Ryzen 9 7950X, X670E): with patch 1 and drive firmware
> > 1B2QJXD7, three VM starts in a row work, and every FLR reports "ready
> > 0ms after FLR".  With firmware 8B2QJXD7, plain v7.2.9 works.
> > 
> > Patch 2 is only tested for regressions, as the drive no longer shows the
> > problem: below a Root Port with RRS SV, three VM starts work and every
> > FLR reports "ready 0ms after FLR".  The VF path is untested with the
> > patch, but on another machine, an X550 VF below a Root Port with RRS SV
> > reads ~0 from the Vendor ID and valid data from the Command register
> > 100 ms after FLR.  v1's variant, which read the Command register, was
> > tested against the old firmware, and the drive's Vendor ID read ~0
> > while it wasn't ready.  Applies to pci/next.
> > 
> > Changes since v2:
> > - Patch 1: add Lukas's Reviewed-by
> > - Patch 2: read the Command register on VFs whose Vendor ID reads ~0
> >   instead of treating them as ready (Lukas, sashiko)
> > 
> > v2: https://lore.kernel.org/r/20261011163249.18479-1-gruhlke@mailbox.org
> > v1: https://lore.kernel.org/r/20261010160529.27974-1-gruhlke@mailbox.org
> > 
> > [1] https://bbs.archlinux.org/viewtopic.php?id=314833
> > 
> > Alexander Gruhlke (2):
> >   PCI: Ignore Immediate Readiness on Samsung 990 PRO NVMe
> >   PCI: Don't treat ~0 as ready in pci_dev_wait() with RRS SV
> > 
> >  drivers/pci/pci.c    | 14 ++++++++++----
> >  drivers/pci/quirks.c | 11 +++++++++++
> >  2 files changed, 21 insertions(+), 4 deletions(-)
> 
> Applied to pci/reset for v7.4, thank you!

On second thought, I think at least the first should be in v7.3
because it fixes a v7.2 regression.  The other regression dates to
v6.12, but it seems worth keeping the fixes together.

I moved them both to pci/for-linus for v7.3.

      reply	other threads:[~2026-10-15 16:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-11 19:01 Alexander Gruhlke
2026-10-11 19:01 ` [PATCH v3 1/2] PCI: Ignore Immediate Readiness on Samsung 990 PRO NVMe Alexander Gruhlke
2026-10-11 19:01 ` [PATCH v3 2/2] PCI: Don't treat ~0 as ready in pci_dev_wait() with RRS SV Alexander Gruhlke
2026-10-12 10:11   ` Lukas Wunner
2026-10-12 22:23 ` [PATCH v3 0/2] PCI: Wait after FLR for devices that don't honor Immediate Readiness Bjorn Helgaas
2026-10-15 16:11   ` Bjorn Helgaas [this message]

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=20261015161143.GA1772020@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=alex@shazbot.org \
    --cc=bhelgaas@google.com \
    --cc=gruhlke@mailbox.org \
    --cc=hui.wang@canonical.com \
    --cc=info@masysma.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=rafael@kernel.org \
    --cc=regressions@lists.linux.dev \
    /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

all inboxes | Powered by JetHome®