From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: unlisted-recipients:; (no To-header on input)
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>,
Linux Edac Mailing List <linux-edac@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: [PATCH 1/6] edac: Initialize the dimm label with the known information
Date: Wed, 7 Mar 2012 09:11:13 -0300 [thread overview]
Message-ID: <1331122278-28458-2-git-send-email-mchehab@redhat.com> (raw)
In-Reply-To: <1331122278-28458-1-git-send-email-mchehab@redhat.com>
While userspace doesn't fill the dimm labels, add there the dimm location,
as described by the used memory model. This could eventually match what
is described at the dmidecode, making easier for people to identify the
memory.
For example, on an Intel motherboard, the memory is described as:
Memory Device
Array Handle: 0x0029
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 2048 MB
Form Factor: DIMM
Set: 1
Locator: A1_DIMM0
Bank Locator: A1_Node0_Channel0_Dimm0
Type: <OUT OF SPEC>
Type Detail: Synchronous
Speed: 800 MHz
Manufacturer: A1_Manufacturer0
Serial Number: A1_SerNum0
Asset Tag: A1_AssetTagNum0
Part Number: A1_PartNum0
After this patch, the memory label will be filled with:
/sys/devices/system/edac/mc/mc0/dimm0/dimm_label:mc#0channel#0slot#0
With somewhat matches what it is at the Bank Locator DMI information.
So, it is easier to associate the dimm labels, of course assuming that
the DMI has the Bank Locator filled, and the BIOS doesn't have any bugs.
Yet, even without it, several motherboards are provided with enough
info to map from channel/slot (or branch/channel/slot) into the DIMM
label. So, letting the EDAC core fill it, by default is a good thing.
It should noticed that, as the label filling happens at the
edac_mc_alloc(), drivers can override it to better describe the memories
(and some actually do it).
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
drivers/edac/edac_mc.c | 21 +++++++++++++++++----
1 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c
index 4ff8d28..1651e7e 100644
--- a/drivers/edac/edac_mc.c
+++ b/drivers/edac/edac_mc.c
@@ -205,10 +205,10 @@ struct mem_ctl_info *edac_mc_alloc(unsigned edac_index,
struct errcount_attribute_data *ercd;
struct dimm_info *dimm;
u32 *ce_per_layer[EDAC_MAX_LAYERS], *ue_per_layer[EDAC_MAX_LAYERS];
- void *pvt;
+ void *pvt, *p;
unsigned size, tot_dimms, count, pos[EDAC_MAX_LAYERS];
unsigned tot_csrows, tot_cschannels, tot_errcount = 0;
- int i, j;
+ int i, j, n, len;
int err;
int row, chn;
@@ -324,9 +324,22 @@ struct mem_ctl_info *edac_mc_alloc(unsigned edac_index,
i, (dimm - mci->dimms),
pos[0], pos[1], pos[2], row, chn);
- /* Copy DIMM location */
- for (j = 0; j < n_layers; j++)
+ /*
+ * Copy DIMM location and initialize the memory location
+ */
+ len = sizeof(dimm->label);
+ p = dimm->label;
+ n = snprintf(p, len, "mc#%u", edac_index);
+ p += n;
+ len -= n;
+ for (j = 0; j < n_layers; j++) {
+ n = snprintf(p, len, "%s#%u",
+ edac_layer_name[layers[j].type],
+ pos[j]);
+ p += n;
+ len -= n;
dimm->location[j] = pos[j];
+ }
/* Link it to the csrows old API data */
chan->dimm = dimm;
--
1.7.8
next prev parent reply other threads:[~2012-03-07 12:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-07 12:11 [PATCH 0/6] Post EDAC core fix patches Mauro Carvalho Chehab
2012-03-07 12:11 ` Mauro Carvalho Chehab [this message]
2012-03-07 12:11 ` [PATCH 2/6] edac_mc_sysfs: don't create inactive errcount sysfs nodes Mauro Carvalho Chehab
2012-03-07 12:11 ` [PATCH 3/6] i5000_edac: Fix the logic that retrieves memory information Mauro Carvalho Chehab
2012-03-07 12:11 ` [PATCH 4/6] edac: add a sysfs node that stores the max possible memory location Mauro Carvalho Chehab
2012-03-07 12:11 ` [PATCH 5/6] edac: Call the sysfs nodes as "rank" instead of "dimm" if chip select is used Mauro Carvalho Chehab
2012-03-07 12:11 ` [PATCH 6/6] i5400_edac: improve debug messages to better represent the filled memory Mauro Carvalho Chehab
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=1331122278-28458-2-git-send-email-mchehab@redhat.com \
--to=mchehab@redhat.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®