From: Alex Williamson <alwilliamson@nvidia.com>
To: mark-ship-it <williamwoodstock79@gmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PCI: Avoid bus reset on NVIDIA GB202 and GB203 GPUs
Date: Mon, 19 Oct 2026 14:10:53 -0600 [thread overview]
Message-ID: <20261019141053.7b2d8e23@nvidia.com> (raw)
In-Reply-To: <20261018201727.96924-1-williamwoodstock79@gmail.com>
On Sun, 18 Oct 2026 13:17:27 -0700
mark-ship-it <williamwoodstock79@gmail.com> wrote:
> NVIDIA GB202 (GeForce RTX 5090, RTX PRO 6000) and GB203 (GeForce RTX
> 5080/5070 Ti/5070) GPUs train their link at x16 at boot, but after a
> Secondary Bus Reset the link comes back at x8 and stays there until the
> next cold boot.
>
> The GPU's HD Audio function (e.g. 10de:22e9 on GB203) has no reset method,
> so when both functions are assigned to a VM, vfio-pci falls back to a bus
> reset at VM start and again at release, and the GPU then runs at half
> width. Assigning only function 0 avoids the bus reset because the GPU
> itself supports FLR, which is why the problem is usually reported as
> "passing the audio function breaks x16".
>
> Observed on an RTX 5080 (10de:2c02) behind an AMD Root Port, kernel
> 7.0.14, Proxmox VE host with a Windows 11 Pro guest:
>
> boot: LnkSta: Speed 32GT/s, Width x16
> echo 1 > /sys/bus/pci/devices/<root port>/reset_subordinate
> LnkSta: Speed 32GT/s, Width x8 (downgraded)
>
> No VM is involved in that reproduction. Stepping the link speed through
> bwctrl (Gen5 -> Gen4 -> Gen5) retrains the link and the speed follows,
> but the width stays at x8. With a VM started frozen (-S), the link is
> already at x8 before any guest code has run, so the guest driver is not
> involved.
>
> With this patch applied, reset_method for the GPU is "flr" only, both
> functions can be assigned, and the link stays at x16 Gen5 across VM
> start, shutdown and restart, with the Windows guest driver working.
>
> The same symptom has been reported with an RTX 5090 (10de:2b85) on an
> AMD X870E board, where passing only function 0 was the only thing that
> kept x16.
>
> Link: https://forum.proxmox.com/threads/asus-x870e-pcie-x8-bifurcation-bug-with-rtx-5090-vfio-passthrough.178461/
>
> Signed-off-by: mark-ship-it <williamwoodstock79@gmail.com>
> ---
> drivers/pci/quirks.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 1aa87a3ef..a4adcc3e7 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3769,10 +3769,17 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x22D0, quirk_no_bus_reset);
> /*
> * Some NVIDIA GPU devices do not work with bus reset, SBR needs to be
> * prevented for those affected devices.
> + *
> + * GB202 (0x2b80-0x2bbf) and GB203 (0x2c00-0x2c7f) GPUs train at x16 at
> + * boot, but after a Secondary Bus Reset the link comes back at x8 and
> + * stays there until the next cold boot; a link retrain restores the speed
> + * but not the width. Function Level Reset does not have this problem.
> */
> static void quirk_nvidia_no_bus_reset(struct pci_dev *dev)
> {
> - if ((dev->device & 0xffc0) == 0x2340)
> + if ((dev->device & 0xffc0) == 0x2340 ||
> + (dev->device & 0xffc0) == 0x2b80 ||
> + (dev->device & 0xff80) == 0x2c00)
> quirk_no_bus_reset(dev);
> }
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
What's your RTX 5080 vBIOS version and system information? Is it the
same Asus X870E as the other 5090 reports or something else?
Is the issue still present on kernel v7.3?
Disabling bus reset entirely should be a last resort, it has
implications for device isolation when no other reset mechanism exists.
Thanks,
Alex
prev parent reply other threads:[~2026-10-19 20:11 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-18 20:17 [PATCH] PCI: Avoid bus reset on NVIDIA GB202 and GB203 GPUs mark-ship-it
2026-10-19 20:10 ` Alex Williamson [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=20261019141053.7b2d8e23@nvidia.com \
--to=alwilliamson@nvidia.com \
--cc=bhelgaas@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=williamwoodstock79@gmail.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