From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Borislav Petkov <bp@alien8.de>,
linux-edac <linux-edac@vger.kernel.org>,
Toshimitsu Kani <toshi.kani@hpe.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
LKML <linux-kernel@vger.kernel.org>
Subject: [3/3] EDAC, ghes: Make it a proper module
Date: Wed, 26 Jul 2017 15:17:55 -0300 [thread overview]
Message-ID: <20170726151755.571e5979@vento.lan> (raw)
Em Wed, 26 Jul 2017 17:27:12 +0000
"Luck, Tony" <tony.luck@intel.com> escreveu:
> > > > Hmm... I'm not seeing any implementation that would allow setting
> > > > between firmware first, hardware first or "auto", as we've discussed.
> > >
> > > This is all coming up. As the 0/3 message said, these 3 patches are the
> > > bare minimum of reorganizing stuff only and should serve as a base.
> >
> > I'll then wait for such patch before acking this series.
>
> I didn't think that a BIOS that set "firmware first" gave the OS any choice about this.
>
> What exactly is this option going to do? Fiddle with ACPI OSC??
Currently, my HP server that I use to build the Kernel is FF:
[ 3.783803] GHES: APEI firmware first mode is enabled by APEI bit and WHEA _OSC.
I didn't try to disable FF on its BIOS. Not sure if it is even possible.
Still, EDAC is working there using sb_edac. As I pointed before, one of the
MC channels is not being detected, but I don't use it on this machine.
Except for that, EDAC seems to be working fine there:
$ ras-mc-ctl --layout
+-----------------------------------------------------------------------+
| mc0 | mc1 |
| channel0 | channel1 | channel2 | channel0 | channel1 | channel2 |
-------+-----------------------------------------------------------------------+
slot2: | 0 MB | 0 MB | 0 MB | 0 MB | 0 MB | 0 MB |
slot1: | 0 MB | 0 MB | 0 MB | 0 MB | 0 MB | 0 MB |
slot0: | 16384 MB | 0 MB | 16384 MB | 16384 MB | 0 MB | 16384 MB |
-------+---------------------------------------------------------------------------+
# ras-mc-ctl --guess-labels
memory stick 'PROC 1 DIMM 1' is located at 'Not Specified'
memory stick 'PROC 1 DIMM 2' is located at 'Not Specified'
memory stick 'PROC 1 DIMM 3' is located at 'Not Specified'
memory stick 'PROC 1 DIMM 4' is located at 'Not Specified'
memory stick 'PROC 1 DIMM 5' is located at 'Not Specified'
memory stick 'PROC 1 DIMM 6' is located at 'Not Specified'
memory stick 'PROC 1 DIMM 7' is located at 'Not Specified'
memory stick 'PROC 1 DIMM 8' is located at 'Not Specified'
memory stick 'PROC 1 DIMM 9' is located at 'Not Specified'
memory stick 'PROC 1 DIMM 10' is located at 'Not Specified'
memory stick 'PROC 1 DIMM 11' is located at 'Not Specified'
memory stick 'PROC 1 DIMM 12' is located at 'Not Specified'
memory stick 'PROC 2 DIMM 1' is located at 'Not Specified'
memory stick 'PROC 2 DIMM 2' is located at 'Not Specified'
memory stick 'PROC 2 DIMM 3' is located at 'Not Specified'
memory stick 'PROC 2 DIMM 4' is located at 'Not Specified'
memory stick 'PROC 2 DIMM 5' is located at 'Not Specified'
memory stick 'PROC 2 DIMM 6' is located at 'Not Specified'
memory stick 'PROC 2 DIMM 7' is located at 'Not Specified'
memory stick 'PROC 2 DIMM 8' is located at 'Not Specified'
memory stick 'PROC 2 DIMM 9' is located at 'Not Specified'
memory stick 'PROC 2 DIMM 10' is located at 'Not Specified'
memory stick 'PROC 2 DIMM 11' is located at 'Not Specified'
memory stick 'PROC 2 DIMM 12' is located at 'Not Specified'
I didn't try to inject an error, as I'm not sure if EINJ feature is
enabled on this BIOS. Probably not.
At least on this machine, I very much prefer to use sb_edac driver.
As I explained earlier in the previous thread, I just don't if the
BIOS would be doing the right thing for CE, as I don't know its
internal algorithm.
Also, as I'm maintaining the EDAC userspace tools (rasdaemon),
I would really love to get a few CE error reports there from time to
time, as it could be used to check if rasdaemon is doing do the right
thing to them.
So, I very much prefer to not have any threshold at all there at BIOS.
Thanks,
Mauro
---
To unsubscribe from this list: send the line "unsubscribe linux-edac" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next reply other threads:[~2017-07-26 18:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-26 18:17 Mauro Carvalho Chehab [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-08-02 22:41 [3/3] EDAC, ghes: Make it a proper module Toshi Kani
2017-08-02 3:18 Borislav Petkov
2017-08-02 0:19 Toshi Kani
2017-08-01 9:46 Borislav Petkov
2017-07-31 20:19 Toshi Kani
2017-07-29 6:47 Borislav Petkov
2017-07-28 18:50 Toshi Kani
2017-07-27 5:20 Borislav Petkov
2017-07-26 19:49 Toshi Kani
2017-07-26 19:24 Toshi Kani
2017-07-26 17:27 Luck, Tony
2017-07-26 10:51 Mauro Carvalho Chehab
2017-07-26 10:37 Borislav Petkov
2017-07-26 10:24 Mauro Carvalho Chehab
2017-07-26 8:48 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=20170726151755.571e5979@vento.lan \
--to=mchehab@infradead.org \
--cc=bp@alien8.de \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=tony.luck@intel.com \
--cc=toshi.kani@hpe.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 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).