[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110429140844.GB1768@nowhere>
Date: Fri, 29 Apr 2011 16:08:48 +0200
From: Frederic Weisbecker <fweisbec@...il.com>
To: Borislav Petkov <bp@...64.org>
Cc: Arnaldo Carvalho de Melo <acme@...radead.org>,
Ingo Molnar <mingo@...e.hu>,
Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
Tony Luck <tony.luck@...el.com>,
Mauro Carvalho Chehab <mchehab@...hat.com>,
David Ahern <dsahern@...il.com>,
EDAC devel <linux-edac@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Borislav Petkov <borislav.petkov@....com>
Subject: Re: [PATCH 00/18] RAS daemon: Easter Eggs Edition
On Sat, Apr 23, 2011 at 06:28:02PM +0200, Borislav Petkov wrote:
> From: Borislav Petkov <borislav.petkov@....com>
>
> Ok, here's yet another version of the RAS daemon patchset. This one
> changes all the event handling to how it is done in test__basic_mmap(),
> as acme suggested. Patchset is against tip/perf/core from today.
>
> With this I can inject an mce using the python script below (yeah, work
> in progress in itself):
>
> $ mcegen.py -i sw
>
> [ this will inject a random MCE using the mce_amd_inj.ko module ]
>
> and in /var/log/ras.log I get:
>
> MCE on cpu 0, status: 0xf200210000000853, addr: 0x0000000000000000
> MCE on cpu 0, status: 0x9800400000000015, addr: 0x0000000000000000
> MCE on cpu 0, status: 0xfc00200000050e0f, addr: 0x0000000000000000
> MCE on cpu 0, status: 0x98004100001c010b, addr: 0x0000000000000000
> MCE on cpu 0, status: 0xbc00200000000843, addr: 0x0000000000000000
> MCE on cpu 0, status: 0xda00410000080e0f, addr: 0x0000000000000000
>
> Yep, it is still raw info but you can do almost anything with that info
> in userspace.
>
> Next on the TODO list is changing the tracepoint to convey the decoded
> info too which should be a fairly simple task to do.
>
> So we've got the basic design hammered out methinks, the persistent
> event is off by default for now and since rebasing this pile is always a
> great PITA for me due to other developments in tools/perf, I'd like it
> very much if I could offload it in -tip soon.
If you want to accelerate that, I suggest you cut your patchset into smaller
sets and focus on merging them piece by piece. Few people are going to review
18 patches at once. They may plan to scatter their review over days but
that doesn't scale well, and it naturally reduces the number of reviewers.
You could start with exporting trace things into tools/trace, post the
few concerned patches and iterate them until everyone is happy. Then
switch to another subset of the big thing.
Hm?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists