* HTML message rejected: [REGRESSION] PCI: AMDIF031 ACPI resource conflicts cause bridge window allocation failure on X870E in
[not found] <1778340596-26078-mlmmj-08aae49b@vger.kernel.org>
@ 2026-05-09 15:32 ` jodeliukas
0 siblings, 0 replies; only message in thread
From: jodeliukas @ 2026-05-09 15:32 UTC (permalink / raw)
To: bhelgaas, linux-pci, linux-acpi, linux-kernel
# [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
^ permalink raw reply [flat|nested] only message in thread