Linux PCI subsystem development
 help / color / mirror / Atom feed
* 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

only message in thread, other threads:[~2026-05-09 15:33 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <1778340596-26078-mlmmj-08aae49b@vger.kernel.org>
2026-05-09 15:32 ` HTML message rejected: [REGRESSION] PCI: AMDIF031 ACPI resource conflicts cause bridge window allocation failure on X870E in jodeliukas

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox