Re: [REGRESSION] amdgpu with Thunderbolt eGPU bracket fails since new bridge window alignment calculation code

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

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

On Fri, 10 Apr 2026, Jonas Höglund wrote:
> On Wed, 8 Apr 2026, at 10:43, Ilpo Järvinen wrote:
> > On Wed, 8 Apr 2026, Jonas Höglund wrote:
> >> 
> >> Sorry, I'm slightly unsure what I should be building and testing here.
> >> Is it fine to check out the pci/resource branch as it is and test that,
> >> or should I make sure to pick the patches from that branch atop e.g.
> >> 7.0-rc6?
> >
> > The latter is better because pci/resources is based at 7.0-rc1 and since 
> > then, there have been two fixes that went through -rc series (I'm not sure 
> > if either is relevant for your usecase, probably not but to be on safe 
> > side it's better to include them as well).
> >
> > BUT, it's easier to just merge pci/resource on top of -rc6 so you don't 
> > need to pick the patches by hand). I think the merge should go cleanly.
> >
> 
> Hi,
> 
> I built 7.0-rc7 with these commits from pci/resource rebased atop it:
> 
>   8cb08166 (pci/resource) PCI: Fix alignment calculation for resource size larger than align
>   9036bd0e PCI: Align head space better
>   8bbe8cec PCI: Rename window_alignment() to pci_min_window_alignment()
>   38ec53e1 parisc/PCI: Clean up align handling
>   3fa40d30 MIPS: PCI: Remove unnecessary second application of align
>   4dd6e1aa m68k/PCI: Remove unnecessary second application of align
>   0734cb24 ARM/PCI: Remove unnecessary second application of align
>   66475b5d resource: Rename 'tmp' variable to 'full_avail'
>   f699bcc8 resource: Pass full extent of empty space to resource_alignf callback
>   edfaa81d resource: Add __resource_contains_unbound() for internal contains checks
>   1ee4716a PCI: Fix premature removal from realloc_head list during resource assignment
>   dc4b4d04 PCI: Prevent shrinking bridge window from its required size
>   92427ab4 PCI: Prevent assignment to unsupported bridge windows
> 
> Here's the dmesg and iomem map:
>   https://up.firefly.nu/pub/amdgpu-egpu-7.0.0-rc7-pci-resource.dmesg.txt
>   https://up.firefly.nu/pub/amdgpu-egpu-7.0.0-rc7-pci-resource.iomem.txt
> 
> The thunderbolt dock is connected at the 52-second mark, and "works" as
> well as before (external GPU and monitors are functional from a user
> perspective).  Looks to me like something is still up with the bridge
> window/BAR handling... but I wouldn't know how much of that is down to
> the pci subsystem vs how amdgpu uses it.

Thanks for testing. The pre-existing fixes in pci/resource seem to resolve 
the regressions.

The remaining problems is bridge window that is pinned by sibling devices:

  6030000000-6051ffffff : PCI Bus 0000:3a
    6030000000-60501fffff : PCI Bus 0000:3b
      6030000000-60401fffff : PCI Bus 0000:3c
        6030000000-60401fffff : PCI Bus 0000:3d
          6030000000-60401fffff : PCI Bus 0000:3e
            6030000000-603fffffff : 0000:3e:00.0
            6040000000-60401fffff : 0000:3e:00.0
      6040200000-60480fffff : PCI Bus 0000:58

[   60.147972] amdgpu 0000:3e:00.0: BAR 0 [mem 0x6030000000-0x603fffffff 64bit pref]: releasing
[   60.147978] amdgpu 0000:3e:00.0: BAR 2 [mem 0x6040000000-0x60401fffff 64bit pref]: releasing
[   60.147982] pcieport 0000:3d:00.0: bridge window [mem 0x6030000000-0x60401fffff 64bit pref]: releasing
[   60.147985] pcieport 0000:3c:00.0: bridge window [mem 0x6030000000-0x60401fffff 64bit pref]: releasing
[   60.147988] pcieport 0000:3b:01.0: bridge window [mem 0x6030000000-0x60401fffff 64bit pref]: releasing
[   60.147991] pcieport 0000:3a:00.0: bridge window [mem 0x6030000000-0x60501fffff 64bit pref]: was not released (still contains assigned resources)
[   60.147994] pcieport 0000:00:07.2: bridge window [mem 0x6030000000-0x6051ffffff 64bit pref]: was not released (still contains assigned resources)
[   60.148003] pcieport 0000:3b:02.0: disabling bridge window [mem 0x00000000-0x000fffff 64bit pref disabled] to [bus 57] (unused)

The bridge window at 6040200000-60480fffff pins 6030000000-60501fffff in 
place. The resize for 0000:3e:00.0's BAR currently only releases 
0000:3e:00.0's resources and those upstream bridge windows that do not 
have other children.

The sibling bridge window that causes the pinning seems entirely empty as 
is highlighted by the last log line (but itis  noticed in a too late stage 
to help with the problem). It would be possible to release the pinning 
sibling and then perform resize through sysfs manually but...

...There are currently (at least) three recent reports which have this 
same problem, and one of the reporters started preparing a patch for it:

https://lore.kernel.org/linux-pci/29a5ee31baf8be7d07617beea016c3f6d03934bf.camel@ieee.org/T/#m114098e75df55a4ac5a3e9e0c6e948b12ce81ecd

So hopefully we soon have a kernel solution for it without requiring 
manual intervention through sysfs.


-- 
 i.