lkml.org 
[lkml]   [2012]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v24b] RAS: Add a tracepoint for reporting memory controller events

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

    > On Thu, May 17, 2012 at 05:41:17PM -0300, Mauro Carvalho Chehab wrote:
    > > Add a new tracepoint-based hardware events report method for
    > > reporting Memory Controller events.
    > >
    > > Part of the description bellow is shamelessly copied from Tony
    > > Luck's notes about the Hardware Error BoF during LPC 2010 [1].
    > > Tony, thanks for your notes and discussions to generate the
    > > h/w error reporting requirements.
    > >
    > > [1] http://lwn.net/Articles/416669/
    > >
    > > We have several subsystems & methods for reporting hardware errors:
    > >
    > > 1) EDAC ("Error Detection and Correction"). In its original form
    > > this consisted of a platform specific driver that read topology
    > > information and error counts from chipset registers and reported
    > > the results via a sysfs interface.
    > >
    > > 2) mcelog - x86 specific decoding of machine check bank registers
    > > reporting in binary form via /dev/mcelog. Recent additions make use
    > > of the APEI extensions that were documented in version 4.0a of the
    > > ACPI specification to acquire more information about errors without
    > > having to rely reading chipset registers directly. A user level
    > > programs decodes into somewhat human readable format.
    > >
    > > 3) drivers/edac/mce_amd.c - this driver hooks into the mcelog path and
    > > decodes errors reported via machine check bank registers in AMD
    > > processors to the console log using printk();
    > >
    > > Each of these mechanisms has a band of followers ... and none
    > > of them appear to meet all the needs of all users.
    > >
    > > As part of a RAS subsystem, let's encapsulate the memory error hardware
    > > events into a trace facility.
    > >
    > > The tracepoint printk will be displayed like:
    > >
    > > mc_event: (Corrected|Uncorrected|Fatal) error:[error msg] on memory stick "[label]" ([location] [edac_mc detail] [driver_detail])
    > >
    > > Where:
    > > [error msg] is the driver-specific error message
    > > (e. g. "memory read", "bus error", ...);
    > > [location] is the location in terms of memory controller and
    > > branch/channel/slot, channel/slot or csrow/channel;
    > > [label] is the memory stick label;
    > > [edac_mc detail] describes the address location of the error
    > > and the syndrome;
    > > [driver detail] is driver-specifig error message details,
    > > when needed/provided (e. g. "area:DMA", ...)
    > >
    > > For example:
    > >
    > > mc_event: Corrected error:memory read on memory stick "DIMM_1A" (mc:0 channel:0 slot:0 page:0x586b6e offset:0xa66 grain:32 syndrome:0x0 area:DMA)
    > >
    > > Of course, any userspace tools meant to handle errors should not parse
    > > the above data. They should, instead, use the binary fields provided by
    > > the tracepoint, mapping them directly into their MIBs.
    >
    > Nacked-by: Borislav Petkov <borislav.petkov@amd.com>

    Just wondering why this got nacked, and what the
    suggestions/plans are to improve the situation: I assume Mauro
    is working on these things to solve problems, or to add
    features, Mauro could you please give a higher level list of
    those problems or features? There must be more to it than just a
    new tracepoint! :-)

    Thanks,

    Ingo


    \
     
     \ /
      Last update: 2012-05-18 09:41    [W:5.616 / U:0.336 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site