lkml.org 
[lkml]   [2010]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Hardware Error Kernel Mini-Summit

* Borislav Petkov <bp@amd64.org> wrote:

> Well, we have a trace_mce_record tracepoint in the
> mcheck code which calls all the necessary callbacks when
> an mcheck occurs. For the time being, the idea is to use
> the mce.c ring buffer for early mchecks and copy them to
> the regular ftrace per-cpu buffer after the last has
> been initialized. Later, we could switch to a another
> early bootmem buffer if there's need to.

The end result would be even simpler by one more step:
with persistent events we just use them and dont need the
mce.c ringbuffer at all. (getting rid of that complication
is one of the code cleanliness benefits i see in this move
as a x86 maintainer - beyond the obvious generalization
and unification benefits.)

> Also, we want to have a userspace daemon that reads out
> the mces from the trace buffer and does further
> processing like thresholding etc in userspace.
>
> Concerning critical errors, there we bypass the perf
> subsystem and execute the smallest amount of code
> possible while trying to shutdown gracefully if the
> error type allows that.

Yeah. Each perf_event can have arbitrary callbacks with
add-on (or critical) functionality. We would activate the
event(s) during bootup and it would do its thing from that
point on: critical functionality gets a direct path via
the callback, and every other event that survives goes via
the regular perf output channels, to one (or more)
consumers/subscribers of these events.

Ingo


\
 
 \ /
  Last update: 2010-05-18 21:37    [W:0.179 / U:2.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site