While mcelog does some decoding of the MCA status register, more might be helpful.
Step 1
Download the combined Intel® 64 and IA-32 Architectures Software Developer Manuals from http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html It's massive at 3439 pages. The below refers to the September 2014 version.
Step 2
Take the STATUS word from /var/log/mcelog and pipe it through xxd a few times to get a bit field. For mine, this is:
$ echo "9000004000010005" | xxd -r -p | xxd -b
0000000: 10010000 00000000 00000000 01000000 00000000 00000001 ...@..
0000006: 00000000 00000101 ..
Step 3
Do some text manipulation and then number the bits:
66665555 55555544 44444444 33333333 33222222 22221111 111111
32109876 54321098 76543210 98765432 10987654 32109876 54321098 76543210
-----------------------------------------------------------------------
10010000 00000000 00000000 01000000 00000000 00000001 00000000 00000101
Step 4
Pull the status MCi status register bit definition from Section 15.3.2.2 of the manual:

In my case, bits 3:0 are saying "MCA Error Code 5" which is what mcelog has already interpreted for me as "Internal parity error" (see section 15.9.1). What I'm hoping for is more information - is the CPU, RAM or Motherboard the likely cause of the parity error?
The 1 in bit 63 just means "this register value is valid".
The 1 in bit 60 just means "error reporting is enabled". The value of [52:38] = 1 means one error has been corrected.
The 1 in bit 16 looks promising since it's sitting in the "Model Specific Error Code" field but, alas, according to section 16, bit [15] being equal to 0 means all I get is a 'simple' (not compound) error, so I'm done.
Bottom line: Can't tell if the parity error is from cache memory or system memory. Can't tell what "internal" means. Internal to what? So I swapped memory, same problem, then swapped CPU with another machine (got lucky, compatible sockets) and the problem stopped... on both machines. Not exactly the pinpoint diagnostic help I was hoping for from this advanced hardware, and I don't understand why the "bad" CPU is happy in another machine, but problem solved.