Minis forum MS-A2
- Thread starter freegate
- Start date
-
- Tags
- minisforum ms-01 ms-a2
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
There is a new Bios release for 7xxx CPUs as well: https://pc-file.s3.us-west-1.amazonaws.com/MS-A2/Bios/F1WSA_DRG_1.03_251216B+(7XXX+CPU).7z
I use the MS-A2 with the 9955HX on BIOS v1.02. A little tip that I want to share for those who use the PCIe slot: to overcome that the CPU boost speed is limited to 5040MHz (instead of 5440MHz in performance mode) when the PCIe slot is equipped with, for instance, an OCuLink card (you can then no longer select the Performance mode as the PowerLimit Setting is greyed-out), you can use the Curve Optimizer in the Precision Boost Overdrive menu.
In the BIOS, go to Advanced > AMD Overclocking > Precision Boost Overdrive
- Set Precision Boost Overdrive to Advanced
- Go to Curve Optimizer (not GFX Curve Optimizer!) and set the Curve Optimizer to All Cores
- Set the All Core Curve Optimizer Sign to Negative
- Set the All Core Curve Optimizer Magnitude to -30*
* This is a little bit of a silicon lottery thing, but if the system is not stable with this setting, you can lower it by -5 until it is (mine is perfectly stable on -30).
This minimizes temps a bit (although not as much as on a desktop CPU), but also makes sure the max CPU boost speed (of max. half the cores) returns to 5440MHz @ 1.280V without having to use a PBO overclock. Performance will be improved a bit depending on the use case (my Passmark CPU-score went to 60,790). You can optimize single core performance a bit (and even surpass the single core performance of the 9950X) by combining it with a PBO overclock of +200MHz. This brings the max CPU boost speed of the fastest cores to 5640MHz @ 1.355V. This slightly hurts the multicore performance though (and generates more heat).
I would not advice to use above in combination with the TjMax reduction shared earlier (Minisforum MS-A2 9955HX temperature fix - ETCwiki) as the performance impact will be very negative.
If you only look for longevity, setting the TjMax to 78°C stays the best option (although the performance is then reduced by 5% and it's even bigger if you use the PCIe slot).
In the BIOS, go to Advanced > AMD Overclocking > Precision Boost Overdrive
- Set Precision Boost Overdrive to Advanced
- Go to Curve Optimizer (not GFX Curve Optimizer!) and set the Curve Optimizer to All Cores
- Set the All Core Curve Optimizer Sign to Negative
- Set the All Core Curve Optimizer Magnitude to -30*
* This is a little bit of a silicon lottery thing, but if the system is not stable with this setting, you can lower it by -5 until it is (mine is perfectly stable on -30).
This minimizes temps a bit (although not as much as on a desktop CPU), but also makes sure the max CPU boost speed (of max. half the cores) returns to 5440MHz @ 1.280V without having to use a PBO overclock. Performance will be improved a bit depending on the use case (my Passmark CPU-score went to 60,790). You can optimize single core performance a bit (and even surpass the single core performance of the 9950X) by combining it with a PBO overclock of +200MHz. This brings the max CPU boost speed of the fastest cores to 5640MHz @ 1.355V. This slightly hurts the multicore performance though (and generates more heat).
I would not advice to use above in combination with the TjMax reduction shared earlier (Minisforum MS-A2 9955HX temperature fix - ETCwiki) as the performance impact will be very negative.
If you only look for longevity, setting the TjMax to 78°C stays the best option (although the performance is then reduced by 5% and it's even bigger if you use the PCIe slot).
Last edited:
Thanks @RafiThissen
I tried these settings from the ETCwiki a few months ago, but the performance impact was too high for me because I'm using the 7945HX CPU. So for anybody who is using these settings, you will experience much worse performance with the 7945HX CPU if you are running Proxmox.
In the end, I changed the following to reduce the temperatures:
I'll give your settings a try to see the difference. Many thanks!
I tried these settings from the ETCwiki a few months ago, but the performance impact was too high for me because I'm using the 7945HX CPU. So for anybody who is using these settings, you will experience much worse performance with the 7945HX CPU if you are running Proxmox.
In the end, I changed the following to reduce the temperatures:
- Precision Boost Overdrive: Advanced > Set CPU Boost Clock Override to "Enabled (Negative)" -> Set Max CPU Boost Clock Override (-) to 1000
- Advanced > Power Limit Setting: Balanced
I'll give your settings a try to see the difference. Many thanks!
Hello everyone, I’m running an MS-A2 9955HX with BIOS 1.03 and Proxmox 9.2.5, and I’m having issues with PCI passthrough to a Linux VM.
VM fails to boot with any PCI passthrough including any GPU, or even onboard PCI SFP NIC.
Is anyone using BIOS 1.03 able to successfully configured PCI passthrough?
VM fails to boot with any PCI passthrough including any GPU, or even onboard PCI SFP NIC.
Is anyone using BIOS 1.03 able to successfully configured PCI passthrough?
Last edited:
same issue,witch bios 1.0.3 fix the midrocode problem ,but all passthrough get down.
Has anyone updated to 1.03 with a 7945HX CPU? Are there any known issues? I'm a bit afraid to update after reading this thread. :/
the root cause is the lack of DMA protection On / Off option in MS-A2 BIOS. Unlike other major MB manufacturers, BIOS options are very limited for this workstation class machine, and constantly evolving OS security features, makes this device vulnerable to be caught in such corners. I hope they keep up with more frequent BIOS updates to compensate for the lack of configurability options. Waiting for the subsequent BIOS update soon !!
@jdtx @zzjin - update on the BIOS 1.03 PCIe passthrough issue.
I opened a support ticket with Minisforum and sent them a full diagnostic bundle. They have now confirmed it:
--- ROOT CAUSE ---
For anyone interested, here is what actually breaks. The IVRS ACPI table published by BIOS 1.03 contains three IVMD subtables that do not exist in 1.02:
The device range 0x0000-0x0FFF covers the entire PCI segment, so these three small firmware regions get applied to every device on the machine instead of just the one that needs them. The Linux AMD IOMMU driver turns them into mandatory 1:1 mappings, and VFIO refuses any device carrying a RESV_DIRECT region.
You can check it yourself on any device:
And to dump the table yourself:
On my unit all 36 PCI devices report this, which is why it hits the integrated AMD GPU, an NVIDIA card and the onboard SFP+ NIC alike. It is not device or vendor specific.
The flag combination is also internally inconsistent: Exclusion Range is set while Unity, Readable and Writeable are all cleared.
Worth noting: the kernel runs with
--- ON DOWNGRADING ---
Minisforum also suggested a workaround I had not seen mentioned here:
If anyone attempts it, please report back, and get written confirmation from support about warranty coverage first.
Also be careful with the file: the 9000-series build is
--- SUGGESTION ---
If you are affected, open a ticket too. One report gets logged; several from paying customers tend to move faster. Mentioning "IVRS/IVMD entries" and "DMA protection" seems to help it reach the right people.
I have asked them to notify me when 1.04 lands and offered to test a beta build. Will post here if anything comes of it.
I opened a support ticket with Minisforum and sent them a full diagnostic bundle. They have now confirmed it:
So: acknowledged and escalated, but no ETA for 1.04.
--- ROOT CAUSE ---
For anyone interested, here is what actually breaks. The IVRS ACPI table published by BIOS 1.03 contains three IVMD subtables that do not exist in 1.02:
Code:
Subtable Type : 22 (IVMD - device range)
Flags : 08 (Exclusion Range = 1; Unity, Readable, Writeable = 0)
DeviceId : 0000 <- start of range
Auxiliary Data : 0FFF <- end of range
Start Address : 0xB3088000 / 0xB5E8F000 / 0xB5E90000 (4 KB each)You can check it yourself on any device:
Code:
cat /sys/bus/pci/devices/0000:01:00.0/iommu_group/reserved_regions
0x00000000b3088000 0x00000000b3088fff direct
0x00000000b5e8f000 0x00000000b5e90fff direct
Code:
apt install acpica-tools
acpidump -n IVRS -b && iasl -d ivrs.dat && grep -A6 IVMD ivrs.dslThe flag combination is also internally inconsistent: Exclusion Range is set while Unity, Readable and Writeable are all cleared.
Worth noting: the kernel runs with
iommu: Default domain type: Translated (no iommu=pt), which is exactly what VFIO wants, and it still fails. So no kernel parameter works around this.--- ON DOWNGRADING ---
Minisforum also suggested a workaround I had not seen mentioned here:
So: reflash 1.03 over 1.03 first, THEN install 1.02. My guess is that this two-step procedure exists precisely because of the bootblock, and that going straight from 1.03 to 1.02 is what bricked @Brian Stretch's unit - but that is speculation on my part, support did not explain the reasoning.
If anyone attempts it, please report back, and get written confirmation from support about warranty coverage first.
Also be careful with the file: the 9000-series build is
F1WSA_FRG (Fire Range), the 7000-series one is F1WSA_DRG (Dragon Range). They are not interchangeable. Minisforum pulled the 1.02 FRG download, so ask support for an official link rather than using a mirror.--- SUGGESTION ---
If you are affected, open a ticket too. One report gets logged; several from paying customers tend to move faster. Mentioning "IVRS/IVMD entries" and "DMA protection" seems to help it reach the right people.
I have asked them to notify me when 1.04 lands and offered to test a beta build. Will post here if anything comes of it.
Hi all,
I'm trying to fit an NVMe heatsink under the SSD/10G fan on the storage side of the MS-A2, and I'm having trouble finding a precise clearance measurement.
Has anyone actually measured the gap between the M.2 PCB and the fan blades on the three M.2 slots (especially once the fan is remounted)? I've seen a post elsewhere mentioning that a "standard" heatsink barely cleared the fan on at least one slot, but no exact figures.
Specifically, I'm considering a ~3mm aluminum finned heatsink + a thin thermal pad (~0.5-1mm) on top of the Crucial T500's stock label , does that combined stack-up (roughly 3.5-4mm total) clear the fan, or is that too tall for at least some of the slots?
Any real-world experience (with or without heatsinks)
Just trying to get my ssd cooler....
I'm trying to fit an NVMe heatsink under the SSD/10G fan on the storage side of the MS-A2, and I'm having trouble finding a precise clearance measurement.
Has anyone actually measured the gap between the M.2 PCB and the fan blades on the three M.2 slots (especially once the fan is remounted)? I've seen a post elsewhere mentioning that a "standard" heatsink barely cleared the fan on at least one slot, but no exact figures.
Specifically, I'm considering a ~3mm aluminum finned heatsink + a thin thermal pad (~0.5-1mm) on top of the Crucial T500's stock label , does that combined stack-up (roughly 3.5-4mm total) clear the fan, or is that too tall for at least some of the slots?
Any real-world experience (with or without heatsinks)
Just trying to get my ssd cooler....
@VivienM I'm also getting spontaneous reboots. Interesting enough, it's only been happening on one of my MS-A2s (I have three). They are all configured exactly the same. I see this inside dmesg once it comes back up:
x86/amd: Previous system reset reason [0x00800800]: internal CPU shutdown event occurred
Okay, meanwhile I get
[ 0.934974] x86/amd: Previous system reset reason [0x00300800]: software wrote 0xE to reset control register 0xCF9
[ 0.934976] x86/amd: Previous system reset reason [0x00300800]: ACPI power state transition occurred
Makes me wonder if it's the same problem or a different problem.
What kernel are you using, and have you tried 6.14.8?
Sorry for the late reply. I am on kernel 6.18, and I don't believe it was happening on kernel 6.12.
I used to get those same reset reasons, and I figured it was the Intel GPU I had in the PCIe x16 slot. So I reset my nodes and removed that card. Haven't seen those exact ones since. It's always 0x00800800.
EDIT: It was due to the memory bandwidth on this particular machine. I had to drop 5600 to 5200 MHz and it's been stable since.
Last edited:
@Harlotboring
post #351 was exactly my problem, thank you for the info. flashing 1.03 over again caused an odd issue, uefi shell wouldn't load after and i couldn't disable secure boot, but after a few more reboots it finally started working normally, not sure what that was about. downgrade to 1.02 went smoothly. I've now got a running lxc with gpu passed through.
post #351 was exactly my problem, thank you for the info. flashing 1.03 over again caused an odd issue, uefi shell wouldn't load after and i couldn't disable secure boot, but after a few more reboots it finally started working normally, not sure what that was about. downgrade to 1.02 went smoothly. I've now got a running lxc with gpu passed through.
MS-A2 BIOS 1.03 breaks PCIe passthrough ("1:1 IOMMU mapping"): root cause + working fix without downgrading
TL;DR: Every BIOS 1.03 build I know of, including the latest 04/01/2026 re-release, ships an ACPI IVRS table that marks every PCI device on buses 00-0F as needing a forced 1:1 IOMMU mapping. VFIO then refuses to pass through any device: GPU, NIC, NVMe, SR-IOV VFs, all of them. No BIOS setting or kernel version fixes it. You can downgrade to 1.02, or stay on 1.03 and load a corrected IVRS table from the initrd. I did the second; details below.
Setup
Symptoms
The VM fails to start. QEMU says:
and dmesg has the real reason:
It happens for whole devices (PFs) and for VFs alike.
Quick check: are you affected?
On 1.03 I got a "direct" entry in every IOMMU group (28 of 28):
Any number above 0 means passthrough of those devices is blocked.
Root cause
1.03 added three IVMD (memory definition) entries to the IVRS table:
Linux treats exclusion ranges as read/write unity maps, so each device in the range gets a non-relaxable IOMMU_RESV_DIRECT region. Since kernel 6.x, VFIO refuses to attach any device that has a "require direct" region. The range 0x0000-0x0FFF covers every bus, so nothing can be passed through.
A 1.02 table doesn't have these entries. Removing them restores 1.02 behaviour.
What I/others tried that does NOT help: other kernels (6.17, 7.0.x), removing iommu=pt, toggling Above 4G / ReBAR / ACS in the BIOS, pcie_acs_override, legacy VFIO vs iommufd. "amd_iommu=relax_unity" has been mentioned but isn't in any PVE kernel.
Option A: downgrade to 1.02
F1WSA_FRG_1.02_250616a. Per Minisforum support (see earlier posts in this thread), reflash 1.03 over 1.03 first, then flash 1.02. Going straight from 1.03 to 1.02 reportedly bricked at least one unit.
Option B: stay on 1.03 and override the IVRS table (what I did)
The PVE kernel has CONFIG_ACPI_TABLE_UPGRADE=y, so it can load a replacement ACPI table from an uncompressed cpio at the front of the initrd. No kernel recompile.
1. Build the corrected table
Install acpica-tools. If the host has no internet, download the .deb elsewhere and copy it over; it only depends on libc6:
Keep everything before the first IVMD and bump the OEM revision. The kernel only replaces a table if the new one has a higher revision:
Sanity checks: disassemble IVRS.aml again and diff it against the original. The only differences should be table length (0x128 -> 0xC8), checksum, OEM revision and compiler ID, plus the three missing IVMD blocks. I also byte-compared the IVHD part, and it's identical:
2. Load it from the initrd with an initramfs-tools hook
The Proxmox forum guide uses GRUB_EARLY_INITRD_LINUX_CUSTOM with a cpio in /boot. On proxmox-boot-tool systems (ZFS root, kernels/initrds copied to the ESPs) I didn't want to rely on that. A hook that calls prepend_earlyinitramfs (the same mechanism microcode uses) puts the table inside every initrd. That works for GRUB and systemd-boot, and every future kernel upgrade picks it up automatically.
3. (Optional) Test boot with automatic rollback (GRUB)
The MS-A2 has no remote console, so I wanted a boot that rolls itself back if it hangs. Note: on GRUB, proxmox-boot-tool kernel pin <ver> --next-boot is NOT a real one-shot. It writes a fixed "set default=" into the ESP grub.cfg and only proxmox-boot-cleanup.service clears it, after a successful boot, so a hang would boot the same kernel again. GRUB's own next_entry is a real one-shot (GRUB clears it before it boots):
4. Verify
No AMD-Vi errors or IO_PAGE_FAULTs, and the VM with both E810 VFs started on boot again. Once it works, rebuild the other kernels too with update-initramfs -u -k all if you want them as fallbacks with passthrough working.
Undo / when a fixed BIOS ships
Do this before or right after flashing a new BIOS. Otherwise the old patched copy of the 1.03 table keeps replacing whatever the new BIOS provides. If a future BIOS is still broken, rebuild the .aml from that BIOS's table; don't reuse the 1.03 one.
Caveats
Hopefully Minisforum fixes the IVMD entries in 1.04. Until then this lets you stay on 1.03 without the risky downgrade.
TL;DR: Every BIOS 1.03 build I know of, including the latest 04/01/2026 re-release, ships an ACPI IVRS table that marks every PCI device on buses 00-0F as needing a forced 1:1 IOMMU mapping. VFIO then refuses to pass through any device: GPU, NIC, NVMe, SR-IOV VFs, all of them. No BIOS setting or kernel version fixes it. You can downgrade to 1.02, or stay on 1.03 and load a corrected IVRS table from the initrd. I did the second; details below.
Setup
- MS-A2 (9955HX), BIOS 1.03, dated 04/01/2026 per dmidecode (the re-release that was reported as "works fine")
- Proxmox VE 9, kernel 7.0.14-20-pve, ZFS root, GRUB through proxmox-boot-tool
- Intel E810-XXV dual-port. The host keeps the PFs on the ice driver (for DDP); one SR-IOV VF per port goes to an OPNsense/Linux router VM
- Passthrough worked on 1.02. After flashing 1.03 it broke completely.
Symptoms
The VM fails to start. QEMU says:
Code:
kvm: -device vfio-pci,host=0000:07:01.0,...: vfio 0000:07:01.0: failed to setup container for group 28: Failed to set group container: Invalid argument
Code:
vfio-pci 0000:07:01.0: Firmware has requested this device have a 1:1 IOMMU mapping, rejecting configuring the device without a 1:1 mapping. Contact your platform vendor.Quick check: are you affected?
Code:
cat /sys/kernel/iommu_groups/*/reserved_regions | grep -c direct
Code:
0x00000000b2da4000 0x00000000b2da4fff direct
0x00000000b5e45000 0x00000000b5e46fff direct
0x00000000fee00000 0x00000000feefffff msi
0x000000fd00000000 0x000000ffffffffff reservedRoot cause
1.03 added three IVMD (memory definition) entries to the IVRS table:
Code:
Subtable Type : 22 [Memory Definition Block (IVMD)] <- type 0x22 = device range
Flags : 08 -> Unity 0, Readable 0, Writeable 0, Exclusion Range 1
DeviceId : 0000
Auxiliary Data: 0FFF <- end of range: devices 00:00.0 .. 0F:1F.7 = everything
Start Address : 00000000B5E46000 Length 0x1000
(same again for B5E45000 and B2DA4000)A 1.02 table doesn't have these entries. Removing them restores 1.02 behaviour.
What I/others tried that does NOT help: other kernels (6.17, 7.0.x), removing iommu=pt, toggling Above 4G / ReBAR / ACS in the BIOS, pcie_acs_override, legacy VFIO vs iommufd. "amd_iommu=relax_unity" has been mentioned but isn't in any PVE kernel.
Option A: downgrade to 1.02
F1WSA_FRG_1.02_250616a. Per Minisforum support (see earlier posts in this thread), reflash 1.03 over 1.03 first, then flash 1.02. Going straight from 1.03 to 1.02 reportedly bricked at least one unit.
Option B: stay on 1.03 and override the IVRS table (what I did)
The PVE kernel has CONFIG_ACPI_TABLE_UPGRADE=y, so it can load a replacement ACPI table from an uncompressed cpio at the front of the initrd. No kernel recompile.
1. Build the corrected table
Install acpica-tools. If the host has no internet, download the .deb elsewhere and copy it over; it only depends on libc6:
Code:
# trixie / PVE 9:
# http://deb.debian.org/debian/pool/main/a/acpica-unix/acpica-tools_20250404-1_amd64.deb
dpkg -i acpica-tools_20250404-1_amd64.deb
mkdir -p /root/ivrs && cd /root/ivrs
cp /sys/firmware/acpi/tables/IVRS IVRS.orig.dat
iasl -d IVRS.orig.dat # -> IVRS.orig.dsl
grep -n "Subtable Type" IVRS.orig.dsl # the three type-22 IVMD entries are the LAST subtables
Code:
n=$(grep -n "Subtable Type : 22" IVRS.orig.dsl | head -1 | cut -d: -f1)
head -n $((n-1)) IVRS.orig.dsl | sed 's/\(Oem Revision : \)00000001/\100000002/' > IVRS.dsl
iasl IVRS.dsl # -> IVRS.aml, 200 bytes (was 296)
Code:
cmp -l <(head -c 200 IVRS.orig.dat) IVRS.aml # only header bytes 5,6,10,25,29-36 differThe Proxmox forum guide uses GRUB_EARLY_INITRD_LINUX_CUSTOM with a cpio in /boot. On proxmox-boot-tool systems (ZFS root, kernels/initrds copied to the ESPs) I didn't want to rely on that. A hook that calls prepend_earlyinitramfs (the same mechanism microcode uses) puts the table inside every initrd. That works for GRUB and systemd-boot, and every future kernel upgrade picks it up automatically.
Code:
mkdir -p /etc/initramfs-tools/acpi
cp /root/ivrs/IVRS.aml /etc/initramfs-tools/acpi/ivrs.aml
cat > /etc/initramfs-tools/hooks/acpi-ivrs-override <<'EOF'
#!/bin/sh
# Prepend patched ACPI IVRS (MS-A2 BIOS 1.03: IVMD 0000-0FFF entries removed).
# Remove this hook + run update-initramfs -u -k all once the BIOS is fixed.
PREREQ=""
prereqs() { echo "$PREREQ"; }
case "$1" in prereqs) prereqs; exit 0 ;; esac
. /usr/share/initramfs-tools/hook-functions
AML=/etc/initramfs-tools/acpi/ivrs.aml
[ -f "$AML" ] || exit 0
TMP=$(mktemp -d)
mkdir -p "$TMP/kernel/firmware/acpi"
cp "$AML" "$TMP/kernel/firmware/acpi/ivrs.aml"
(cd "$TMP" && find kernel | cpio -H newc -o --quiet) > "$TMP.cpio"
prepend_earlyinitramfs "$TMP.cpio"
rm -rf "$TMP" "$TMP.cpio"
EOF
chmod +x /etc/initramfs-tools/hooks/acpi-ivrs-override
# rebuild ONLY the current kernel's initrd first; older kernels stay untouched as a fallback
update-initramfs -u -k $(uname -r)
lsinitramfs /boot/initrd.img-$(uname -r) | grep ivrs # kernel/firmware/acpi/ivrs.amlThe MS-A2 has no remote console, so I wanted a boot that rolls itself back if it hangs. Note: on GRUB, proxmox-boot-tool kernel pin <ver> --next-boot is NOT a real one-shot. It writes a fixed "set default=" into the ESP grub.cfg and only proxmox-boot-cleanup.service clears it, after a successful boot, so a hang would boot the same kernel again. GRUB's own next_entry is a real one-shot (GRUB clears it before it boots):
Code:
proxmox-boot-tool kernel pin <older-known-good-kernel> # persistent default = old initrd, no override
proxmox-boot-tool refresh
E="gnulinux-advanced-<id>>gnulinux-<new-kernel>-advanced-<id>" # IDs: grep menuentry_id_option /boot/grub/grub.cfg
for u in $(cat /etc/kernel/proxmox-boot-uuids); do
m=$(mktemp -d); mount /dev/disk/by-uuid/$u $m
grub-editenv $m/grub/grubenv set next_entry="$E"
umount $m; rmdir $m
done
reboot
# hang -> power cycle -> boots the pinned old kernel without the override
# OK -> proxmox-boot-tool kernel unpin && proxmox-boot-tool refresh
# (and grub-editenv <esp>/grub/grubenv unset next_entry on the ESP that didn't boot)
Code:
# dmesg | grep -i "table upgrade\|ACPI: IVRS"
ACPI: IVRS ACPI table found in initrd [kernel/firmware/acpi/ivrs.aml][0xc8]
ACPI: Table Upgrade: override [IVRS- AMD -AmdTable]
ACPI: IVRS 0x00000000B9ED6000 0000C8 (v02 AMD AmdTable 00000002 INTL 20250404)
# cat /sys/kernel/iommu_groups/*/reserved_regions | grep -c direct
0Undo / when a fixed BIOS ships
Code:
rm /etc/initramfs-tools/hooks/acpi-ivrs-override /etc/initramfs-tools/acpi/ivrs.aml
update-initramfs -u -k all
rebootCaveats
- The firmware presumably wanted those three 4K pages excluded for some reason (they sit in or near BIOS-reserved memory). Ignoring them has been fine for me and others so far, and 1.02 didn't have them, but Minisforum hasn't said what they're for.
- A malformed override table is simply ignored by the kernel (you just get the 1:1 error again), so the risk to booting is low. Still keep a fallback kernel, as above.
- Unrelated gotcha: after flashing, the BIOS turned the WiFi card back on, which shifted my E810 from bus 07 to 08 and broke the hostpci/VF addresses. Re-check your PCIe devices after any BIOS flash.
Hopefully Minisforum fixes the IVMD entries in 1.04. Until then this lets you stay on 1.03 without the risky downgrade.