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

[Bjorn Helgaas <helgaas@kernel.org>]

[+cc Ilpo]

On Sun, Mar 15, 2026 at 12:35:53PM +0100, 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

Thanks, I think this is a known issue.  The most useful information
for fixing this would be a dmesg log and output of "sudo lspci -vv"
from the newest available kernel, ideally v6.19 or v7.0-rc.  Please
don't select what appears to be useful, just collect the complete
logs.

I'm pretty sure this isn't a regression, but if it is, please mention
the newest working version and the oldest broken one.

> 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.