Dual socket mining board bios moding and issues

So i given myself a task to mod an old ETH mining board and allow it to stretch it’s legs and finally use all of its available cores on dual E5-2650V2 cpu’s.

By default board comes with locked down bios without the ability to change the number of active cores, enable hyperthreading nor turbo. That did not sit well with me so i got to learning downloaded a few AMI bios modding tools a hex editor and a few other ancillary things. Long story short after a lot of trial and error i finally managed to enable all cores with hyperthreading and turbo boost now this is where the problems begin.

The mod was kinda sorta a success but it was not very stable when booted it would run indefinitely if it had no load applied but if i stress test it using s-tui then it will run for about 10 minutes before throwing an error:

CPUS NOT RESPONDING TO MCE BROADCAST

After a few of these, kernel shits its pants and initiates a reboot with 30 sec timer and that is that. Sometimes it will even just report a timeout on the cpu’s on boot and reboot. I am not sure what is causing this if its a hardware limitation fine nothing i can do about it it was a fun learning experience but i am suspecting there are missing pieces in the bios or some additional things that i need to modify in order to allow these additional cores to behave.

I suspect that it has something to do with it being dual socket but only having 1 dimm slot, maybe not ? Could it be that board creators applied some sort of voltage limit so when multiple cores are enabled its not enough and it becomes unstable ? I have tried turning turbo and ht off but the behavior does not change, it looks like its only the core count that is causing it. I have also update microcode to the latest available but with no change.

Board looks like this:

Original and modded bios files:
bios.zip (6.6 MB)

Any help would be greatly appreciated.

I’m not familiar with the board, but if you say it’s working fine until you apply load, my suspicions are either thermals or power constraints. Perhaps the CPUs were locked for that reason (e.g. underpowered VRM or insufficient cooling). I’d try to monitor both with slowly increased load.