linux-kernel - Re: [PATCH] PCI: Mark Nvidia GB10 to avoid bus reset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260115205347.GA881345@bhelgaas>
Date: Thu, 15 Jan 2026 14:53:47 -0600
From: Bjorn Helgaas <helgaas@...nel.org>
To: Terje Bergstrom <tbergstrom@...dia.com>
Cc: Johnny-CC Chang (張晋嘉) <Johnny-CC.Chang@...iatek.com>,
	"lukas@...ner.de" <lukas@...ner.de>,
	Project_Global_Digits_Upstream_Group <Project_Global_Digits_Upstream_Group@...iatek.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
	"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
	"matthias.bgg@...il.com" <matthias.bgg@...il.com>,
	Jason Gunthorpe <jgg@...dia.com>,
	Alex Williamson <alex@...zbot.org>
Subject: Re: [PATCH] PCI: Mark Nvidia GB10 to avoid bus reset

On Thu, Jan 15, 2026 at 12:11:09PM -0800, Terje Bergstrom wrote:
> On 1/14/26 09:28, Bjorn Helgaas wrote:
> 
> > What sort of crash happens?  It's useful if we can include a bread
> > crumb that will help people identify the crash and find a fix.
>
> We observed retraining to lower PCIe lane count and config read
> timeout.  So yes crash is not the best way to describe it.
> 
> > I'm confused about what the topology is.  I first assumed GB10 was
> > a PCIe Endpoint, since Secondary Bus Reset only applies to devices
> > below a bridge, so SBR would be applied to a device by a config
> > write to that bridge.
>
> gb10 is an SoC designed by NVIDIA and Mediatek in collaboration.
> It's not an endpoint, but has its own PCIe controller for connecting
> PCIe peripherals like NVMe drives, NIC, etc.

OK, so you do SBR to some endpoint below a GB10 Root Port, and after
the SBR, the link to the endpoint retrains with a lower lane count and
config reads to the endpoint time out?

I see you're from NVIDIA, so if you're confirming that this is a
hardware erratum (not an issue with the GB10 PCI controller driver),
we should definitely apply this, and I'll wordsmith the commit log and
comment something like this:

  When asserting Secondary Bus Reset to downstream devices via a GB10
  Root Port, the link doesn't retrain correctly.  The link may retrain
  with a lower lane count, and config accesses to downstream devices
  may fail.

Bjorn