All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Aristeu Rozanski <aris@redhat.com>
Cc: Tony Luck <tony.luck@intel.com>, Borislav Petkov <bp@alien8.de>,
	Qiuxu Zhuo <qiuxu.zhuo@intel.com>,
	linux-edac@vger.kernel.org
Subject: Re: [PATCH 0/2] EDAC, skx: Provide more machine specific location detail
Date: Wed, 18 Sep 2019 07:30:26 -0300	[thread overview]
Message-ID: <20190918073026.6b810136@coco.lan> (raw)
In-Reply-To: <20190917200503.hwizqhlukpbsipom@redhat.com>

Em Tue, 17 Sep 2019 16:05:04 -0400
Aristeu Rozanski <aris@redhat.com> escreveu:

> Hi Tony,
> 
> On Fri, Sep 13, 2019 at 03:13:42PM -0700, Tony Luck wrote:
> > First patch refactors code so that second can work on systems
> > with and without the ACPI ADXL address translation code. Perhaps
> > has some value on its own as the code is, IMHO, a little cleaner.
> > 
> > Second is in RFC state. Im looking for input on whether to just print
> > the extra information to the console log (as the patch does now) or
> > whether to tag it onto the long string that we push though the EDAC
> > reporting path.  
> 
> I believe it'll be more interesting for users that only care about error
> counts to keep this out of the console. For those who care about the extra
> information, having it available with rasdaemon or equivalent will be
> easier than have to look at both stored errors and kernel logs.

I agree with Aris here: the best is to report extra info via the
EDAC way, as some monitoring tool like rasdaemon will store it on 
a database and/or report via some mechanism like ABRT. 

I would expect that someone interested on monitoring hardware errors
to have all relevant details at the same place.

So, between a more detailed print or a more complete EDAC report, I
would do the latter.

Yet, nothing prevents to do both. 

Thanks,
Mauro

  reply	other threads:[~2019-09-18 10:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-13 22:13 [PATCH 0/2] EDAC, skx: Provide more machine specific location detail Tony Luck
2019-09-13 22:13 ` [PATCH 1/2] EDAC, skx_common: Refactor so that we initialize "dev" in result of adxl decode Tony Luck
2019-09-18 10:40   ` Mauro Carvalho Chehab
2019-09-23 23:36     ` Luck, Tony
2019-09-13 22:13 ` [RFC PATCH 2/2] EDAC, skx: Retrieve and print retry_rd_err_log registers Tony Luck
2019-09-18 10:52   ` Mauro Carvalho Chehab
2019-09-23 23:57     ` Luck, Tony
2019-09-24 21:52     ` [PATCHv2 " Tony Luck
2019-09-17 20:05 ` [PATCH 0/2] EDAC, skx: Provide more machine specific location detail Aristeu Rozanski
2019-09-18 10:30   ` Mauro Carvalho Chehab [this message]
2019-09-25 13:51 ` Aristeu Rozanski

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=20190918073026.6b810136@coco.lan \
    --to=mchehab@kernel.org \
    --cc=aris@redhat.com \
    --cc=bp@alien8.de \
    --cc=linux-edac@vger.kernel.org \
    --cc=qiuxu.zhuo@intel.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.