So, here I am bumping a necro-thread. Why? Because I've had this exact error on a new system that I bought just one week ago, and I've researched it this afternoon, and I now know the answer.
This exact machine check exception -- specifically, with "STATUS 0x90000040000f0005", or something very similar ending in 000f0005 -- is caused by Intel erratum HSD131. The exception is spurious and can therefore be ignored. For avoidance of doubt, it has nothing to do with temperatures, faulty motherboards or faulty memory.
See
Desktop 4th Generation Intel® Core™ Processor Family, Desktop Intel® Pentium® Processor Family, and Desktop Intel® Celeron® Processor Family Specification Update [intel.com, pdf] page 51:
Quote:
HSD131. Spurious Corrected Errors May be Reported
Problem: Due this erratum, spurious corrected errors may be logged in the IA32_MC0_STATUS register with the valid field (bit 63) set, the uncorrected error field (bit 61) not set, a Model Specific Error Code (bits [31:16]) of 0x000F, and an MCA Error Code (bits [15:0]) of 0x0005. If CMCI is enabled, these spurious corrected errors also signal interrupts.
Implication: When this erratum occurs, software may see corrected errors that are benign. These corrected errors may be safely ignored.
Workaround: None identified.
Status: For the steppings affected, see the Summary Table of Changes.
|
A list of the affected Intel processors is given on pages 17-20. There are quite a lot of them.
FreeBSD actually elides the error: see
https://lists.freebsd.org/pipermail/...il/070884.html
For me, it occurs only when executing 32-bit code, which presumably ties in with the mention of the IA32_MC0_STATUS register above. This probably explains why the net is full of people wrongly blaming this error on VMWare Player, qemu, etc. (see e.g.
https://bugs.launchpad.net/qemu/+bug/1307225)
