Re: [RFC PATCH 0/1] vfio/pci: Wait for GB202 firmware after reset
From: Gustavo Andrade
Date: Sat Nov 14 2026 - 20:48:06 EST
Hi Jason,
Thanks for the feedback. I submitted this as an RFC because, while the
workaround solved the issue for me, it seemed unusual that only my
card required it, since I haven't seen recent reports of this issue.
How would you suggest I proceed? I am currently running the latest
VBIOS available for my card (Palit RTX 5090 GameRock, version
98.02.2E.80.10), which is also the most recent version listed in the
TechPowerUp database.
Best regards,
Gustavo Andrade
On Sat, Nov 14, 2026 at 10:44 PM Gustavo Andrade <gustavogyn@xxxxxxxxx> wrote:
>
> Hi Jason,
>
> Thanks for the feedback. I submitted this as an RFC because, while the workaround solved the issue for me, it seemed unusual that only my card required it, since I haven't seen recent reports of this issue.
>
> How would you suggest I proceed? I am currently running the latest VBIOS available for my card (Palit RTX 5090 GameRock, version 98.02.2E.80.10), which is also the most recent version listed in the TechPowerUp database.
>
> Best regards,
> Gustavo Andrade
>
>
> On Sat, Nov 14, 2026 at 8:58 PM Jason Gunthorpe <jgg@xxxxxxxxxx> wrote:
>>
>> On Sat, Nov 14, 2026 at 02:48:53AM +0000, Gustavo A. wrote:
>>
>> > PCI reset returns successfully while the Firmware Security Processor (FSP)
>> > is still initializing. Restricting BAR1 to 4 KiB mappings masks the problem.
>> > Waiting for FSP completion after reset restores normal output with stock
>> > KVM and verified 1 GiB BAR1 mappings.
>>
>> That doesn't really make any sense, you are probably hitting a race
>> condition somewhere since 1G/4k changes the timing. And possibly
>> because your new kernel versions boot VFIO faster than older ones.
>>
>> IIRC there was some VBIOS bug in old versions that caused issues with
>> vfio.
>>
>> VFIO should definately not be doing things like this.
>>
>> Jason