On Ilpo Järvinen wrote: > Great, it worked (I was somewhat afraid there might have been some > landmine for the case where there's no bridge). > > And yes, it's very important in general case to assign the resource in > correct order because the assignment algorithm is greedy.
Thanks, Ilpo, for both reviews. Yes, it works fine even without the bridge. This is what it looks like when triggering the resize through sysfs, and through amdgpu's probe-on-insmod, on the actual root-bus hardware (HoneyComb LX2K, LX2160A, dGPU directly on the root bus, no upstream bridge). Manual trigger via sysfs (shrink then grow back, forcing the release + reassign path both directions): pci 0004:01:00.0: BAR 0 [mem 0xa400000000-0xa4ffffffff 64bit pref]: releasing pci 0004:01:00.0: BAR 2 [mem 0xa500000000-0xa5001fffff 64bit pref]: releasing pci 0004:01:00.0: BAR 0 [mem 0xa400000000-0xa40fffffff 64bit pref]: assigned pci 0004:01:00.0: BAR 2 [mem 0xa410000000-0xa4101fffff 64bit pref]: assigned ... pci 0004:01:00.0: BAR 0 [mem 0xa400000000-0xa40fffffff 64bit pref]: releasing pci 0004:01:00.0: BAR 2 [mem 0xa410000000-0xa4101fffff 64bit pref]: releasing pci 0004:01:00.0: BAR 0 [mem 0xa400000000-0xa4ffffffff 64bit pref]: assigned pci 0004:01:00.0: BAR 2 [mem 0xa500000000-0xa5001fffff 64bit pref]: assigned And the real-world path, amdgpu's own probe with the amdgpu.rebar=0 workaround removed: amdgpu 0004:01:00.0: VRAM: 4096M 0x000000F400000000 - 0x000000F4FFFFFFFF (4096M used) amdgpu 0004:01:00.0: [drm] Detected VRAM RAM=4096M, BAR=4096M amdgpu 0004:01:00.0: 4096M of VRAM memory ready No "Fatal error during GPU init" (the original regression's failure signature), full IP block init, driver comes up clean.
