t.s.ohnishi77
New member
- Joined
- Sep 7, 2026
- Messages
- 2
Posting this in case someone hits the same wall, with a small BIOS request for MSI at the end.
Board: MAG X870E TOMAHAWK MAX WIFI PZ (MS-7E84), BIOS 1.A42 / Ryzen 9 9950X / 3x RTX 5060 Ti
(one in the CPU x16 slot, two below the chipset) / Ubuntu 26.04, kernel 7.0.
**Symptom:** with three GPUs installed, the third one is invisible to Linux. It shows up in
lspci but no driver ever binds to it, because its BAR 0 is never assigned. Not a bad card,
slot or riser. Windows is unaffected.
**Cause:** the firmware declares an ACPI device AMDIF031 (Promontory chipset GPIO) whose
_CRS returns Memory32Fixed(0xD4300000, 0x1000). That address sits inside the memory window
0xC8000000-0xD4DFFFFF of bridge 00:02.1, where all chipset-attached devices live. Linux
treats a non-PCI reservation inside a bridge window as invalid and throws the window away:
It then recomputes the window and gets it too small - two 65 MB windows each holding a
64 MB-aligned BAR need 193 MB laid out, but only 134 MB is reserved:
Address space was never the problem - over 1 GB below 4 GB was free. And the BIOS assignment
itself was correct; it had given all three GPUs valid BARs. With only two GPUs everything
fits, which is why this stays hidden until you add the third.
**What did NOT work** (saving you the time I burned):
- pci=realloc / pci=hpmemsize=0 / pci=hpmemsize=64M - window size unchanged
- pci=nocrs - does not boot
- blacklisting gpio_amdpt - the reservation happens at ACPI enumeration, not at driver probe
- overriding the SSDT via initrd - the override mechanism itself is broken on kernel 7.0
- BIOS: disabling USB4, SR-IOV, toggling Above 4G - 0xD4300000 never moves
**The fix** - one line in drivers/acpi/acpi_platform.c so the platform device is never
created and therefore never reserves the address:
Nothing on this board uses that GPIO - its only consumers (ASMP/ASMT) are already disabled
by the firmware. Rebuild the distro kernel with that patch and all three cards show up.
**Keep Re-Size BAR DISABLED.** With ReBAR on, BAR1 becomes 16 GB and needs 16 GB alignment,
and the identical shortfall reappears in 64-bit space - the third card then loses BAR1
instead of BAR0 and still fails to probe (NVRM: BAR1 is 0M @ 0x0). Secure Boot also has to
be off to boot a self-built kernel.
**Request to MSI:** could the MMIO block for AMDIF031 be moved outside the PCIe bridge
memory windows in a future BIOS? It costs nothing under Windows, but on Linux it silently
kills PCIe enumeration behind the chipset - no error is shown, the device just never
appears. Anyone running this board as a multi-GPU workstation under Linux will hit it.
The board has been great for this build otherwise, and this is the one thing in the way.
Board: MAG X870E TOMAHAWK MAX WIFI PZ (MS-7E84), BIOS 1.A42 / Ryzen 9 9950X / 3x RTX 5060 Ti
(one in the CPU x16 slot, two below the chipset) / Ubuntu 26.04, kernel 7.0.
**Symptom:** with three GPUs installed, the third one is invisible to Linux. It shows up in
lspci but no driver ever binds to it, because its BAR 0 is never assigned. Not a bad card,
slot or riser. Windows is unaffected.
**Cause:** the firmware declares an ACPI device AMDIF031 (Promontory chipset GPIO) whose
_CRS returns Memory32Fixed(0xD4300000, 0x1000). That address sits inside the memory window
0xC8000000-0xD4DFFFFF of bridge 00:02.1, where all chipset-attached devices live. Linux
treats a non-PCI reservation inside a bridge window as invalid and throws the window away:
pci 0000:00:02.1: bridge window [mem 0xc8000000-0xd4dfffff]: can't claim;
address conflict with AMDIF031:00 [mem 0xd4300000-0xd4300fff]
It then recomputes the window and gets it too small - two 65 MB windows each holding a
64 MB-aligned BAR need 193 MB laid out, but only 134 MB is reserved:
pci 0000:09:00.0: bridge window [mem 0x90000000-0x985fffff]: assigned (134M)
pci 0000:0a:08.0: bridge window [mem size 0x04100000]: can't assign; no space
pci 0000:10:00.0: BAR 0 [mem size 0x04000000]: can't assign; no space
Address space was never the problem - over 1 GB below 4 GB was free. And the BIOS assignment
itself was correct; it had given all three GPUs valid BARs. With only two GPUs everything
fits, which is why this stays hidden until you add the third.
**What did NOT work** (saving you the time I burned):
- pci=realloc / pci=hpmemsize=0 / pci=hpmemsize=64M - window size unchanged
- pci=nocrs - does not boot
- blacklisting gpio_amdpt - the reservation happens at ACPI enumeration, not at driver probe
- overriding the SSDT via initrd - the override mechanism itself is broken on kernel 7.0
- BIOS: disabling USB4, SR-IOV, toggling Above 4G - 0xD4300000 never moves
**The fix** - one line in drivers/acpi/acpi_platform.c so the platform device is never
created and therefore never reserves the address:
static const struct acpi_device_id forbidden_id_list[] = {
{"PNP0200", 0}, /* AT DMA Controller */
+ {"AMDIF031", 0}, /* AMD Promontory GPIO: MMIO inside a PCIe bridge window */
{ACPI_SMBUS_MS_HID, ACPI_ALLOW_WO_RESOURCES},
{ }
};
Nothing on this board uses that GPIO - its only consumers (ASMP/ASMT) are already disabled
by the firmware. Rebuild the distro kernel with that patch and all three cards show up.
**Keep Re-Size BAR DISABLED.** With ReBAR on, BAR1 becomes 16 GB and needs 16 GB alignment,
and the identical shortfall reappears in 64-bit space - the third card then loses BAR1
instead of BAR0 and still fails to probe (NVRM: BAR1 is 0M @ 0x0). Secure Boot also has to
be off to boot a self-built kernel.
**Request to MSI:** could the MMIO block for AMDIF031 be moved outside the PCIe bridge
memory windows in a future BIOS? It costs nothing under Windows, but on Linux it silently
kills PCIe enumeration behind the chipset - no error is shown, the device just never
appears. Anyone running this board as a multi-GPU workstation under Linux will hit it.
The board has been great for this build otherwise, and this is the one thing in the way.