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

[Michal Babička]

Hi,

please find attached the requested logs collected on my Mac mini 2018 with the Razer Core X Chroma eGPU setup.

Attached:
- logs collected with dyndbg="file drivers/pci/* +p" enabled
- /proc/iomem output
- the earlier archive collected without dyndbg for comparison

Current setup:
- Mac mini 2018
- Zorin OS 18 Pro
- kernel 6.17.0-19-generic
- NVIDIA Quadro P4000 in Razer Core X Chroma

The problem is still reproducible. The GPU is visible on the PCI bus, but initialization fails and nvidia-smi reports no devices found. The logs still show PCI bridge window / BAR allocation failures and invalid BAR assignments for the GPU.

Please let me know if you want any additional logs or if you would like me to test a specific patch or kernel version.

Thanks,
Michal Babicka

Attachment: egpu-logs-dyndbg.tar.gz
Description: GNU Zip compressed data

Attachment: egpu-logs.tar.gz
Description: GNU Zip compressed data

> 16. 3. 2026 v 12:57, Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx>:
> 
> 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.