|
 |
06486d |
From 95e9590bfee2df447c8f4c0fd799e8c514beca80 Mon Sep 17 00:00:00 2001
|
|
|
06486d |
From: Denys Vlasenko <dvlasenk@redhat.com>
|
|
|
06486d |
Date: Tue, 10 Dec 2013 13:07:35 +0100
|
|
|
06486d |
Subject: [ABRT PATCH 24/27] doc/MCE_readme.txt: new file - documentation about
|
|
|
06486d |
MCE handling
|
|
|
06486d |
|
|
|
06486d |
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
|
|
|
06486d |
|
|
|
06486d |
Related to rhbz#1032077
|
|
|
06486d |
|
|
|
06486d |
Signed-off-by: Jakub Filak <jfilak@redhat.com>
|
|
|
06486d |
---
|
|
|
06486d |
doc/MCE_readme.txt | 86 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
|
|
06486d |
1 file changed, 86 insertions(+)
|
|
|
06486d |
create mode 100644 doc/MCE_readme.txt
|
|
|
06486d |
|
|
|
06486d |
diff --git a/doc/MCE_readme.txt b/doc/MCE_readme.txt
|
|
|
06486d |
new file mode 100644
|
|
|
06486d |
index 0000000..ed5b627
|
|
|
06486d |
--- /dev/null
|
|
|
06486d |
+++ b/doc/MCE_readme.txt
|
|
|
06486d |
@@ -0,0 +1,86 @@
|
|
|
06486d |
+ Background
|
|
|
06486d |
+
|
|
|
06486d |
+MCEs can be fatal (they panic kernel) or not.
|
|
|
06486d |
+Fatal MCE are delivered as exception#18.
|
|
|
06486d |
+Non-fatal ones sometimes are delivered as exception#18; other times
|
|
|
06486d |
+they are silently recorded in magic MSRs, CPU is not alerted.
|
|
|
06486d |
+Linux kernel periodically (up to 5 mins interval) reads those MSRs
|
|
|
06486d |
+and if MCE is seen there, it is piped in binary form through
|
|
|
06486d |
+/dev/mcelog to whoever listens on it. (Such as mcelog tool in
|
|
|
06486d |
+--daemon mode; but cat
|
|
|
06486d |
+
|
|
|
06486d |
+"Machine Check Exception:" message is printed *only* by fatal MCEs.
|
|
|
06486d |
+It will be caught as vmcore if kdump is configured.
|
|
|
06486d |
+
|
|
|
06486d |
+Non-fatal MCEs have "[Hardware Error]: Machine check events logged"
|
|
|
06486d |
+message in kernel log.
|
|
|
06486d |
+When /dev/mcelog is read, *no additional kernel log messages appear*.
|
|
|
06486d |
+
|
|
|
06486d |
+> Are those magic MSR registers cleared when read via /dev/mcelog?
|
|
|
06486d |
+
|
|
|
06486d |
+Yes.
|
|
|
06486d |
+
|
|
|
06486d |
+> Without mcelog utility, we can directly read only binary form, right?
|
|
|
06486d |
+> Not nice, but still useful, right?
|
|
|
06486d |
+> (could be transferred to nice text form on other machine).
|
|
|
06486d |
+
|
|
|
06486d |
+No, raw /dev/mcelog data is not easy to interpret on other machine.
|
|
|
06486d |
+In fact, it can't be used by mcelog tool even on the same machine.
|
|
|
06486d |
+Technical reason is that mcelog uses an obscure ioctl on /dev/mcelog
|
|
|
06486d |
+in order to know the size of binary blob with MCE information.
|
|
|
06486d |
+When run on a file, ioctl fails, and mcelog bombs out.
|
|
|
06486d |
+
|
|
|
06486d |
+Looks like without mcelog running and processing /dev/mcelog data,
|
|
|
06486d |
+non-fatal MCE's can't be easily decoded with currently existing tools.
|
|
|
06486d |
+
|
|
|
06486d |
+mcelog tool can be configured to write log to /var/log/mcelog
|
|
|
06486d |
+(RHEL6 does that) or to syslog (RHEL7 does that).
|
|
|
06486d |
+
|
|
|
06486d |
+
|
|
|
06486d |
+ How ABRT catches MCEs
|
|
|
06486d |
+
|
|
|
06486d |
+Fatal MCEs are caught as any fatal kernel panic is caught - as a vmcore.
|
|
|
06486d |
+The oops text, which goes to "backtrace" element, will be the decoded
|
|
|
06486d |
+MCE message from kernel log buffer.
|
|
|
06486d |
+
|
|
|
06486d |
+Non-fatal MCEs are caught as kernel oopses.
|
|
|
06486d |
+If "Machine check events logged" message is seen in "dmesg" element,
|
|
|
06486d |
+we assume it's a MCE, and create "not-reportable" element with suitable
|
|
|
06486d |
+explanation.
|
|
|
06486d |
+Then we check whether /var/log/mcelog exists,
|
|
|
06486d |
+or whether system log contains "mcelog: Hardware event",
|
|
|
06486d |
+and create a "comment" element with explanatory text, followed by
|
|
|
06486d |
+last 20 lines from either of those files.
|
|
|
06486d |
+
|
|
|
06486d |
+
|
|
|
06486d |
+ How to test MCEs
|
|
|
06486d |
+
|
|
|
06486d |
+There is an MCE injection tool and a kernel module, both named mce-inject.
|
|
|
06486d |
+(The tool comes from mce-test project, may be found in ras-utils RHEL7 package).
|
|
|
06486d |
+The script I used is:
|
|
|
06486d |
+
|
|
|
06486d |
+modprobe mce-inject
|
|
|
06486d |
+sync &
|
|
|
06486d |
+sleep 1
|
|
|
06486d |
+sync
|
|
|
06486d |
+# This can crash the machine:
|
|
|
06486d |
+echo "Injecting MCE from file $1"
|
|
|
06486d |
+mce-inject "$1"
|
|
|
06486d |
+echo "Exitcode:$?"
|
|
|
06486d |
+
|
|
|
06486d |
+It requires files which describe MCE to simulate. I grabbed a few examples
|
|
|
06486d |
+from mce-test.tar.gz (source tarball of mce-test project).
|
|
|
06486d |
+I used this this file to cause a non-fatal MCE:
|
|
|
06486d |
+
|
|
|
06486d |
+CPU 0 BANK 2
|
|
|
06486d |
+STATUS VAL OVER EN
|
|
|
06486d |
+
|
|
|
06486d |
+And this one to cause a fatal one:
|
|
|
06486d |
+
|
|
|
06486d |
+CPU 0 BANK 4
|
|
|
06486d |
+MCGSTATUS MCIP
|
|
|
06486d |
+STATUS FATAL S
|
|
|
06486d |
+RIP 12343434
|
|
|
06486d |
+MISC 11
|
|
|
06486d |
+
|
|
|
06486d |
+(Not sure what failures exactly they imitate, maybe there are better examples).
|
|
|
06486d |
--
|
|
|
06486d |
1.8.3.1
|
|
|
06486d |
|