Re: [PATCH 21/21] amd64_edac: add module registration routines

[Doug Thompson]

---- Original Message ----

From: Borislav Petkov <borislav.petkov@xxxxxxx>
To: Ingo Molnar <mingo@xxxxxxx>
Cc: akpm@xxxxxxxxxxxxxxxxxxxx; greg@xxxxxxxxx; norsk5@xxxxxxxxx; tglx@xxxxxxxxxxxxx; hpa@xxxxxxxxx; mchehab@xxxxxxxxxx; aris@xxxxxxxxxx; edt@xxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Doug Thompson <dougthompson@xxxxxxxxxxxx>
Sent: Thursday, May 14, 2009 10:52:05 AM
Subject: Re: [PATCH 21/21] amd64_edac: add module registration routines


> > +      Recent Opterons (Family 10h and later) provide for Memory Error
> > +      Injection into the ECC detection circuits. The amd64_edac module
> > +      allows the operator/user to inject Uncorrectable and Correctable
> > +      errors into DRAM.
> > +
> > +      When enabled, in each of the respective memory controller directories
> > +      (/sys/devices/system/edac/mc/mcX), there are 3 input files:
> > +
> > +      - z_inject_section (0..3, 16-byte section of 64-byte cacheline),
> > +      - z_inject_word (0..8, 16-bit word of 16-byte section),
> > +      - z_inject_bit_map (hex bitmap vector: mask bits of 16 bit word to
> > +        error-out)
> > +
> > +      In addition, there are two control files, z_inject_read and
> > +      z_inject_write, which trigger the Read and Write errors respectively.
> 
> I think the file names should follow existing EDAC driver practices, 
> and be named according to the existing inject_data_* pattern?
> 
> There's nothing more annoying to users (and tools) than inconsistent 
> driver namespaces.

Agreed. Done.

@Doug: edac-utils doesn't use those yet, right?

[..]


No, and probably won't.  Those injection semantics are specific to the AMD64 only

I have only done one other inject implementation with Sicortex's MIPS processors
and these two do not provide enough to generate an abstract interface quite yet.
Hence, it is driver SPECIFIC methods at this time

doug t
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/