mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Luck, Tony" <tony.luck@intel.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: bp@suse.de, linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: changing format/size of data in TRACE_EVENT(extlog_mem_event)
Date: Wed, 24 Jun 2015 14:56:49 -0700	[thread overview]
Message-ID: <20150624215649.GA16000@agluck-desk.sc.intel.com> (raw)

In <ras/ras_event.h> we define a trace event for memory errors.
The last field is:

                __field_struct(struct cper_mem_err_compact, data)

where the structure is defined in <linux/cper.h> as:

struct cper_mem_err_compact {
        __u64   validation_bits;
        __u16   node;
        __u16   card;
        __u16   module;
        __u16   bank;
        __u16   device;
        __u16   row;
        __u16   column;
        __u16   bit_pos;
        __u64   requestor_id;
        __u64   responder_id;
        __u64   target_id;
        __u16   rank;
        __u16   mem_array_handle;
        __u16   mem_dev_handle;
};

This structure was defined based on the useful bits in the
UEFI 2.4 spec appendix N, section 2.5 "Memory Error Section".

But UEFI have released a new version of the spec ... 2.5

  http://www.uefi.org/sites/default/files/resources/UEFI%202_5.pdf

and things have been updated to cope with ever increasing memory sizes
thanks to Moore's law. The old structure got a couple of tweaks as a
quick band-aid to handle current problems (__u16 isn't big enough for
the "row" entry for some 64GB DIMMs, so they squeezed bits 16:17 into a
reserved field).  But looking to the future they added a whole new GUID
record "Memory Error Section 2" that increases the width of the device,
row, column, rank and bit_pos fields from u16 to u32 and adds a couple
of completely new fields.

So the question is - how can we update the trace event to include these
new wider fields with the minimum pain to applications that look at it?
I don't know if there are any other consumers besides rasdaemon at the
moment ... but we don't want ugly transitions where you have to guess
which version of the application you need to run to work with a given
kernel version.

-Tony

             reply	other threads:[~2015-06-24 21:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-24 21:56 Luck, Tony [this message]
2015-06-24 22:17 ` Borislav Petkov
2015-06-25  0:59 ` Steven Rostedt

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=20150624215649.GA16000@agluck-desk.sc.intel.com \
    --to=tony.luck@intel.com \
    --cc=bp@suse.de \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®