Linux PCI subsystem development
 help / color / mirror / Atom feed
From: "jodeliukas@gmail.com" <jodeliukas@gmail.com>
To: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: HTML message rejected: [REGRESSION] PCI: AMDIF031 ACPI resource conflicts cause bridge window allocation failure on X870E in
Date: Sat, 9 May 2026 18:32:56 +0300	[thread overview]
Message-ID: <7e9825d8-3180-4787-ab7a-456446b0cbb8@gmail.com> (raw)
In-Reply-To: <1778340596-26078-mlmmj-08aae49b@vger.kernel.org>

# [REGRESSION] PCI: AMDIF031 ACPI resource conflict at host bridge 
window prevents PCIe device probe on X870E AI TOP / 6.18

## Summary

Starting with kernel 6.18, an ACPI device `AMDIF031` (declared in vendor 
SSDT
with a `Memory32Fixed` `_CRS` resource at an address falling inside a PCIe
bridge window) causes that bridge window to fail `pci_claim_resource()` with
"address conflict". The conflict cascades to all downstream bridges and
endpoints, leaving multiple devices without assigned BARs.

The same conflict is logged on kernel 6.12 (LTS) but is non-fatal there:
all devices receive resources and operate normally. On 6.18 the conflict is
fatal and a PCIe device behind the affected bridge fails to probe with
`-EIO (-5)`.

This appears to be a regression in the PCI resource allocator's handling of
ACPI-declared MMIO resources that overlap host bridge windows between 6.12
and 6.18.

## System

- Motherboard: Gigabyte X870E AORUS XTREME AI TOP, BIOS F12b (latest)
- CPU: AMD Ryzen 9 9950X3D (Granite Ridge, family 19h)
- Affected PCIe device: Aquantia AQC113C (10GbE), driver `atlantic`
   (one of two identical AQC113C controllers fails to probe; the other 
works)
- Distribution: Gentoo Linux
- Working kernel: 6.12.86 (gentoo-sources)
- Broken kernel: 6.18.28 (gentoo-sources)

## Reproduction

Boot the system on 6.18.28 with default kernel command line. The on-board
secondary AQC113C fails to probe.

`lspci` placement:

```
0a:06.0 PCI bridge: AMD 600 Series Chipset PCIe Switch Downstream Port
10:00.0 Ethernet controller: Aquantia AQC113C [Marvell Scalable mGig]
```

(Bus numbers shift slightly depending on whether the discrete GPU is 
installed;
the failure pattern is identical.)

## Symptoms (kernel 6.18.28)

```
pci 0000:0b:06.0:   bridge window [mem 0xdc400000-0xdc8fffff]
pci 0000:10:00.0: [1d6a:14c0] type 00 class 0x020000 PCIe Endpoint
pci 0000:10:00.0: BAR 0 [mem 0xdc800000-0xdc87ffff 64bit]
pci 0000:10:00.0: BAR 2 [mem 0xdc8a0000-0xdc8a0fff 64bit]
pci 0000:10:00.0: BAR 4 [mem 0xdc400000-0xdc7fffff 64bit]
pci 0000:10:00.0: ROM    [mem 0xdc880000-0xdc89ffff pref]
...
pci 0000:00:02.1: bridge window [mem 0xdc400000-0xddafffff]: can't claim;
     address conflict with AMDIF031:00 [mem 0xdd500000-0xdd500fff]
pci 0000:03:00.0: bridge window [mem 0xdc400000-0xddafffff]: can't claim;
     no compatible bridge window
pci 0000:0b:06.0: bridge window [mem 0xdc400000-0xdc8fffff]: can't claim;
     no compatible bridge window
pci 0000:10:00.0: BAR 0 [mem 0xdc800000-0xdc87ffff 64bit]: can't claim;
     no compatible bridge window
... (cascades to ~20 devices)
pci 0000:0b:06.0: bridge window [mem size 0x00500000]: failed to assign
pci 0000:10:00.0: BAR 0 [mem 0xdc800000-0xdc87ffff 64bit]: failed to assign
...
atlantic 0000:10:00.0: probe with driver atlantic failed with error -5
```

Result: only one of the two AQC113C interfaces is available.

## Behaviour on 6.12.86 (working baseline)

The exact same `address conflict with AMDIF031:00` line is logged, but no
`failed to assign` follows. Both AQC113C interfaces probe and operate.

```
pci 0000:00:02.1: bridge window [mem 0xdc400000-0xddafffff]: can't claim;
     address conflict with AMDIF031:00 [mem 0xdd500000-0xdd500fff]
... (subsequent BAR allocations succeed)
```

## ACPI source of the conflict

The conflicting region is declared by `Device(SPTO)` in vendor SSDT
(`OEM TableID "AmdTable"`, the second instance), located at the bottom of a
deep ASMedia PCIe-switch hierarchy:

```asl
Scope (\_SB.PCI0.GPP7.UP00.DP40.UP00.DP68)
{
     Device (SPTO)
     {
         Name (_HID, "AMDIF031")
         Name (_CID, "AMDIF031")
         Name (_UID, 0x02)
         Method (_CRS, 0, NotSerialized)
         {
             Name (RBUF, ResourceTemplate ()
             {
                 Memory32Fixed (ReadWrite, 0xDD500000, 0x00001000, )
             })
             Return (RBUF)
         }
         Method (_STA, 0, NotSerialized) { ... Return (0x0F) ... }
     }
     Device (ASMP)
     {
         Name (_HID, "ASMT0001")
         ...
         // Uses SPTO as GPIO provider
     }
}
```

The address `0xDD500000` falls inside the bridge window
`[mem 0xdc400000-0xddafffff]` declared by host bridge `0000:00:02.1`,
which is the upstream port of the chain hosting the second AQC113C.

The exact base address shifts (e.g. `0xddd00000` when the discrete GPU is
removed and the iGPU is in use) — the BIOS clearly computes it dynamically
relative to other PCI resources, but always inside an active host bridge
window.

## Mitigations attempted (all unsuccessful on 6.18)

1. BIOS update F11 → F12b — no effect.
2. `pci=nocrs` — caused USB/keyboard hang at boot (this AMD Inference Engine
    ACPI device shares the ASMedia PCIe-switch ACPI subtree with USB GPIO
    resources).
3. `pci=realloc` — relocates some BARs into 64-bit space (NVMe ends up at
    `0xf2100000`), but `atlantic` still fails to probe with `-EIO`.
4. `pci=use_e820` — option appears silently ignored in 6.18.
5. `acpi_enforce_resources=lax` — no effect.
6. `pci=hpiosize=0,hpmemsize=0,hpmmiosize=0,hpmmioprefsize=0` — no effect.
7. ACPI table override (initrd) replacing `_STA` → `Zero` for SPTO —
    override loaded successfully (`ACPI: Table Upgrade: install`), but the
    conflict persists. Disabling SPTO via `_STA` additionally hangs USB
    probably because ASMP depends on SPTO as GpioIo provider.
8. ACPI table override defining a Scope() that overrides only `_CRS` to
    return an empty `ResourceTemplate ()` — table loads successfully but
    conflict still present, suggesting the early PCI resource-claim path
    does not consult the override.
9. Re-Size BAR Disabled, Above 4G Decoding Enabled, IOMMU Auto — no effect.

## Hypothesis

Between 6.12 and 6.18, a change in
`drivers/pci/setup-bus.c` / `drivers/acpi/resource.c` made an ACPI-claimed
MMIO region inside a host bridge window block that bridge from being
claimed entirely, instead of allowing the rest of the window to be used
around the ACPI reservation. The vendor BIOS bug (declaring a
`Memory32Fixed` for a non-functional placeholder NPU device inside an
active PCIe bridge window) was harmless under 6.12 and is fatal under 6.18.

## Attached / available on request

- Full `dmesg` from 6.12.86 (working) and 6.18.28 (broken)
- `lspci -vvv` output
- `cat /proc/iomem` from both kernels
- Disassembled DSDT and SSDT17/SSDT18 (`iasl -d`)
- `/proc/cmdline`, `.config`

## Bisect

I have not yet bisected. Happy to run a bisect between v6.12 and v6.18 if
maintainers can suggest a likely subsystem to narrow the search
(`drivers/pci/`, `drivers/acpi/resource.c`?).


https://bugzilla.kernel.org/show_bug.cgi?id=221493

---


-- 
Aleksandras
IT Administrator
alex@bevielis.lt
tel: +37069947470


           reply	other threads:[~2026-05-09 15:33 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <1778340596-26078-mlmmj-08aae49b@vger.kernel.org>]

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=7e9825d8-3180-4787-ab7a-456446b0cbb8@gmail.com \
    --to=jodeliukas@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.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