#FAST SELF BOOTING CPU STRESS TEST SOFTWARE#
#FAST SELF BOOTING CPU STRESS TEST CODE#
#FAST SELF BOOTING CPU STRESS TEST WINDOWS#

But if you are more experience in decoding its crash dumps and just starting with ESXi – go ahead and do whatever you are more comfortable and proficient with 🙂

#FAST SELF BOOTING CPU STRESS TEST WINDOWS#

Of course you can get the crash on a Linux or Windows OS Live CD, but debugging the crash dumps or kernel panics might introduce some additional overhead. Second, when you have enough experience troubleshooting the insides of ESXi and understand how VMkernel, and the hardware it runs on top of ticks, you can more easily understand the logs (vmkernel.log and vmkwarning.log in this case) or PSODs. The question you might ask – why go through all this to stress test the physical hardware with a Virtual Machine running on top of a hypervisor? First, ESXi is tailored to be sensitive to any hardware anomalies and likes to tell you about it in its logs. Why Stress Test the Hardware on an ESXi Hypervisor and a Few Tips This means that the first processor plays a role in our ESXi host crashing as well, but it was pretty well hidden until a custom stress test was made – only the 2nd CPU has seemed to cause trouble when the stress test was spanning both NUMA nodes. Now, we see that we have unfortunately run into an Internal unclassified error – looking at the note a condition must be satisfied that at least one X must equal to one, and that is true.

#FAST SELF BOOTING CPU STRESS TEST CODE#

That way you can better see the bits we need (61 and 57-55) to further debug.Ĭhecking the Simple Error Code Encoding table to gain further insight. Step 1: Convert the Hexadecimal String to Binary (I like ’s converter) and space it appropriately according to Figure 15-6 in the Manual.

#FAST SELF BOOTING CPU STRESS TEST SOFTWARE#

I’ll again be using the indispensable Intel® 64 and IA-32 Architectures Software Developer’s Manual (further referenced as “the Manual”) – the pictures below are courtesy of Intel Corporation and are taken from that manual.

I will try to be more detailed than in my previous article. Now let’s take a quick look at Processor 1’s MCE. In my previous article about stress testing the host’s memory the Processor 2’s MCE was debugged there and was shown to be indeed a Generic TransBus Error. Processor 2: 0xFA001A4000020E0F – this has been reported when the whole NUMA node was tested.Processor 1: 0xB200000072000402 – this is the first time the error has been reported while stress testing with an affinity on the Second Physical CPU.The iLO has revealed that an MCE has appeared on both CPUs at the time of the crash.Īt the same time, both processors reported an MCE. This got passed down to the Guest OS where I could have chosen not only the classical CPU Cores overview but also NUMA Node overview – a very nice change that came with Windows Server 2012’s Task Manager. The VM was configured to be aligned with the host’s NUMA Architecture, so I have configured 2 Sockets with 12 Cores Each. Therefore this host is composed of two NUMA nodes, each containing 12 Physical Cores and in total 24 Logical Cores (including the HyperThreaded ones) – I have chosen a methodical approach – first spanning on both NUMA nodes and then testing separately on each node.įor the first test, I have spanned this VM across all 24 Physical Cores, supported with 128 GB RAM – that is much more than I would have needed – but hey, it’s a VM on a host that has been put aside for testing – so why not :).

Inside the server, the CPU that needs to be tested is a Dual-Socket 12-Core Xeon and this is the only thing that will be of interest to us. Stress Test VM Configuration and Its Alignment With Physical Hardware I have taken a closer look at the matter and went to stress thest this ill host’s CPUs. From the start I had a hunch that the second Physical CPU or a System Board are faulty – but these were replaced already and the host has crashed yet again. The host has crashed several times into a PSOD with Uncorrectable Machine Check Errors. I will be using a Windows VM again, but this time it will be Windows Server 2012 Standard Edition that can handle up to 4TB Memory and up to 64 Sockets containing 640 logical processors – a very nice bump from Windows Server 2008 R2 Standard that had a Compute configuration maximum of 4 sockets and 32 GB RAM. I have done a Memory Stress Test using a Windows VM in a previous article. I have needed to stress test a component inside a physical server – this time it was CPU and I’d like to share my method here.

Fast self booting cpu stress test