guysensei8
Contributor
Contributor

VVMware ESXi 7.0.2 ReleaseBuild-17867351 giving PSOD after BIOS update

Hello and Happy Holidays All,

On my home server I was updating my BIOS trying to see if a future version would show further GPU options so maybe I could change a setting to get the code 43 to go away and my Nvidia P2000 would work on my Plex Server for transcoding. Unfortunately after I did this I received the purple screen of death that you see attached. As well, I attached information on my BIOS regarding a little on my hardware info. I'll admit it may have been ignorant to update my BIOS without considering what issues may come with it being a VMware host. Not sure if anyone has seen the attached error or knows a solution to it but it would be greatly appreciated! I know that if I turn off VT-d that ESXi 7.0.2 will boot up but then none of my Virtual Machines will boot up due to that setting being off. Again, thank you for anyone who can assist me with this issue! I am just an average computer support tech and have no professional experience with VMware but I like using it to host VMs so bear with me!

Thank You,

GuySensei

Labels (3)
0 Kudos
3 Replies
bluefirestorm
Champion
Champion

I run a Linux desktop on an Asus Z370 Prime II motherboard, so its UEFI menus would be similar to the Asus WS C246 motherboard. My experience with this Asus motherboard is that it resets almost everything back to default after a BIOS update.

I supposed you have seen this thread
https://communities.vmware.com/t5/VMware-vSphere-Discussions/ESXi-6-7u1-RMRR-overlaps-system-memory/...

The IBM x-Series UEFI "PCI 64-bit Resource Allocation" equivalent on Asus UEFI would be the "Above 4G decoding". I don't see the base memory window (maybe it will show up when the Above 4G decoding is disabled). The closest thing would be a Memory Remapping but the help text at the bottom suggests that is for when Above 4G decoding is enabled.

Which makes all of this a Catch-22. The "Above 4G decoding" is the VMware vmx equivalent of pciPassthru.enable64bitMMIO = "TRUE"; which to my knowledge for that to work, the host machine also needs to have MMIO addressing above 4GB address space also enabled.

Anyway, give those a try.

0 Kudos
guysensei8
Contributor
Contributor

Okay,

I know I saw that and I thought I turned it off when I went into the BIOS and it didn’t help but I’ll make sure I did disable it. I’ll get back to you to see what it does.

 

thank you,

 

guysensei8

0 Kudos
bluefirestorm
Champion
Champion

If you want to have some background about RMRR, there is this old Redhat whitepaper.

https://access.redhat.com/sites/default/files/attachments/rmrr-wp1.pdf

ESXi is not Linux. I refer to you the Redhat whitepaper because RMRR is part of Intel VT-d specification/rules. So ESXi would also have to aware of those VT-d specs. According to the Redhat paper a lot of motherboard makers don't really follow the RMRR spec/rules.

For UEFI settings, you could try Above 4G Decoding=Enabled, Memory Remapping=Disabled

Another possible thing to try is VT-d enabled, Above 4G Decoding enabled but add the following ESXi boot option (press Shift-O at the start of the "Loading VMware ESXi" screen)

panicOnInvalidRMRR=FALSE

The RedHat paper mentions the intention of RMRR is for legacy devices like USB, integrated graphics. So if that is the case you could try to disable any legacy device not used (USB, COM serial ports, shrink the Intel graphics memory, etc) but that's a complicated path to take.

Have you tried going back to the previous firmware version?