From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
To: Robert Richter <rrichter@marvell.com>
Cc: Borislav Petkov <bp@alien8.de>, Tony Luck <tony.luck@intel.com>,
Jonathan Corbet <corbet@lwn.net>,
James Morse <james.morse@arm.com>,
"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH 19/19] EDAC, Documentation: Describe CPER module definition and DIMM ranks
Date: Fri, 11 Oct 2019 08:29:13 -0300 [thread overview]
Message-ID: <20191011082913.6514e126@coco.lan> (raw)
In-Reply-To: <20191010202418.25098-20-rrichter@marvell.com>
Em Thu, 10 Oct 2019 20:25:42 +0000
Robert Richter <rrichter@marvell.com> escreveu:
> Update on CPER DIMM naming convention and DIMM ranks.
>
> Signed-off-by: Robert Richter <rrichter@marvell.com>
Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> Documentation/admin-guide/ras.rst | 31 +++++++++++++++++++------------
> 1 file changed, 19 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/admin-guide/ras.rst b/Documentation/admin-guide/ras.rst
> index 2b20f5f7380d..26e02a59f0f4 100644
> --- a/Documentation/admin-guide/ras.rst
> +++ b/Documentation/admin-guide/ras.rst
> @@ -330,9 +330,12 @@ There can be multiple csrows and multiple channels.
>
> .. [#f4] Nowadays, the term DIMM (Dual In-line Memory Module) is widely
> used to refer to a memory module, although there are other memory
> - packaging alternatives, like SO-DIMM, SIMM, etc. Along this document,
> - and inside the EDAC system, the term "dimm" is used for all memory
> - modules, even when they use a different kind of packaging.
> + packaging alternatives, like SO-DIMM, SIMM, etc. The UEFI
> + specification (Version 2.7) defines a memory module in the Common
> + Platform Error Record (CPER) section to be an SMBIOS Memory Device
> + (Type 17). Along this document, and inside the EDAC system, the term
> + "dimm" is used for all memory modules, even when they use a
> + different kind of packaging.
>
> Memory controllers allow for several csrows, with 8 csrows being a
> typical value. Yet, the actual number of csrows depends on the layout of
> @@ -349,12 +352,14 @@ controllers. The following example will assume 2 channels:
> | | ``ch0`` | ``ch1`` |
> +============+===========+===========+
> | ``csrow0`` | DIMM_A0 | DIMM_B0 |
> - +------------+ | |
> - | ``csrow1`` | | |
> + | | rank0 | rank0 |
> + +------------+ - | - |
> + | ``csrow1`` | rank1 | rank1 |
> +------------+-----------+-----------+
> | ``csrow2`` | DIMM_A1 | DIMM_B1 |
> - +------------+ | |
> - | ``csrow3`` | | |
> + | | rank0 | rank0 |
> + +------------+ - | - |
> + | ``csrow3`` | rank1 | rank1 |
> +------------+-----------+-----------+
>
> In the above example, there are 4 physical slots on the motherboard
> @@ -374,11 +379,13 @@ which the memory DIMM is placed. Thus, when 1 DIMM is placed in each
> Channel, the csrows cross both DIMMs.
>
> Memory DIMMs come single or dual "ranked". A rank is a populated csrow.
> -Thus, 2 single ranked DIMMs, placed in slots DIMM_A0 and DIMM_B0 above
> -will have just one csrow (csrow0). csrow1 will be empty. On the other
> -hand, when 2 dual ranked DIMMs are similarly placed, then both csrow0
> -and csrow1 will be populated. The pattern repeats itself for csrow2 and
> -csrow3.
> +In the example above 2 dual ranked DIMMs are similarly placed. Thus,
> +both csrow0 and csrow1 are populated. On the other hand, when 2 single
> +ranked DIMMs are placed in slots DIMM_A0 and DIMM_B0, then they will
> +have just one csrow (csrow0) and csrow1 will be empty. The pattern
> +repeats itself for csrow2 and csrow3. Also note that some memory
> +controller doesn't have any logic to identify the memory module, see
> +``rankX`` directories below.
>
> The representation of the above is reflected in the directory
> tree in EDAC's sysfs interface. Starting in directory
Thanks,
Mauro
next prev parent reply other threads:[~2019-10-11 11:29 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-10 20:25 [PATCH 00/19] EDAC: Rework edac_mc and ghes drivers Robert Richter
2019-10-10 20:25 ` [PATCH 01/19] EDAC: Replace EDAC_DIMM_PTR() macro with edac_get_dimm() function Robert Richter
2019-10-11 9:58 ` Mauro Carvalho Chehab
2019-10-11 11:38 ` Robert Richter
2019-10-10 20:25 ` [PATCH 02/19] EDAC: Remove EDAC_DIMM_OFF() macro Robert Richter
2019-10-11 10:09 ` Mauro Carvalho Chehab
2019-10-11 11:36 ` Robert Richter
2019-10-10 20:25 ` [PATCH 03/19] EDAC: Introduce mci_for_each_dimm() iterator Robert Richter
2019-10-11 10:14 ` Mauro Carvalho Chehab
2019-10-10 20:25 ` [PATCH 04/19] EDAC, mc: Do not BUG_ON() in edac_mc_alloc() Robert Richter
2019-10-11 10:15 ` Mauro Carvalho Chehab
2019-10-10 20:25 ` [PATCH 05/19] EDAC, mc: Reduce indentation level in edac_mc_handle_error() Robert Richter
2019-10-10 22:10 ` Joe Perches
2019-10-11 6:50 ` Robert Richter
2019-10-11 10:20 ` Mauro Carvalho Chehab
2019-10-11 10:50 ` Joe Perches
2019-10-11 12:08 ` Robert Richter
2019-10-11 14:49 ` Joe Perches
2019-10-11 10:17 ` Mauro Carvalho Chehab
2019-10-10 20:25 ` [PATCH 06/19] EDAC, mc: Remove per layer counters Robert Richter
2019-10-11 10:40 ` Mauro Carvalho Chehab
2019-10-14 11:12 ` Robert Richter
2019-10-10 20:25 ` [PATCH 07/19] EDAC, mc: Rename iterator variable to idx Robert Richter
2019-10-11 10:41 ` Mauro Carvalho Chehab
2019-10-10 20:25 ` [PATCH 08/19] EDAC, mc: Split edac_mc_alloc() into smaller functions Robert Richter
2019-10-11 10:43 ` Mauro Carvalho Chehab
2019-10-10 20:25 ` [PATCH 09/19] EDAC, mc: Reorder functions edac_mc_alloc*() Robert Richter
2019-10-11 10:45 ` Mauro Carvalho Chehab
2019-10-10 20:25 ` [PATCH 10/19] EDAC, mc: Rework edac_raw_mc_handle_error() to use struct dimm_info Robert Richter
2019-10-11 10:48 ` Mauro Carvalho Chehab
2019-10-10 20:25 ` [PATCH 11/19] EDAC: Remove misleading comment in struct edac_raw_error_desc Robert Richter
2019-10-11 10:49 ` Mauro Carvalho Chehab
2019-10-10 20:25 ` [PATCH 12/19] EDAC: Store error type " Robert Richter
2019-10-11 10:54 ` Mauro Carvalho Chehab
2019-10-14 11:47 ` Robert Richter
2019-10-10 20:25 ` [PATCH 13/19] EDAC, mc: Determine mci pointer from the error descriptor Robert Richter
2019-10-11 10:56 ` Mauro Carvalho Chehab
2019-10-10 20:25 ` [PATCH 14/19] EDAC, mc: Create new function edac_inc_csrow() Robert Richter
2019-10-11 11:08 ` Mauro Carvalho Chehab
2019-10-14 11:58 ` Robert Richter
2019-10-10 20:25 ` [PATCH 15/19] EDAC, ghes: Use standard kernel macros for page calculations Robert Richter
2019-10-11 11:10 ` Mauro Carvalho Chehab
2019-10-10 20:25 ` [PATCH 16/19] EDAC, ghes: Fix grain calculation Robert Richter
2019-10-11 11:22 ` Mauro Carvalho Chehab
2019-10-10 20:25 ` [PATCH 17/19] EDAC, ghes: Remove intermediate buffer pvt->detail_location Robert Richter
2019-10-11 11:20 ` Mauro Carvalho Chehab
2019-10-10 20:25 ` [PATCH 18/19] EDAC, ghes: Unify trace_mc_event() code with edac_mc driver Robert Richter
2019-10-11 11:23 ` Mauro Carvalho Chehab
2019-10-10 20:25 ` [PATCH 19/19] EDAC, Documentation: Describe CPER module definition and DIMM ranks Robert Richter
2019-10-11 11:29 ` Mauro Carvalho Chehab [this message]
2019-10-10 20:36 ` [PATCH 00/19] EDAC: Rework edac_mc and ghes drivers Robert Richter
2019-10-14 12:00 ` Robert Richter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191011082913.6514e126@coco.lan \
--to=mchehab+samsung@kernel.org \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=james.morse@arm.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rrichter@marvell.com \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.