Re: [REGRESSION] amdgpu fails to load eGPU after 6.19

[Ilpo Järvinen]

On Tue, 14 Apr 2026, Rio Liu wrote:

> Hi Ilpo,
> 
> > This snippet only contains collateral damage and does not show where the
> > problem originates from. Please provide a full dmesg instead with
> > dyndbg="file drivers/pci/*.c +p" on the kernel command line.
> >
> > Preferrably test with the latest code + fixes that are in pci/resources
> > branch (you can just take all changes from there) and get the logs from
> > there. I wouldn't be surprised if your problem is already addressed by
> > those fixes but we'll see.
> 
> Thanks a lot for the help! I tested on pci/resources
> 8cb081667377709f4924ab6b3a88a0d7a761fe91 "PCI: Fix alignment calculation for
> resource size larger than align", and the eGPU is now loading! There are some
> messages in dmesg showing "can't assign; no space" and "failed to assign", but I
> don't see any functional impact from it. Including the dmesg anyways in case
> there's anything important: https://pastebin.com/n5hhtkz0.

Hi,

Thanks for testing.

Most of the assignment failures occur for io resources. It tends to be 
that in large systems of today, hotplug reservation consumes all io space 
for things that don't need any. Usually, the io resource assignment 
failures are harmless.

Then there's a bridge window pin for this bridge window:

pcieport 0000:04:00.0: bridge window [mem 0x6000000000-0x60201fffff 64bit pref]: was not released (still contains assigned resources)

That window is pinned in place by sibling devices so kernel cannot 
release it prior to attempting BAR resizing, which in turn prevents BAR 
resizing from succeeding as the bridge windows cannot be made large 
enough.

You should be able to see what the siblings are easily from /proc/iomem.

It may be possible to manually remove the siblings first, resize the 
eGPU's BAR through sysfs, and finally rescan.

-- 
 i.