Re: [BUG] Apple Mac mini 2018 + Thunderbolt 3 eGPU: PCI bridge window / BAR allocation failure prevents NVIDIA and AMD GPUs from initializing

[Ilpo Järvinen]

On Sun, 15 Mar 2026, Michal Babička wrote:

> Subject: Apple Mac mini 2018 + Thunderbolt 3 eGPU: PCI bridge window / BAR allocation failure prevents NVIDIA and AMD GPUs from initializing
> 
> Hardware / platform:
> - Host: Apple Mac mini 2018
> - Connection: Thunderbolt 3
> - eGPU enclosure: Razer Core X Chroma
> - Tested GPUs:
>   - NVIDIA Quadro P400
>   - NVIDIA Quadro P4000
>   - AMD Radeon Vega 64
> 
> Linux distributions / kernels tested:
> - Ubuntu-based systems
> - Zorin OS 18 Pro
> - Multiple kernels tested, including 6.12.x and 6.17.x

None of which are even near the latest when it comes to resource 
allocation improvements and fixes (though you didn't specify .x).

> Problem summary:
> On Apple Mac mini 2018, an external GPU connected through Thunderbolt 3 in a Razer Core X Chroma enclosure is detected and enumerates on the PCI bus, but GPU initialization fails because PCI bridge windows / BAR resources are not assigned correctly.
> 
> This is reproducible across different Linux installations and with GPUs from different vendors, which strongly suggests a platform/topology-level PCIe resource allocation problem rather than a bug in one specific GPU driver.
> 
> Observed behavior:
> - The Thunderbolt enclosure is detected correctly.
> - boltctl shows the enclosure as connected / authorized.
> - The GPU appears in lspci.
> - The kernel loads the vendor driver module.
> - GPU initialization then fails.
> 
> For NVIDIA, nvidia-smi reports:
>   "NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver."
> 
> Relevant NVIDIA kernel messages include:
> - "BAR 1 [mem size 0x10000000 64bit pref]: can't assign; no space"
> - "BAR 3 [mem size 0x02000000 64bit pref]: can't assign; no space"
> - "This PCI I/O region assigned to your NVIDIA device is invalid"
> - "BAR1 is 0M @ 0x0"
> - "RmInitAdapter failed"
> - in some attempts also:
>   "fallen off the bus and is not responding to commands"
> 
> With NVIDIA Quadro P4000, the same general failure pattern was observed:
> - the GPU is detected on the PCI bus,
> - the NVIDIA kernel module loads,
> - initialization fails,
> - and the logs again point to invalid / missing BAR assignments and resource allocation problems behind the Thunderbolt PCIe bridge hierarchy.
> 
> For nouveau, the failure is visible as BAR/resource allocation failure as well, for example:
> - "bar: one-time init failed, -12"
> - "init failed with -12"
> - "Device allocation failed: -12"
> 
> With AMD Radeon Vega 64 installed in the same enclosure on the same host, the same fundamental problem occurs:
> - the enclosure is detected,
> - the GPU enumerates,
> - initialization fails,
> - and the overall behavior indicates the same lower-level PCI resource / bridge window allocation issue.
> 
> This strongly suggests the issue is not NVIDIA-specific.
> 
> Thunderbolt state:
> boltctl reports the Razer Core X Chroma enclosure as connected/authorized correctly, for example:
> - type: peripheral
> - generation: Thunderbolt 3
> - status: authorized
> - rx speed: 40 Gb/s
> - tx speed: 40 Gb/s
> 
> Important conclusion:
> Thunderbolt authorization itself appears to work.
> PCI enumeration also works.
> The failure happens later, at PCI resource assignment / bridge window sizing / BAR allocation time.
> 
> Key dmesg patterns observed:
> - multiple "can't assign; no space" messages for PCI bridges and BARs
> - BAR1 / BAR3 of the GPU not assigned
> - bridge windows under the Thunderbolt hierarchy not large enough
> - reassignment attempts that still leave required windows unassigned or invalid
> - vendor driver subsequently failing device initialization
> 
> Examples of affected topology in logs:
> - 0000:00:01.1
> - 0000:05:00.0
> - 0000:06:01.0
> - 0000:0b:00.0
> - in other boots, the same problem may appear under a different BDF address after Thunderbolt re-enumeration
> 
> Representative log excerpts:
> - pci 0000:0b:00.0: BAR 1 [mem size 0x10000000 64bit pref]: can't assign; no space
> - pci 0000:0b:00.0: BAR 3 [mem size 0x02000000 64bit pref]: can't assign; no space
> - pci 0000:06:01.0: bridge window [mem size 0x10000000]: can't assign; no space
> - pci 0000:05:00.0: bridge window [mem size 0x20200000]: can't assign; no space
> - NVRM: BAR1 is 0M @ 0x0
> - NVRM: RmInitAdapter failed
> - NVRM: The NVIDIA GPU ... has fallen off the bus and is not responding to commands
> - nouveau ... Device allocation failed: -12
> 
> Kernel command line options already tested:
> The following boot parameters were tested in various combinations:
> - pci=realloc=on
> - pci=hpbussize=0x33,hpmemsize=256M,hpiosize=2M
> - pcie_aspm=off
> - pci=nommconf
> - pci=noaer
> 
> These mitigations did not resolve the issue.
> 
> Why this looks platform/topology specific:
> - The same Thunderbolt eGPU enclosure is recognized correctly.
> - The same failure pattern appears with NVIDIA Quadro P400, NVIDIA Quadro P4000, and AMD Radeon Vega 64.
> - The common denominator is Apple Mac mini 2018 + Thunderbolt PCIe topology under Linux.
> - The failure mode is centered around PCI bridge window sizing / BAR placement, not around one vendor-specific driver alone.
> 
> Expected behavior:
> The Thunderbolt eGPU should receive valid PCI bridge windows and valid BAR assignments so that the GPU driver can initialize the device successfully.
> 
> Actual behavior:
> The GPU is visible on the bus, but bridge windows and BAR resources are not fully assigned, which leaves the device unusable and prevents the driver from completing initialization.
> 
> Request:
> Please investigate PCI resource allocation / bridge window sizing for Thunderbolt eGPU topologies on Apple Mac mini 2018 under Linux, especially where large GPU BARs must be assigned behind multiple Thunderbolt / PCIe bridges.
> 
> Cross-vendor reproducibility on the same enclosure and same host strongly suggests that the root cause is in PCIe/Thunderbolt resource allocation on this platform rather than in a specific NVIDIA or AMD driver.

Hi,

Have you tried with this pending patch:

https://patchwork.kernel.org/project/linux-pci/patch/20260219153951.68869-1-ilpo.jarvinen@xxxxxxxxxxxxxxx/

This too might be relevant here (it has been recently accepted for 
next):

https://patchwork.kernel.org/project/linux-pci/patch/20260313084551.1934-1-ilpo.jarvinen@xxxxxxxxxxxxxxx/i.

There are plenty of other fixes as well done relatively recently (though 
some may be irrelevant for the kernels as old as you've been testing).

You didn't include any real logs that shows the error into this report,
those log snippets are useless in root causing where the problem 
originates from. All dmesg logs should be taken with dyndebug enabled 
(with CONFIG_DYNAMIC_DEBUG + dyndbg="file drivers/pci/*.c +p" on the 
kernel's command line). Please also dump /proc/iomem.

-- 
 i.