From: Lukas Wunner <lukas@wunner.de>
To: Rick Warner <rick@microway.com>
Cc: bhelgaas@google.com, ilpo.jarvinen@linux.intel.com,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
rhoughton@microway.com, ssingh@microway.com
Subject: Re: [PATCH] PCI: Fix Intel Xeon 6 x2 quirk collateral damage on adjacent x4 endpoints
Date: Wed, 29 Jul 2026 20:43:29 +0200 [thread overview]
Message-ID: <ampJ0dIhz1J-a0sk@wunner.de> (raw)
In-Reply-To: <20260729144508.12337-1-rick@microway.com>
On Wed, Jul 29, 2026 at 10:45:08AM -0400, Rick Warner wrote:
> commit a22250fe933d ("PCI: Add Extended Tag + MRRS quirk for Xeon 6")
> introduced a traffic mitigation quirk for Intel Xeon 6 root ports that
> negotiate down to an x2 lane width. However, that patch manipulated host
> bridge properties globally via 'bridge->no_ext_tags = 1' and by hooking
> 'bridge->enable_device'.
>
> Because multiple unrelated root ports can reside under the exact same
> global pci_host_bridge domain structure, this overly aggressive mitigation
> causes severe collateral damage. When a low-speed or bifurcated secondary
> device (such as an onboard ASMedia SATA controller or BMC graphics link)
> matches the x2 condition, the kernel strips away Extended Tags and forces
> a 128B MRRS restriction across that ENTIRE host bridge. This instantly
> breaks or starves adjacent high-performance, unrelated x4 endpoints
> (such as NVMe drives), resulting in controller timeouts, initialization
> failures, and missing drives at boot.
>
> Fix this by refactoring the quirk logic to be completely per-device and
> downstream-isolated. Remove the broad host bridge structure assignments
> entirely. Instead, convert the hook to an explicit
> 'DECLARE_PCI_FIXUP_FINAL' sweep. When an x2 bifurcated root port is
> discovered, leverage 'pci_walk_bus()' to step down only that specific root
> port's subordinate tree, manually clearing 'PCI_EXP_DEVCTL_EXT_TAG' and
> 'PCI_EXP_DEVCTL_READRQ' directly in the endpoint Device Control
> configuration registers.
One problem I see with this approach is that it won't work for hotplugged
devices below a bifurcated Root Port: You're only adjusting Extended Tags
and MRRS once on enumeration of the Root Ports, leaving devices that are
hotplugged later at incorrect settings.
But perhaps you could simply amend limit_mrrs_to_128() to walk up to the
Root Port, check whether it is bifurcated, and bail out if it's not?
Thanks,
Lukas
next prev parent reply other threads:[~2026-07-29 18:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 14:45 Rick Warner
2026-07-29 18:43 ` Lukas Wunner [this message]
2026-08-04 13:55 ` Rick Warner
2026-08-04 17:10 ` 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=ampJ0dIhz1J-a0sk@wunner.de \
--to=lukas@wunner.de \
--cc=bhelgaas@google.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rhoughton@microway.com \
--cc=rick@microway.com \
--cc=ssingh@microway.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 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®