Hello, I own the mb in subject and am having issues booting Windows 10 with VT-D enabled, if I disable it all works fine but when it is enabled i can't boot, it gets stuck at the win10 blue logo. Anyone can help me fixing this issue for the bios on this mb?
Thanks in advance
Here is the link to the latest BIOS version -
https://www.supermicro.com/Bios/softfile...38_709.zip
Hoping for some support, attached the extracted dsdt from the mainbord in subject. Thx in advance
(04-16-2022, 11:49 AM)dnsound Wrote: [ -> ]am having issues booting Windows 10 with VT-D enabled
What about other windows system versions? The same?
Have you tried with vt-x off and vt-d on?
(05-16-2022, 10:08 AM)Maxinator500 Wrote: [ -> ] (04-16-2022, 11:49 AM)dnsound Wrote: [ -> ]am having issues booting Windows 10 with VT-D enabled
What about other windows system versions? The same?
Have you tried with vt-x off and vt-d on?
Hi, win10 boots until I install or update to v1809 . the issue only affect vt-d, tried with "Intel Virtualization" both On and Off and without vt-d enabled in the bios it boots fine , but i can't use virtualization software or get a working hyper-v, if I enable vt-d it won't boot no matter what I try . Also tried installing win11 with no avail, havent tried with vt-d disabled .
Booting ubuntu, in the dmesg I get lots of messages pointing to bad ACPI tables ; if needed i can post the output of dmesg here.
(05-16-2022, 10:30 AM)dnsound Wrote: [ -> ]if needed i can post the output of dmesg here
Yes, please. If it turns out that these messages are somehow related to virtualization, that'll help.
(05-16-2022, 10:38 AM)Maxinator500 Wrote: [ -> ] (05-16-2022, 10:30 AM)dnsound Wrote: [ -> ]if needed i can post the output of dmesg here
Yes, please. If it turns out that these messages are somehow related to virtualization, that'll help.
ok , attached the dmesg output
(05-16-2022, 10:51 AM)dnsound Wrote: [ -> ]attached the dmesg output
Thanks.
Check if disabling VT-d removes the following line from dmesg output: "
DMAR:[Firmware Bug]: Your BIOS is broken; bad RMRR".
(05-16-2022, 11:09 AM)Maxinator500 Wrote: [ -> ] (05-16-2022, 10:51 AM)dnsound Wrote: [ -> ]attached the dmesg output
Thanks.
Check if disabling VT-d removes the following line from dmesg output: "DMAR:[Firmware Bug]: Your BIOS is broken; bad RMRR".
Just tried, when booting with vt-d disabled the following lines are missing in the dmesg output:
ACPI: DMAR 0x00000000BF75E0D0 000138 (v01 AMI OEMDMAR 00000001 MSFT 00000097)
ACPI: Reserving DMAR table memory at [mem 0xbf75e0d0-0xbf75e207]
[ 2.694343] DMAR: Host address width 40
[ 2.698221] DMAR: DRHD base: 0x000000fbffe000 flags: 0x1
[ 2.703585] DMAR: dmar0: reg_base_addr fbffe000 ver 1:0 cap c90780106f0462 ecap f020fe
[ 2.711560] DMAR: RMRR base: 0x000000000e7700 end: 0x000000000eb6ff
[ 2.717872] DMAR: [Firmware Bug]: Your BIOS is broken; bad RMRR [0x00000000000e7700-0x00000000000eb6ff]
BIOS vendor: American Megatrends Inc.; Ver: 2.2 ; Product Version: 1234567890
[ 2.735760] DMAR: RMRR base: 0x000000bf7ec000 end: 0x000000bf7fffff
[ 2.742072] DMAR: ATSR flags: 0x0
[ 2.745433] DMAR-IR: IOAPIC id 8 under DRHD base 0xfbffe000 IOMMU 0
[ 2.751832] DMAR-IR: IOAPIC id 9 under DRHD base 0xfbffe000 IOMMU 0
[ 2.758619] DMAR-IR: Enabled IRQ remapping in xapic mode
I have some opinion on why enabling VT-d resulting in these messages to show up, but do not take my words for the pure truth.
Here's how I would interpret it: VT-d requires RMRR regions and ubuntu tries to determine them by taking memory adresses specified in the firmware. And as far as I understand, the kernel has algorithms of PMRR sanity check, which detect a failure as you can see.
(05-16-2022, 11:41 AM)dnsound Wrote: [ -> ][ 2.711560] DMAR: RMRR base: 0x000000000e7700 end: 0x000000000eb6ff
[ 2.717872] DMAR: [Firmware Bug]: Your BIOS is broken; bad RMRR [0x00000000000e7700-0x00000000000eb6ff]
And then kernel corrects adresses so ubuntu can boot?!
(05-16-2022, 11:41 AM)dnsound Wrote: [ -> ][ 2.735760] DMAR: RMRR base: 0x000000bf7ec000 end: 0x000000bf7fffff
Just imagine what if the windows update v1809 introduced something like this algorithm, but without the auto-correction feature.
I'll think about what can be done about it.
EDIT:
I looked for PMRR base in the bios image and I went through some information on the net, but nothing came of it.
I can't solve this problem.