On Tue, Nov 24, 2015 at 03:51:21PM +0000, Luck, Tony wrote: > >> Ok ... applied those two on top of my "UNTESTED" patch and injected an > >> error to force a UCNA log. > > > > Ok, what error type is that in EINJ nomenclature? I had only > > > > /sys/kernel/debug/apei/einj/available_error_type:0x00000002 Processor > > Uncorrectable non-fatal > > /sys/kernel/debug/apei/einj/available_error_type:0x00000008 Memory > > Correctable > > /sys/kernel/debug/apei/einj/available_error_type:0x00000010 Memory > > Uncorrectable non-fatal > > > > and I would've guessed it is the 0x10 type, i.e., the memory > > uncorrectable which is non-fatal - assuming here - but that one got > > promoted to a #MC on my box. > > I juggled with the type of the injection and the instruction sequence to > access the target > location. I used 0x10 to inject an uncorrected memory error with "# echo 1 > > notrigger" > to make sure the EINJ driver skipped the trigger actions. Then I had a user > mode test program > write a byte to the cache line. That pulled the uncorrected data into the > cache (which logged > the UCNA error signaled with CMCI). But the processor didn't actually consume > the poison > (no registers had corrupted data), so there was no machine check. > > Sneaky, huh?
That reminds me of the whitepaper: https://software.intel.com/sites/default/files/managed/b3/d1/MCA_Recovery_Validation_Guide.pdf Btw, should we take those tools here: https://git.kernel.org/cgit/linux/kernel/git/aegl/ras-tools.git and glue them together with a python or a shell script or so which goes and automatically takes care of loading einj.ko and injects the proper error type and thus abstracts away all that detail which makes me everytime look at Documentation/acpi/apei/einj.txt? Something like ./einject.py --ucna which would do all the fun? That would simplify our testing a lot, methinks. Hmmm? Oh, and btw, the box here didn't have the notrigger node, which means, it'll always do the trigger actions. :-\ -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
