All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luck, Tony" <tony.luck@intel.com>
To: Borislav Petkov <bp@alien8.de>, "Chen, Gong" <gong.chen@linux.intel.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	"m.chehab@samsung.com" <m.chehab@samsung.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 5/7 v6] trace, RAS: Add eMCA trace event interface
Date: Fri, 30 May 2014 23:03:27 +0000	[thread overview]
Message-ID: <3908561D78D1C84285E8C5FCA982C28F32823D2B@ORSMSX114.amr.corp.intel.com> (raw)
In-Reply-To: <20140530100716.GE28131@pd.tnic>

>> For memory error location, I will utilize type offset to save one
>> more byte, furthermore, I want to drop requestor_id, responder_id
>> and target_id. 1) They are very rare (I've never seen them by now)
>
> My concern is, are we sure we're never going to need them at all? Tony,
> what's your take on this?

They may seem rare because our BIOS doesn't bother to provide them.
Other BIOS writers may be more diligent.

I flip-flop on the issue of how much detail to log.  For the majority
of users it is enough to just point at the DIMM.  That's the thing that
they can easily replace.

But OEMs and large scale users often want to know every tiny detail
so they can look for patterns between errors reported across a large
fleet. So I hate to drop information on the floor that might be useful
to someone later.

All of this stuff only applies to server systems - so quibbling over
a handful of *bytes* in an error record on a system that has tens,
hundreds or even thousands of *gigabytes* of memory seems
a bit pointless.

-Tony

WARNING: multiple messages have this Message-ID (diff)
From: "Luck, Tony" <tony.luck@intel.com>
To: Borislav Petkov <bp@alien8.de>, "Chen, Gong" <gong.chen@linux.intel.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	"m.chehab@samsung.com" <m.chehab@samsung.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 5/7 v6] trace, RAS: Add eMCA trace event interface
Date: Fri, 30 May 2014 23:03:27 +0000	[thread overview]
Message-ID: <3908561D78D1C84285E8C5FCA982C28F32823D2B@ORSMSX114.amr.corp.intel.com> (raw)
In-Reply-To: <20140530100716.GE28131@pd.tnic>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1196 bytes --]

>> For memory error location, I will utilize type offset to save one
>> more byte, furthermore, I want to drop requestor_id, responder_id
>> and target_id. 1) They are very rare (I've never seen them by now)
>
> My concern is, are we sure we're never going to need them at all? Tony,
> what's your take on this?

They may seem rare because our BIOS doesn't bother to provide them.
Other BIOS writers may be more diligent.

I flip-flop on the issue of how much detail to log.  For the majority
of users it is enough to just point at the DIMM.  That's the thing that
they can easily replace.

But OEMs and large scale users often want to know every tiny detail
so they can look for patterns between errors reported across a large
fleet. So I hate to drop information on the floor that might be useful
to someone later.

All of this stuff only applies to server systems - so quibbling over
a handful of *bytes* in an error record on a system that has tens,
hundreds or even thousands of *gigabytes* of memory seems
a bit pointless.

-Tony
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

  parent reply	other threads:[~2014-05-30 23:03 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-15  8:30 New eMCA trace event interface Chen, Gong
2014-05-15  8:30 ` [PATCH 1/7 v5] trace, RAS: Add basic RAS trace event Chen, Gong
2014-05-15  8:30 ` [PATCH 2/7 v3] trace, AER: Move trace into unified interface Chen, Gong
2014-05-21 10:19   ` Borislav Petkov
2014-05-22  0:03     ` Chen, Gong
2014-05-22 10:41       ` Borislav Petkov
2014-05-15  8:30 ` [PATCH 3/7 v4] CPER: Adjust code flow of some functions Chen, Gong
2014-05-21 11:05   ` Borislav Petkov
2014-05-21 23:51     ` Chen, Gong
2014-05-22 10:52       ` Borislav Petkov
2014-05-23  1:49         ` Chen, Gong
2014-05-23  9:37           ` Borislav Petkov
2014-05-23 10:11             ` Borislav Petkov
2014-05-26  1:59               ` Chen, Gong
2014-05-26 10:21                 ` Borislav Petkov
2014-05-26 10:42                   ` Chen, Gong
2014-05-26  2:07             ` Chen, Gong
2014-05-26 10:23               ` Borislav Petkov
2014-05-15  8:30 ` [PATCH 4/7 v2] RAS, debugfs: Add debugfs interface for RAS subsystem Chen, Gong
2014-05-15  8:30 ` [PATCH 5/7 v5] trace, RAS: Add eMCA trace event interface Chen, Gong
2014-05-15  8:30 ` [PATCH 6/7 v3] trace, eMCA: Add a knob to adjust where to save event log Chen, Gong
2014-05-21 11:06   ` Borislav Petkov
2014-05-21 23:46     ` Chen, Gong
2014-05-22 11:11       ` Borislav Petkov
2014-05-23  1:40         ` Chen, Gong
2014-05-28  3:27         ` [PATCH 6/7 v4] " Chen, Gong
2014-05-15  8:30 ` [PATCH 7/7] RAS, extlog: Adjust init flow Chen, Gong
2014-05-28  3:32 ` new trace output format Chen, Gong
2014-05-28  3:32   ` [PATCH 5/7 v6] trace, RAS: Add eMCA trace event interface Chen, Gong
2014-05-28 15:28     ` Steven Rostedt
2014-05-28 16:34       ` Borislav Petkov
2014-05-28 16:56         ` Steven Rostedt
2014-05-29  7:43           ` Chen, Gong
2014-05-29 10:35             ` Borislav Petkov
2014-05-29 13:12             ` Steven Rostedt
2014-05-30  2:56               ` Chen, Gong
2014-05-30  9:22           ` Chen, Gong
2014-05-30 10:07             ` Borislav Petkov
2014-05-30 21:16               ` Tony Luck
2014-05-30 21:26                 ` Borislav Petkov
2014-05-30 23:03               ` Luck, Tony [this message]
2014-05-30 23:03                 ` Luck, Tony
2014-05-31  1:07                 ` Steven Rostedt
2014-06-02 16:22                   ` Luck, Tony
2014-06-02 16:57                     ` Steven Rostedt
2014-06-03  8:36                       ` Chen, Gong
2014-06-03 14:35                         ` Steven Rostedt
2014-06-04 18:32                           ` Steven Rostedt
2014-06-06  6:51                           ` Chen, Gong
2014-06-06 15:21                             ` Steven Rostedt
2014-06-09  1:10                               ` Chen, Gong
2014-06-09 10:22                                 ` Borislav Petkov
2014-05-28 16:23   ` new trace output format 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=3908561D78D1C84285E8C5FCA982C28F32823D2B@ORSMSX114.amr.corp.intel.com \
    --to=tony.luck@intel.com \
    --cc=bp@alien8.de \
    --cc=gong.chen@linux.intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.chehab@samsung.com \
    --cc=rostedt@goodmis.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 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.