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.
prev parent 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®