Hardware Issues - Revision history

Rf at 18:05, 5 December 2017

2017-12-05T18:05:40Z

Rf at 15:44, 15 February 2017

2017-02-15T15:44:28Z

Rf at 15:40, 15 February 2017

2017-02-15T15:40:13Z

Rf at 17:04, 9 January 2017

2017-01-09T17:04:26Z

Rf at 17:00, 9 January 2017

2017-01-09T17:00:10Z

Rf at 18:28, 16 December 2016

2016-12-16T18:28:14Z

Rf at 18:13, 16 December 2016

2016-12-16T18:13:01Z

Rf at 18:08, 16 December 2016

2016-12-16T18:08:26Z

Rf at 18:03, 16 December 2016

2016-12-16T18:03:35Z

Rf at 17:41, 16 December 2016

2016-12-16T17:41:28Z

@@ Line 13: / Line 13: @@
 * Contact email is '''gold@xma.co.uk'''
 * Contact number is '''01727 201 850'''
-* Favourite contact: Doshunn. Least favourite contact: Bradley.
+* Favourite contact: Manmeet. Failing him, Doshunn. Least favourite contact: Bradley.
 * Local engineer is Graeme Akers, tel. 07970 444162, but he can only be contacted via central support.

@@ Line 150: / Line 150: @@
          Interleaved Data Depth: Unknown
-Note how this refers to handle 0x023, which is P1_2B, bank locator 3, i.e. the fourth DIMM, the second of the second pair P1_2.
+Note how this refers to handle 0x023, which is P1_2B, bank locator 3 (bank locators are zero-indexed), i.e. the fourth DIMM, the second of the second pair P1_2.
 This information now allows us to write the following mail to '''gold@xma.co.uk'''

@@ Line 119: / Line 119: @@
          Rank: 2
-This is the last record, so marvin has 32 such banks, which most likely correspond to separate DIMMS. So the hunch right now is that one of these has been requiring all this correction. The dmidecode schema is as follows:
+This is the last record, so marvin has 32 such banks, which most likely correspond to separate DIMMS. So seeing as the error report are the same, the hunch right now is that one of these has been requiring all this correction. Now, the dmidecode schema is as follows for the memory is like so:
   P{1,2,3,4}_{1,2,3,4}{A,B}
-Correspnding to banks 0 to 31 of 16G each which is 512G RAM, correct.
+Corresponding to banks 0 to 31 of 16G each which is 512G RAM, correct.
-The syslogd warnings do not show one particular line, but this can be found in '''/var/log/messages''':
+In terms of the error reports blocks,  '''/var/log/messages''' contains one extra line that does not appear in the syslogd console warnings:
   EDAC MC0: CE page 0xc00b0e, offset 0xf80, grain 0, syndrome 0x100, row 0, channel 0, label "": amd64_edac
-It appears now that the '''MC4''' name in the warnings may be a bit of a red herring and that the problem is MC0. The fibrevillage link below shows you can append the CE page and offset address to give the address like so
+So, it appears now that the '''MC4''' name in the warnings may be a bit of a red herring and is some what generic. It seems that it is not specifying a particulr memory module. However, the problem does seem to be MC0. On conulting google, the fibrevillage link below yielded information whereby you can aggregate the '''CE page''' and '''offset''' addresses to give the following:
 xc00b0ef80
-This appears quite small and so is somewhat disconcerting, but what seems likely is that it's the veryfirst memory module that is causing the problems.
+This may appears quite small and therefore might not invite confidence, but it is also true that the misbehaving module amy resides in one of the very first slots.
   dmidecode -t 20

@@ Line 87: / Line 87: @@
   Message from syslogd@marvin at Nov  3 19:15:33 ...
-  kernel:[Hardware Error]: CPU:0 (15:2:0) MC4_STATUS[-|CE|MiscV|-|AddrV|-|-|CECC]: 0x9c00400001080813
+  kernel:[Hardware Error]: CPU:0 (15:2:0) MC4_STATUS[-|CE|MiscV|-|AddrV|-|-|CECC]: 0x9c00400001080a13
   Message from syslogd@marvin at Nov  3 19:15:33 ...

@@ Line 76: / Line 76: @@
   kernel:[Hardware Error]: cache level: L3/GEN, mem/io: MEM, mem-tx: RD, part-proc: RES (no timeout)
-There is a tool called '''edac-util''' whihc allows you to see errors, but it doesn't correlate with MC4, claiming in fact that it is MC0 that is correcting errors. Nevertheless when a warning comes in about MC4, the MC0:csrow0:ch0 DIMM coordinate gets incremented ... so the warnings do correlate with edac-util.
+There is a tool called '''edac-util''' which allows you to see errors, but it doesn't correlate with MC4, claiming in fact that it is MC0 that is correcting errors. Nevertheless when a warning comes in about MC4, the MC0:csrow0:ch0 DIMM coordinate gets incremented ... so the warnings do seem to correlate with edac-util's output.
 Back on 3 Nov there was also:
@@ Line 153: / Line 153: @@
 This information now allows us to write the following mail to '''gold@xma.co.uk'''
   Good evening,
-−
   Further to a recent phone call (25th November last), I discussed how to submit memory error correction events issue and though the server has not failed yet, the warnings have become so regular, one an hour, that I now would like to report it and request a new HMT42GR7MFR4C-PB 16GB memory unit.

@@ Line 33: / Line 33: @@
   dmesg -n 1
-The manpage for dmesg explains how this can be.
+The manpage for dmesg explains how this can be. NO. I'm afraid that was a little to easy. The technque is different. the file
 Here is one example from 16/12/2016

@@ Line 28: / Line 28: @@
 == Repeated memory warnings on marvin front-end ==
-Because these self correct (due to the RAM being expensive ECC RAM) it look as if these warnings can be safely ignored.
+Because these self correct (due to the RAM being expensive ECC RAM) it looks as if these warnings can be safely ignored.
-Unfortunately, all the users see them and are quite mystified by them.
+Unfortunately, all the users see them and are quite mystified by them. In fact this has been going on for some time, and there seesm to be an incredibly easy remedy:
 Here is one example from 16/12/2016

@@ Line 160: / Line 160: @@
   Please ask me for any further information.
-In the meantime here in the mainboard diagram is where the new DIM might go, if we get it:
+In the meantime here in the mainboard (dmidecode says the board is H8QGi-F) diagram is where the new DIM might go, if we get it:
 [[File:marvdimm.png]]
 == Node 2 shows only 110 GB RAM ==

← Older revision		Revision as of 18:03, 16 December 2016
Line 160:		Line 160:
	Please ask me for any further information.		Please ask me for any further information.

		+	In the meantime here in the mainboard diagram is where the new DIM might go, if we get it:
		+
		+	[[File:marvdimm.png]]

	== Node 2 shows only 110 GB RAM ==		== Node 2 shows only 110 GB RAM ==