From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Mario Limonciello <mario.limonciello@amd.com>
Cc: "Maciej Grochowski" <Maciej.Grochowski@sony.com>,
"Nikolas Joshua Britton" <nbritton@exabit.io>,
"Geramy Loveless" <gloveless@jqluv.com>,
"Eric Auger" <eauger@redhat.com>,
"Alexey Fomenko" <alexey.fomenko@intel.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
linux-pci@vger.kernel.org,
"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Thomas Gleixner" <tglx@kernel.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
LKML <linux-kernel@vger.kernel.org>,
"Bradley Morgan" <brads@mainlining.org>
Subject: Re: [PATCH v3 8/8] PCI/quirks: Avoid certain address on Genoa systems
Date: Tue, 13 Oct 2026 20:26:44 +0300 (EEST) [thread overview]
Message-ID: <01b571a9-06ae-076e-95f4-0851a90d0c44@linux.intel.com> (raw)
In-Reply-To: <ed19c161-9703-4967-997a-b9054e92a216@amd.com>
[-- Attachment #1: Type: text/plain, Size: 5581 bytes --]
On Tue, 13 Oct 2026, Mario Limonciello wrote:
> On 10/13/26 12:00, Mario Limonciello wrote:
> > On 10/13/26 08:09, Ilpo Järvinen wrote:
> > > While testing the resource placement changes, tests hit a case where
> > > igb fails to probe when BAR 0 is placed at 0x9c000000:
> > >
> > > 90000000-9cffffff : PCI Bus 0000:a0
> > > - 90000000-902fffff : PCI Bus 0000:a1
> > > - 90000000-900fffff : 0000:a1:00.0
> > > - 90000000-900fffff : igb
> > > - 90100000-901fffff : 0000:a1:00.0
> > > - 90200000-90203fff : 0000:a1:00.0
> > > - 90200000-90203fff : igb
> > > + 9be00000-9c0fffff : PCI Bus 0000:a1
> > > + 9be00000-9befffff : 0000:a1:00.0
> > > + 9bf00000-9bf03fff : 0000:a1:00.0
> > > + 9c000000-9c0fffff : 0000:a1:00.0
> > > 9c100000-9c17ffff : amd_iommu
> > > 9c180000-9c1803ff : IOAPIC 8
> > >
> > > - Region 0: Memory at 90000000 (32-bit, non-prefetchable)
> > > [size=1M]
> > > - Region 3: Memory at 90200000 (32-bit, non-prefetchable)
> > > [size=16K]
> > > - Expansion ROM at 90100000 [disabled] [size=1M]
> > > + Region 0: Memory at 9c000000 (32-bit, non-prefetchable)
> > > [size=1M]
> > > + Region 3: Memory at 9bf00000 (32-bit, non-prefetchable)
> > > [size=16K]
> > > + Expansion ROM at 9be00000 [disabled] [size=1M]
> > >
> > > igb 0000:a1:00.0 0000:a1:00.0 (uninitialized): PCIe link lost
> > > ------------[ cut here ]------------
> > > igb: Failed to read reg 0x18!
> > > WARNING: drivers/net/ethernet/intel/igb/igb_main.c:724 at
> > > igb_rd32.cold+0x3c/0x4f [igb], CPU#32: kworker/32:1/706
> > > ...
> > > igb_get_invariants_82575+0xff/0xf00 [igb]
> > > igb_probe+0x3c8/0x1190 [igb]
> > > local_pci_probe+0x3b/0x80
> > >
> > > It turns out there is a 64kB iomem black hole at 9c000000 that returns
> > > ~0 and this is where igb's BAR 0 resides. If another BAR of the same
> > > card is placed into that address, it is similarly black holed.
> > >
> > > Mark the problematic 64kB range reserved using a quirk bound to the
> > > bridge found in the problematic system.
> > >
> > > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222074
> > > Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
> > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > > ---
> > > Cc: Borislav Petkov <bp@alien8.de>
> > >
> > > As an alternative to this, I've also tested reverting the commit
> > > 07eab0901ede ("efi/x86: Remove EfiMemoryMappedIO from E820 map") and
> > > that also resolves the issue by retaining "9c000000-9cffffff : Reserved"
> > > entry in the resource tree.
> > >
> > > ---
> > > arch/x86/pci/fixup.c | 36 ++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 36 insertions(+)
> > >
> > > diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> > > index b301c6c8df75..cc463bf492b6 100644
> > > --- a/arch/x86/pci/fixup.c
> > > +++ b/arch/x86/pci/fixup.c
> > > @@ -822,6 +822,42 @@ DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x1571,
> > > pci_amd_enable_64bit_bar);
> > > DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x15b1,
> > > pci_amd_enable_64bit_bar);
> > > DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x1601,
> > > pci_amd_enable_64bit_bar);
> > > +/*
> > > + * TODO: Remove when/if root cause is found.
> > > + *
> > > + * Genoa appears to have a 64kB iomem black hole starting at 0x9c000000
> > > + * address for which all reads return ~0 blocking an overlapping BAR from
> > > + * working.
> > > + *
> > > + * Work around the problem by reserving the space prior to making any
> > > iomem
> > > + * allocations that could overlap with the black hole.
> > > + */
> > > +static struct resource genoa_black_hole =
> > > DEFINE_RES_MEM_NAMED(0x9c000000,
> > > + SZ_64K,
> > > + "reserved");
> > > +
> > > +static void genoa_iomem_black_hole(struct pci_dev *dev)
> > > +{
> > > + struct resource *r;
> > > +
> > > + pci_bus_for_each_resource(dev->bus, r) {
> > > + if (!r || !r->flags || !resource_assigned(r))
> > > + continue;
> > > +
> > > + if (!__resource_contains_unbound(r, &genoa_black_hole))
> > > + continue;
> > > +
> > > + if (resource_assigned(&genoa_black_hole))
> > > + pci_dbg(dev, "iomem black hole workaround already
> > > applied\n");
> > > + else if (!insert_resource(r, &genoa_black_hole))
> > > + pci_info(dev, "iomem black hole workaround enabled\n");
> > > + else
> > > + pci_dbg(dev, "iomem black hole workaround add failed\n");
> > > + return;
> > > + }
> > > +}
> > > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AMD, 0x14ab,
> > > genoa_iomem_black_hole);
> > > +
> > > #define RS690_LOWER_TOP_OF_DRAM2 0x30
> > > #define RS690_LOWER_TOP_OF_DRAM2_VALID 0x1
> > > #define RS690_UPPER_TOP_OF_DRAM2 0x31
> >
> > I guess it's good we know the root cause is 07eab0901ede. If we're going
> > down the path of making holes in that we may well put the hole in
> > efi_remove_e820_mmio() like this (attached).
>
> I don't really like that though. If Genoa is affected I would expect plenty
> of other machines are too they just haven't been found yet.
That's what I'm worried as well. My own testing can only cover very little
ground here.
> Can we roll back 07eab0901ede and add quirks for the busted machines instead?
--
i.
next prev parent reply other threads:[~2026-10-13 17:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 13:09 [PATCH v3 0/8] PCI: Resource placement algorithm fixes Ilpo Järvinen
2026-10-13 13:09 ` [PATCH v3 1/8] resource: Mark free space assigned Ilpo Järvinen
2026-10-13 13:09 ` [PATCH v3 2/8] PCI/parisc: Clean up resource debug print & use dynamic debug Ilpo Järvinen
2026-10-13 13:09 ` [PATCH v3 3/8] PCI: Honor alignment overrides Ilpo Järvinen
2026-10-13 14:08 ` Rodrigo Vivi
2026-10-13 13:09 ` [PATCH v3 4/8] PCI: Fix nesting windows with remainder at the left edge Ilpo Järvinen
2026-10-13 13:09 ` [PATCH v3 5/8] linux/log2.h: Add 64-bit roundup/down_pow_of_two64() variants Ilpo Järvinen
2026-10-13 13:09 ` [PATCH v3 6/8] PCI: Place resources to either edge of the window Ilpo Järvinen
2026-10-13 13:09 ` [PATCH v3 7/8] PCI: Fix composite resource sizing Ilpo Järvinen
2026-10-13 13:09 ` [PATCH v3 8/8] PCI/quirks: Avoid certain address on Genoa systems Ilpo Järvinen
2026-10-13 17:00 ` Mario Limonciello
2026-10-13 17:03 ` Mario Limonciello
2026-10-13 17:26 ` Ilpo Järvinen [this message]
2026-10-13 18:59 ` Mario Limonciello
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=01b571a9-06ae-076e-95f4-0851a90d0c44@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=Maciej.Grochowski@sony.com \
--cc=alexey.fomenko@intel.com \
--cc=bhelgaas@google.com \
--cc=bp@alien8.de \
--cc=brads@mainlining.org \
--cc=dave.hansen@linux.intel.com \
--cc=eauger@redhat.com \
--cc=gloveless@jqluv.com \
--cc=hpa@zytor.com \
--cc=kw@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mario.limonciello@amd.com \
--cc=mingo@redhat.com \
--cc=nbritton@exabit.io \
--cc=robh@kernel.org \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
/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®