From: wufan@codeaurora.org (wufan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] EDAC, ghes: use CPER module handles to locate DIMMs
Date: Thu, 30 Aug 2018 08:40:40 -0600 [thread overview]
Message-ID: <000f01d4406f$6ce8f160$46bad420$@codeaurora.org> (raw)
In-Reply-To: <c70fa799-bc9f-64c8-e151-088ca8c3ed3e@arm.com>
Hi James,
> > The current ghes_edac driver does not update per-dimm error counters
> > when reporting memory errors, because there is no platform-independent
> > way to find DIMMs based on the error information provided by firmware.
>
> I'd argue there is: its in the CPER records, we just didn't do anything useful
> with the information in the past!
Agreed. Will update the wording.
> > +static int ghes_edac_dimm_index(u16 handle) {
> > + struct mem_ctl_info *mci;
> > + int i;
> > +
> > + if (!ghes_pvt)
> > + return -1;
>
> ghes_edac_report_mem_error() already checked this, as its the only caller
> there is no need to check it again.
Will remove.
>
> > + mci = ghes_pvt->mci;
> > +
> > + if (!mci)
> > + return -1;
>
> Can this happen? ghes_edac_report_mem_error() would have
> dereferenced this already!
>
> If you need the struct mem_ctl_info, you may as well pass it in as the only
> caller has it to hand.
Will remove.
>
> > +
> > + for (i = 0; i < mci->tot_dimms; i++) {
> > + if (mci->dimms[i]->smbios_handle == handle)
> > + return i;
> > + }
> > + return -1;
> > +}
> > +
> > static void ghes_edac_dmidecode(const struct dmi_header *dh, void
> > *arg) {
> > struct ghes_edac_dimm_fill *dimm_fill = arg; @@ -177,6 +197,8 @@
> > static void ghes_edac_dmidecode(const struct dmi_header *dh, void *arg)
> > entry->total_width, entry->data_width);
> > }
> >
> > + dimm->smbios_handle = entry->handle;
>
> We aren't checking for duplicate handles, (e.g. they're all zero). I think this is
> fine as chances are firmware on those systems won't set
> CPER_MEM_VALID_MODULE_HANDLE. If it does, the handle it gives us is
> ambiguous, and we pick a dimm, instead of whine-ing about broken
> firmware tables.
>
> (I'm just drawing attention to it in case someone disagrees)
SBMIOS tables are typically automatically generated so chances for duplicate
handles are small.
>
> > dimm_fill->count++;
> > }
> > }
> > @@ -327,12 +349,20 @@ void ghes_edac_report_mem_error(int sev,
> struct cper_sec_mem_err *mem_err)
> > p += sprintf(p, "bit_pos:%d ", mem_err->bit_pos);
> > if (mem_err->validation_bits &
> CPER_MEM_VALID_MODULE_HANDLE) {
> > const char *bank = NULL, *device = NULL;
> > + int index = -1;
> > +
> > dmi_memdev_name(mem_err->mem_dev_handle, &bank,
> &device);
>
> > + p += sprintf(p, "DIMM DMI handle: 0x%.4x ",
> > + mem_err->mem_dev_handle);
> > if (bank != NULL && device != NULL)
> > p += sprintf(p, "DIMM location:%s %s ", bank, device);
> > - else
> > - p += sprintf(p, "DIMM DMI handle: 0x%.4x ",
> > - mem_err->mem_dev_handle);
>
> Why do we now print the handle every time? The handle is pretty
> meaningless, it can only be used to find the location-strings, if we get those
> we print them instead.
For ghes_edac the bank/device is informational, and nothing would go wrong
if the bank/device numbers are the same as another entry. But the handle
is now critical for DIMM lookup, thus pull it out.
Thanks!
Fan
next prev parent reply other threads:[~2018-08-30 14:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-29 18:33 [PATCH] EDAC, ghes: use CPER module handles to locate DIMMs Fan Wu
2018-08-30 10:43 ` Borislav Petkov
2018-08-30 14:20 ` wufan
2018-08-30 15:12 ` Boris Petkov
2018-08-30 16:34 ` James Morse
2018-08-30 10:48 ` James Morse
2018-08-30 14:40 ` wufan [this message]
2018-08-30 16:32 ` James Morse
2018-08-30 16:45 ` wufan
2018-08-30 16:46 ` Tyler Baicar
2018-08-30 17:11 ` wufan
2018-08-30 16:34 ` James Morse
2018-08-30 16:50 ` John Garry
2018-08-31 10:06 ` tanxiaofei
2018-09-03 15:05 ` wufan
2018-09-03 19:18 ` Borislav Petkov
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='000f01d4406f$6ce8f160$46bad420$@codeaurora.org' \
--to=wufan@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).