Yes, on both MSI and Asrock mobos. They’re practicing this universally now it looks like.
As above, could be a bug in the part of the BIOS contributed by AMD. Maybe not intentional, but due to it being AMD code shipped to the vendor, common across all of them…
Also, which BIOS versions for both boards?
edit:
checking release notes for most recent BIOS for my x470 taichi:
Improve add-on VGA compatibility with Raven processors.
Could be a bug related to that.
First bios from April for the Taichi also included updated AGESA which could also be bugged?
IDK it’s the same exact error / problem as the MSI board. Maybe they have the same feature “improvements” in their bios updates.
I’m not going to RMA the Asrock board yet. I’m definitely RMA’ing the MSI board since I bricked it. But I definitely just need a working motherboard for now. I’m gonna called Asrock on Friday and see if I can get them to help me revert the BIOS and report back here for anyone who is interested.
1 Like
I had some issues updating my BIOS on an Asrock x370. It was pre 3.30, and bugged out when I updated it to 3.30 (bridge bios) and then 4.something, but it did allow me to downgrade, then worked when I tried again.
So I was able to update to, and past the 3.something bridge bios.
I used VFIO on it before and after.
The UEFI wouldn’t boot any of the operating systems I had installed, but a fresh install and that worked too…
So maybe try again?
The issue affects all fresh installs of any linux distro and both AMD GPUs and NVIDIA GPUs, and evidently more than one AMD motherboard manufacturer. I’ve spent many many hours trying to resolve this issue. if you go to the Asrock Taichi x470 support page, then the BIOS download page, you’ll see the last four versions say “users will be unable to rollback”. That bit is intentional.
Hmm. Maybe the lack of downgrade is due to Ryzen 3000 specific features (for coming launch) and allowing downgrade could potentially end up with a user with a board that won’t work with their CPU, if they were to say, get a board with BIOS 3.x on it, a Ryzen 3000 and then try to downgrade it.
agesa 0072 I think? there’s a quirk for this though. known bug:
get used to compiling your own kernels buddy
Where do you get the error message?
I have a x470 taichi since yesterday. I updated it to Bios version 3.20 and i don´t see that error in my System logs.
I am passing through a Sapphire Nitro + Vega 64.
I disabled “ROM BAR” in virt-manager.
Edit: So i got the error some time after i shut down my windows VM.
1 Like
sorry I’m not used to putting my own bits of code in the kernel. Whereabouts do I put this bit of code exactly?
It’s a diff, the hint is here:
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
It is in your kernel souce directory, then drivers/pci/quirks.c
I’d suggest just waiting for a new kernel release that fixes it unless you’re keen on hacking kernel source and recompiling.
I used to compile custom kernels all the time back in the day but now can’t be bothered since about 2004. I’m not trying to fit linux on a 486 with 4MB RAM any more (and almost everything can be made a module now)… so not sure how much of a pain in the balls/time sink it is these days.
the last AMD agesa based issue took almost a year to correct IIRC, if he already uses vfio that may not be an option. no idea if this patch is even on their radar atm
this is for sure on the radar. I feel confident about MSI and Gigabyte having a workable solution before launch, but that might be same bios version with two agesas… not sure. I’m working on it now though.
2 Likes
good to know. I’ve been putting out fires in various vfio hobby channels for a while now on this one, and it’s been very frustrating for quite a few newcomers.
“oh, just compile a custom kernel” just isn’t an acceptable answer for a lot of people.
5 Likes
I’m perfectly happy compiling my own kernel if it fixes this problem. Thank you very much for the information! I will figure it out. I always do.
OK, I think I’ve done everything correctly to setup a patched compilation of the kernel (using arch). Do I need to alter that code you posted at all to in regards to those PCI-E addresses at the bottom to match my own? Or do they encompass all of my x16 slots? ./lsiommu.sh shows my card to be something that looks different from that patch, but it’s also formatted differently, so I’m not sure.
Sorry mate i’m not sure what the code does and i don’t run VFIO at the moment.
That diff shows the differences between two files under two different folders.
Other than that don’t have the time/inclination to investigate myself, sorry.
Can you show me where you found that patch at least? I need to read a bit more before I boot into this kernel. I’ve found similar looking patches with a google search, but not that particular version.
I’m not the one who posted it 
Woops, sorry, I meant to address my last couple of comments to you.