| Message ID | 20190913221344.13055-1-tony.luck@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | EDAC, skx: Provide more machine specific location detail | expand |
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.
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
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. > > Tony Luck (2): > EDAC, skx_common: Refactor so that we initialize "dev" in result of > adxl decode. > EDAC, skx: Retrieve and print retry_rd_err_log registers with v2: Acked-by: Aristeu Rozanski <aris@redhat.com>
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. Tony Luck (2): EDAC, skx_common: Refactor so that we initialize "dev" in result of adxl decode. EDAC, skx: Retrieve and print retry_rd_err_log registers drivers/edac/skx_base.c | 38 +++++++++++++++++++++++++-- drivers/edac/skx_common.c | 55 +++++++++++++++++++++------------------ drivers/edac/skx_common.h | 4 ++- 3 files changed, 68 insertions(+), 29 deletions(-)