From: Borislav Petkov <bp@alien8.de>
To: Mauro Carvalho Chehab <mchehab@redhat.com>,
Tony Luck <tony.luck@intel.com>
Cc: Linux Edac Mailing List <linux-edac@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC EDAC/GHES] edac: lock module owner to avoid error report conflicts
Date: Thu, 1 Nov 2012 12:05:12 +0100 [thread overview]
Message-ID: <20121101110512.GA31271@liondog.tnic> (raw)
In-Reply-To: <048a00fa4a888b349be5954ce9fd063a7bcf2564.1351691230.git.mchehab@redhat.com>
+ Tony.
On Wed, Oct 31, 2012 at 11:58:15AM -0200, Mauro Carvalho Chehab wrote:
> There's a know bug that happens when apei/ghes is loaded together
> with an EDAC module: the same error is reported several times,
> as ghes calls mcelog, with, in tune, calls edac.
This is exactly why I think APEI is crap. So it is a completely useless
additional layer between the MCA code and the rest.
The #MC handler runs, logs the error, and then a split happens which
runs in parallel:
* we do mce_log which carries the error to EDAC
* we enter APEI, do some mumbo jumbo and then do mce_log AGAIN! Wtf?
So, in order to sort this out properly, let's take a step back first:
what do we actually want to do?
* the error coming from APEI still needs to get decoded by EDAC? If yes,
then WTF we need APEI for anyway?
* the error coming from APEI is already decoded, so no need for EDAC? I
highly doubt that.
* add a filter to the MCE code so that certain types of errors are not
reported by it but by APEI so that the double reporting doesn't happen?
Right about now, I'm open for hints as to why we need that APEI crap at
all. And I don't want to hear that "clear interface so that OS coders
don't need to know the hardware" bullshit argument from the sick world
of windoze.
Thanks.
--
Regards/Gruss,
Boris.
next prev parent reply other threads:[~2012-11-01 11:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-31 13:58 [RFC EDAC/GHES] edac: lock module owner to avoid error report conflicts Mauro Carvalho Chehab
2012-11-01 11:05 ` Borislav Petkov [this message]
2012-11-01 11:47 ` Mauro Carvalho Chehab
2012-11-01 17:25 ` Tony Luck
2012-11-01 17:47 ` Mauro Carvalho Chehab
2012-11-01 19:55 ` Borislav Petkov
2012-11-01 21:09 ` Luck, Tony
2012-11-01 22:02 ` Borislav Petkov
2012-11-01 23:47 ` Luck, Tony
2012-11-01 23:54 ` Borislav Petkov
2012-11-02 2:25 ` Mauro Carvalho Chehab
2012-11-02 2:12 ` 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=20121101110512.GA31271@liondog.tnic \
--to=bp@alien8.de \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox