edac.txt: update information about newer Intel CPUs There's a chapter at edac.rst written by the time Nehalem support was added. Such information is used not only by the Nehalem driver (i7core_edac), but by all newer Intel CPU architectures that are supported by i7core_edac, sb_edac and sbx_edac drivers. Update the information to reflect that. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
diff --git a/Documentation/edac.txt b/Documentation/edac.txt index fba1930..0c9161c 100644 --- a/Documentation/edac.txt +++ b/Documentation/edac.txt
@@ -741,13 +741,25 @@ http://bluesmoke.sourceforge.net project site for EDAC. -Nehalem Usage of EDAC APIs --------------------------- +Usage of EDAC APIs on Nehalem and newer Intel CPUs +-------------------------------------------------- -Due to the way Nehalem exports Memory Controller data, some adjustments -were done at i7core_edac driver. This chapter will cover those differences +On older Intel architectures, the memory controller was part of the North +Bridge chipset. Nehalem, Sandy Bridge, Ivy Bridge, Haswell, Sky Lake and +newer Intel architectures integrated an enhanced version of the memory +controller (MC) inside the CPUs. -1) On Nehalem, there is one Memory Controller per Quick Patch Interconnect +This chapter will cover the differences of the enhanced memory controllers +found on newer Intel CPUs, such as ``i7core_edac``, ``sb_edac`` and +``sbx_edac`` drivers. + +.. note:: + + The Xeon E7 processor families use a separate chip for the memory + controller, called Intel Scalable Memory Buffer. This section doesn't + apply for such families. + +1) There is one Memory Controller per Quick Patch Interconnect (QPI). At the driver, the term "socket" means one QPI. This is associated with a physical CPU socket. @@ -757,7 +769,7 @@ The minimum known unity is DIMMs. There are no information about csrows. As EDAC API maps the minimum unity is csrows, the driver sequentially - maps channel/dimm into different csrows. + maps channel/DIMM into different csrows. For example, supposing the following layout:: @@ -780,8 +792,8 @@ Each QPI is exported as a different memory controller. -2) Nehalem MC has the ability to generate errors. The driver implements this - functionality via some error injection nodes: +2) The MC has the ability to inject errors to test drivers. The drivers + implement this functionality via some error injection nodes: For injecting a memory error, there are some sysfs nodes, under ``/sys/devices/system/edac/mc/mc?/``: @@ -855,13 +867,14 @@ EDAC MC0: UE row 0, channel-a= 0 channel-b= 0 labels "-": NON_FATAL (addr = 0x0075b980, socket=0, Dimm=0, Channel=2, syndrome=0x00000040, count=1, Err=8c0000400001009f:4000080482 (read error: read ECC error)) -3) Nehalem specific Corrected Error memory counters +3) Corrected Error memory register counters - Nehalem have some registers to count memory errors. The driver uses those - registers to report Corrected Errors on devices with Registered Dimms. + Those newer MCs have some registers to count memory errors. The driver + uses those registers to report Corrected Errors on devices with Registered + DIMMs. - However, those counters don't work with Unregistered Dimms. As the chipset - offers some counters that also work with UDIMMS (but with a worse level of + However, those counters don't work with Unregistered DIMM. As the chipset + offers some counters that also work with UDIMMs (but with a worse level of granularity than the default ones), the driver exposes those registers for UDIMM memories. @@ -896,8 +909,8 @@ 4) Standard error counters The standard error counters are generated when an mcelog error is received - by the driver. Since, with udimm, this is counted by software, it is - possible that some errors could be lost. With rdimm's, they display the + by the driver. Since, with UDIMM, this is counted by software, it is + possible that some errors could be lost. With RDIMM's, they display the contents of the registers Reference documents used on ``amd64_edac`` @@ -958,6 +971,7 @@ * |copy| Mauro Carvalho Chehab - 05 Aug 2009 Nehalem interface + - 26 Oct 2016 Converted to ReST and cleanups at the Nehalem section * EDAC authors/maintainers: