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

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

[Michal Babička]

[-- Attachment #1: Type: text/plain, Size: 5688 bytes --]

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

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.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3523 bytes --]

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

[Michal Babička]

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

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.

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

[Thorsten Leemhuis]

On 3/15/26 12:54, 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

Lo! You CCed the regression list, which implies that this is a
regression. But you did not specify when the problem started. And if it
really is one: have you considered a git bisection? Then we'd know what
causes this. This in case of a regression most likely will be needed,
unless some developer has an idea what might be at fault here.

Ciao, Thorsten

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

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]

[-- Attachment #1: Type: text/plain, Size: 6963 bytes --]

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@linux.intel.com/

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@linux.intel.com/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.

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

[Bjorn Helgaas]

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

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]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

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 #2: egpu-logs-dyndbg.tar.gz --]
[-- Type: application/x-gzip, Size: 170531 bytes --]

[-- Attachment #3: egpu-logs.tar.gz --]
[-- Type: application/x-gzip, Size: 188194 bytes --]

[-- Attachment #4: Type: text/plain, Size: 7225 bytes --]


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

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

[Michal Babička]

[-- Attachment #1: Type: text/plain, Size: 1890 bytes --]

Hello,

I am reporting a reproducible PCI resource allocation problem on an
Apple Mac mini 2018 with a Thunderbolt 3 eGPU enclosure.

Hardware:

Apple Mac mini 2018
Razer Core X Chroma
NVIDIA GPU tested
AMD Radeon Vega 64 tested
Zorin OS 18 Pro
kernels tested: 6.12.x and 6.17.x

Problem summary:
The eGPU enclosure and GPU are detected and enumerated on the PCI bus,
but GPU initialization fails because PCI bridge windows / BAR
resources are not assigned correctly.

This reproduces with multiple GPU vendors in the same enclosure on the
same host, which suggests a PCI / Thunderbolt bridge resource
allocation problem on this platform rather than a vendor-specific
driver issue.

Expected behavior:
The kernel should assign valid PCI bridge windows and BAR resources so
the GPU can initialize successfully and become usable.

Actual behavior:
The GPU is visible on the PCI bus, but bridge windows and BAR
resources are incomplete or invalid, leaving the device unusable.

Observed errors include:

bridge window [mem size ...]: can't assign; no space
NVRM: BAR1 is 0M @ 0x0
RmInitAdapter failed
NVIDIA initialization fails
AMD shows similar behavior in the same enclosure on the same host

Kernel command line used for the latest debug boot:
BOOT_IMAGE=/boot/vmlinuz-6.17.0-19-generic
root=UUID=f0048c61-b4fe-4edb-9af5-bc756f9e2e7d ro quiet splash
"dyndbg=file drivers/pci/* +p" vt.handoff=7

I also confirmed that dynamic debug for drivers/pci was enabled.

I collected and attached two archives:

egpu-logs.tar.gz
egpu-logs-dyndbg.tar.gz

These archives contain:

full dmesg
dmesg extract
lspci -nnvvv
lspci tree
per-device lspci dumps for the relevant bridges and GPU
/proc/iomem
journalctl -b
nvidia-smi output

Please let me know which specific logs or excerpts would be most useful.

Best regards,
Michal Babička

[-- Attachment #2: egpu-logs.tar.gz --]
[-- Type: application/x-gzip, Size: 188194 bytes --]

[-- Attachment #3: egpu-logs-dyndbg.tar.gz --]
[-- Type: application/x-gzip, Size: 170531 bytes --]

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

[Michal Babička]

Hello,

I am reporting a reproducible PCI resource allocation problem on an
Apple Mac mini 2018 with a Thunderbolt 3 eGPU enclosure.

Hardware:

Apple Mac mini 2018
Razer Core X Chroma
NVIDIA GPU tested
AMD Radeon Vega 64 tested
Zorin OS 18 Pro
kernels tested: 6.12.x and 6.17.x

Problem summary:
The eGPU enclosure and GPU are detected and enumerated on the PCI bus,
but GPU initialization fails because PCI bridge windows / BAR
resources are not assigned correctly.

This reproduces with multiple GPU vendors in the same enclosure on the
same host, which suggests a PCI / Thunderbolt bridge resource
allocation problem on this platform rather than a vendor-specific
driver issue.

Expected behavior:
The kernel should assign valid PCI bridge windows and BAR resources so
the GPU can initialize successfully and become usable.

Actual behavior:
The GPU is visible on the PCI bus, but bridge windows and BAR
resources are incomplete or invalid, leaving the device unusable.

Observed errors include:

bridge window [mem size ...]: can't assign; no space
NVRM: BAR1 is 0M @ 0x0
RmInitAdapter failed

For the latest debug boot I used:
BOOT_IMAGE=/boot/vmlinuz-6.17.0-19-generic
root=UUID=f0048c61-b4fe-4edb-9af5-bc756f9e2e7d ro quiet splash
"dyndbg=file drivers/pci/* +p" vt.handoff=7

I collected full logs, including dmesg, lspci, /proc/iomem,
journalctl, and per-device dumps. I can provide them in another form
if needed, since my previous attempts with attachments were blocked by
mail policy.

Best regards,
Michal Babička
michal.babka@gmail.com