On Wed, Jul 8, 2026 at 2:03 PM Mario Limonciello <[email protected]> wrote: > > > > On 7/8/26 13:02, Alex Deucher wrote: > > On Wed, Jul 8, 2026 at 1:59 PM Mario Limonciello > > <[email protected]> wrote: > >> > >> > >> > >> On 7/8/26 12:52, Oz Tiram wrote: > >>> Hi Mario, > >>> > >>> Tested on 7.2-rc2 with your patch applied. The mismatch condition is > >>> unchanged from 6.18.35: > >>> > >>> amdgpu 0000:0b:00.0: VFCT bus number mismatch: table 106 != runtime > >>> 11, > >>> matching by device identity (vendor 0x1002 device 0x1900) > >>> amdgpu 0000:0b:00.0: Fetched VBIOS from VFCT > >>> > >>> Both GPUs initialise fully with your patch. > >>> > >>> I also tested 7.2-rc2 without pci=realloc,assign-busses to check whether > >>> the pci/realloc changes fixed the dGPU probe failure. They did not -- the > >>> dGPU still fails on 7.2-rc2: > >>> > >>> amdgpu 0000:03:00.0: Fatal error during GPU init > >>> amdgpu 0000:03:00.0: probe with driver amdgpu failed with error -12 > >>> > >>> Without the kernel argument the iGPU sits at its POST bus (0x6A), VFCT > >>> matches directly, and it works fine -- but the dGPU is unusable. > >>> pci=realloc,assign-busses remains necessary for this machine on 7.2-rc2, > >>> which means the VFCT mismatch persists and your patch is still needed. > >>> > >>> Thank you for not giving up on me so quickly! > >>> This is my first time working on such issue. It feels > >>> daunting to modify kernel code. > >> > >> OK, in that case I will clean up and post the patches shortly. You'll > >> be able to use them for a workaround if everyone else is aligned. The > >> part I'm worried about with these is how they would interplay with a > >> system with multiple of the same GPU. But I don't believe we would be > >> fetching VBIOS from VFCT in that case most likely? Not sure. > > > > It's allowed by the spec. A number of apple systems use VFCT for > > multu-GPU systems with the same GPU. > > But then what happens with the bus numbers? They all need to be on the > same bus?
I'm not sure. As far as I know, the VFCT is populated by the sbios based on the locations at boot time. We can ask the vbios team for more details. Alex > > > > > Alex > > > >> > >> We really shouldn't have to set pci=realloc,assign-busses on a design > >> with all internal PCIe devices. We should adjust resource allocation > >> code for this case. > >> > >> So please start another another thread with the linux-pci mailing list > >> on this issue, include a full dmesg showing what happens when you don't > >> add the parameters and then what happens when you do (feel free to > >> include/reference this patch in that thread too). > >> > >> If you want to use one, this is the kind of thing an LLM with access to > >> a kernel checkout and both those dmesgs might be good at helping to > >> propose a draft for a solution to the resource allocation code too. > >> > >> You can CC me on that linux-pci mailing list submission, and we'll see > >> if we can come up with a better solution for you. > >> > >>> > >>> Oz > >>> > >>> > >>> On 7/8/26 18:39, Mario Limonciello wrote: > >>>> On 7/8/26 11:35, Oz Tiram wrote: > >>>>> Hi Mario, > >>>>> > >>>>> The GPU is internal. It's an AMD RADEON PRO W7800 48GB. > >>>>> The kernel is built from gentoo-sources-6.18.35. > >>>>> > >>>>> I will test the latest sys-kernel/vanilla-sources (7.1.3) and let you > >>>>> know. > >>>>> > >>>>> Best regards, > >>>> > >>>> Thanks. Can you please test 7.2-rc2? > >>>> > >>>> I'll clean up the workaround and propose it for review in parallel. > >>>> > >>>>> > >>>>> Oz > >>>>> > >>>>> On 7/8/26 15:13, Mario Limonciello wrote: > >>>>>> > >>>>>> On 7/8/26 08:10, Oz Tiram wrote: > >>>>>>> Hi Mario, > >>>>>>> > >>>>>>> > If you drop that - does this notice still come up? > >>>>>>> > >>>>>>> No, the notice does not appear without pci=realloc,assign-busses. > >>>>>>> The iGPU stays at its POST bus (0x6A = 106), VFCT matches > >>>>>>> directly, and it fetches the VBIOS without any mismatch. > >>>>>>> > >>>>>>> However, dropping the kernel argument is not an option on this > >>>>>>> machine: > >>>>>>> without it the discrete GPU (0x7449) fails to probe entirely: > >>>>>>> > >>>>>>> amdgpu 0000:03:00.0: amdgpu: Fatal error during GPU init > >>>>>>> amdgpu 0000:03:00.0: probe with driver amdgpu failed with error > >>>>>>> -12 > >>>>>>> > >>>>>>> The firmware BARs cannot be mapped without resource reallocation, so > >>>>>>> pci=realloc,assign-busses is required for the dGPU, which in turn > >>>>>>> reassigns > >>>>>>> the iGPU to bus 0x0B and triggers the mismatch your patch resolves. > >>>>>> > >>>>>> Got it; thanks for clarifying. I would like to dig a little bit > >>>>>> futher into that though. What kernel are you finding this behavior > >>>>>> and can it still reproduce with 7.2-rc2 if it's older? There was a > >>>>>> bunch of pci/realloc changes that happened in the last cycle that > >>>>>> might have helped this. > >>>>>> > >>>>>> Also; is it an eGPU (external) or dGPU (internal)? > >>>>>> > >>>>>> If it's an dGPU IMO this is arguably a BIOS issue that not enough > >>>>>> resources were applied in the first place. > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Thank you, > >>>>>>> > >>>>>>> Oz > >>>>>>> > >>>>>>> > >>>>>>> On 7/8/26 14:55, Mario Limonciello wrote: > >>>>>>>> Hi Oz, > >>>>>>>> > >>>>>>>> On 7/8/26 07:36, Oz Tiram wrote: > >>>>>>>>> Hi Mario, > >>>>>>>>> > >>>>>>>>> Tested on a Morefine MNAS X1 AI Workstation (AMD Ryzen 7 Pro > >>>>>>>>> 8845HS / Radeon 780M iGPU) with pci=realloc,assign-busses. > >>>>>>>>> > >>>>>>>>> The VFCT entry for the iGPU has PCIBus=106 (0x6A, recorded at > >>>>>>>>> POST) while the > >>>>>>>>> runtime bus is 11 (0x0B). Your patch fires exactly as expected: > >>>>>>>>> > >>>>>>>>> amdgpu 0000:0b:00.0: amdgpu: VFCT bus number mismatch: table > >>>>>>>>> 106 ! = runtime 11, > >>>>>>>>> matching by device identity (vendor 0x1002 device 0x1900) > >>>>>>>>> amdgpu 0000:0b:00.0: amdgpu: Fetched VBIOS from VFCT > >>>>>>>>> > >>>>>>>>> The iGPU initialises fully and drives the framebuffer. > >>>>>>>>> > >>>>>>>>> One minor nit: the dev_notice format string ends with \\n (two > >>>>>>>>> characters) rather > >>>>>>>>> than \n. The resulting kernel message has a literal "\n" at the > >>>>>>>>> end. Same issue > >>>>>>>>> exists in the nearby "too short #2" dev_info -- not introduced by > >>>>>>>>> your patch, but > >>>>>>>>> might be worth cleaning up. > >>>>>>>>> > >>>>>>>>> Tested-by: Oz Tiram <[email protected]> > >>>>>>>>> > >>>>>>>> > >>>>>>>> Thanks for confirming. Before I split up this patch and post it > >>>>>>>> in smaller logical pieces can you confirm my proposed root cause > >>>>>>>> is right that this issue happens because "pci=realloc,assign- > >>>>>>>> busses" was on your kernel command line? > >>>>>>>> > >>>>>>>> If you drop that - does this notice still come up? > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> > >>>>>>>>> On 7/6/26 02:56, Mario Limonciello wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 7/5/26 14:10, Oz Tiram wrote: > >>>>>>>>>>> Hi Mario, > >>>>>>>>>>> > >>>>>>>>>>> To make sure I understand correctly: are you suggesting that > >>>>>>>>>>> the bus > >>>>>>>>>>> number in the VFCT was legitimate at BIOS POST time, and that > >>>>>>>>>>> pci=realloc,assign-busses is what changes it at runtime, > >>>>>>>>>>> causing the > >>>>>>>>>>> mismatch? > >>>>>>>>>> > >>>>>>>>>> That's what it sounds like right now. You can easily drop all > >>>>>>>>>> the superfluous kernel command line optiosn and see. > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> I'm not familiar enough with the PCI subsystem to know the > >>>>>>>>>>> right way to > >>>>>>>>>>> implement that — could you point me in the right direction? > >>>>>>>>>> > >>>>>>>>>> Well there's a variety of ways to do it. But how about we start > >>>>>>>>>> here - if we make that specific busnr match optional and instead > >>>>>>>>>> make a VID/DID match. > >>>>>>>>>> > >>>>>>>>>> See if the attached patch helps. > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Oz > >>>>>>>>>>> > >>>>>>>>>>> On 7/5/26 20:37, Mario Limonciello wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On 7/5/26 05:04, Oz Tiram wrote: > >>>>>>>>>>>>> APUs (e.g. AMD Radeon 780M / HawkPoint, PCI 1002:1900) have no > >>>>>>>>>>>>> dedicated VBIOS ROM chip. amdgpu_get_bios_apu() attempts > >>>>>>>>>>>>> four paths > >>>>>>>>>>>>> before giving up: > >>>>>>>>>>>>> > >>>>>>>>>>>>> 1. ACPI VFCT table > >>>>>>>>>>>>> 2. VRAM BAR read > >>>>>>>>>>>>> 3. ROM BAR read > >>>>>>>>>>>>> 4. platform BIOS > >>>>>>>>>>>>> > >>>>>>>>>>>>> On some systems all four fail. The specific case motivating > >>>>>>>>>>>>> this patch > >>>>>>>>>>>>> is a hybrid graphics machine (dGPU + APU) where: > >>>>>>>>>>>>> > >>>>>>>>>>>>> - The VFCT table contains the iGPU entry but with a stale > >>>>>>>>>>>>> PCIBus value > >>>>>>>>>>>>> from BIOS POST time (0x6A). When the kernel boots with > >>>>>>>>>>>>> pci=realloc,assign-busses, PCI bus numbers are > >>>>>>>>>>>>> reassigned dynamically > >>>>>>>>>>>>> and the iGPU lands on bus 0x0B at runtime. > >>>>>>>>>>>>> amdgpu_acpi_vfct_bios() > >>>>>>>>>>>>> matches entries by bus number, so the entry is never > >>>>>>>>>>>>> found. > >>>>>>>>>>>>> - The VRAM BAR is unmapped at probe time. > >>>>>>>>>>>>> - The ROM BAR is zero (PCI firmware did not assign it). > >>>>>>>>>>>>> - No platform BIOS mapping exists. > >>>>>>>>>>>>> > >>>>>>>>>>>>> The UEFI GOP driver initialises the iGPU successfully for > >>>>>>>>>>>>> early display, > >>>>>>>>>>>>> confirming the hardware is functional. The VBIOS image data > >>>>>>>>>>>>> embedded in > >>>>>>>>>>>>> the VFCT is also valid; only the PCIBus metadata is wrong. > >>>>>>>>>>>> > >>>>>>>>>>>> So the BIOS on this machine is actually totally fine; it's > >>>>>>>>>>>> just when the kernel is booted to reassign busses there is a > >>>>>>>>>>>> problem? > >>>>>>>>>>>> > >>>>>>>>>>>> In that case; why not detect the kernel was booted this way > >>>>>>>>>>>> and keep track of the original bus number when reassigned to > >>>>>>>>>>>> avoid the issue? > >>>>>>>>>>>> > >>>>>>>>>>>>> The firmware > >>>>>>>>>>>>> file can be extracted directly from the VFCT using dd: > >>>>>>>>>>>>> > >>>>>>>>>>>>> dd if=/sys/firmware/acpi/tables/VFCT bs=1 skip=$((0x68)) > >>>>>>>>>>>>> count=16896 \ > >>>>>>>>>>>>> of=/lib/firmware/amdgpu/1002_1900.bin > >>>>>>>>>>>>> > >>>>>>>>>>>>> (0x68 is the byte offset of the VBIOS image after the ACPI > >>>>>>>>>>>>> table header > >>>>>>>>>>>>> and VFCT_IMAGE_HEADER; the image length 16896 comes from the > >>>>>>>>>>>>> ImageLength > >>>>>>>>>>>>> field in VFCT_IMAGE_HEADER.) > >>>>>>>>>>>>> > >>>>>>>>>>>>> The driver then prints "Unable to locate a BIOS ROM" and > >>>>>>>>>>>>> refuses to > >>>>>>>>>>>>> bind, leaving the APU completely unusable under Linux. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Add a fifth fallback: request a firmware file named > >>>>>>>>>>>>> "amdgpu/<vendor>_<device>.bin" (e.g. "amdgpu/1002_1900.bin") via > >>>>>>>>>>>>> request_firmware(). This allows a VBIOS image extracted as > >>>>>>>>>>>>> above to be > >>>>>>>>>>>>> placed in /lib/firmware/ and makes the binding succeed > >>>>>>>>>>>>> without patching > >>>>>>>>>>>>> ACPI tables or BIOS. > >>>>>>>>>>>>> > >>>>>>>>>>>>> The fallback is only reached if all existing paths have > >>>>>>>>>>>>> already failed, > >>>>>>>>>>>>> so there is no regression risk for boards where VFCT or ROM > >>>>>>>>>>>>> BAR work. > >>>>>>>>>>>> > >>>>>>>>>>>> What happens if the VBIOS changes in another way one boot to > >>>>>>>>>>>> another? You might have some other stateful information that > >>>>>>>>>>>> isn't updated. > >>>>>>>>>>>> > >>>>>>>>>>>> The whole thing to me feels like a hack for a behavior we can > >>>>>>>>>>>> control in the kernel when doing reassignments. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Signed-off-by: Oz Tiram <[email protected]> > >>>>>>>>>>>>> --- > >>>>>>>>>>>>> v2: Fix commit message: clarify that VFCT contains the iGPU > >>>>>>>>>>>>> entry but > >>>>>>>>>>>>> with a stale PCIBus from BIOS POST that mismatches the > >>>>>>>>>>>>> runtime bus > >>>>>>>>>>>>> number assigned by pci=realloc,assign-busses. Explain > >>>>>>>>>>>>> that the VBIOS > >>>>>>>>>>>>> image data is valid and document the dd extraction > >>>>>>>>>>>>> command and byte > >>>>>>>>>>>>> offsets. Note that the UEFI GOP driver initialises the > >>>>>>>>>>>>> iGPU > >>>>>>>>>>>>> successfully, confirming the hardware is functional. > >>>>>>>>>>>>> > >>>>>>>>>>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 23 +++++++++++++ > >>>>>>>>>>>>> ++ ++ ++ ++++ > >>>>>>>>>>>>> 1 file changed, 23 insertions(+) > >>>>>>>>>>>>> > >>>>>>>>>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c b/ > >>>>>>>>>>>>> drivers/ gpu/ drm/amd/amdgpu/amdgpu_bios.c > >>>>>>>>>>>>> index aa039e148a5e..86064c753b09 100644 > >>>>>>>>>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c > >>>>>>>>>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c > >>>>>>>>>>>>> @@ -26,6 +26,7 @@ > >>>>>>>>>>>>> * Jerome Glisse > >>>>>>>>>>>>> */ > >>>>>>>>>>>>> +#include <linux/firmware.h> > >>>>>>>>>>>>> #include "amdgpu.h" > >>>>>>>>>>>>> #include "atom.h" > >>>>>>>>>>>>> @@ -457,6 +458,28 @@ static bool amdgpu_get_bios_apu(struct > >>>>>>>>>>>>> amdgpu_device *adev) > >>>>>>>>>>>>> goto success; > >>>>>>>>>>>>> } > >>>>>>>>>>>>> + { > >>>>>>>>>>>>> + const struct firmware *fw; > >>>>>>>>>>>>> + char fw_name[32]; > >>>>>>>>>>>>> + size_t fw_size; > >>>>>>>>>>>>> + > >>>>>>>>>>>>> + snprintf(fw_name, sizeof(fw_name), "amdgpu/ > >>>>>>>>>>>>> %04x_%04x.bin", > >>>>>>>>>>>>> + adev->pdev->vendor, adev->pdev->device); > >>>>>>>>>>>>> + if (request_firmware(&fw, fw_name, adev->dev) == 0) { > >>>>>>>>>>>>> + adev->bios = kmemdup(fw->data, fw->size, > >>>>>>>>>>>>> GFP_KERNEL); > >>>>>>>>>>>>> + fw_size = fw->size; > >>>>>>>>>>>>> + release_firmware(fw); > >>>>>>>>>>>>> + if (!adev->bios || !check_atom_bios(adev, > >>>>>>>>>>>>> fw_size)) { > >>>>>>>>>>>>> + amdgpu_bios_release(adev); > >>>>>>>>>>>>> + } else { > >>>>>>>>>>>>> + adev->bios_size = fw_size; > >>>>>>>>>>>>> + dev_info(adev->dev, "Fetched VBIOS from > >>>>>>>>>>>>> firmware file %s\n", > >>>>>>>>>>>>> + fw_name); > >>>>>>>>>>>>> + goto success; > >>>>>>>>>>>>> + } > >>>>>>>>>>>>> + } > >>>>>>>>>>>>> + } > >>>>>>>>>>>>> + > >>>>>>>>>>>>> dev_err(adev->dev, "Unable to locate a BIOS ROM\n"); > >>>>>>>>>>>>> return false; > >>>>>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >> >
