Re: [PATCH EDAC v26 00/66] EDAC patches for v3.5

[Borislav Petkov]

On Fri, May 18, 2012 at 01:31:47PM -0300, Mauro Carvalho Chehab wrote:
> This is a long series of patches to fix the EDAC subsystem,
> and is being under discussions since Jan.
> 
> The current EDAC subsystem has several serious issues with regards
> to all Intel Xeon and i3/i5/i7 processors. The EDAC subsystem used
> to assume that all DIMM memory sticks have the same topology as the
> initial PC designs, e. g:
> 
> 	- the DRAM chips inside the DIMM slots are directly
> 	  accessible by the memory controller;
> 
> 	- there's no Advanced Memory Bufffer chips between DIMMs
> 	  and the memory controller;
> 
> 	- if the memory controller has more than one channel, all
> 	  channels are filled with the same memory type/size;
> 
> Due to that, all Intel drivers for hardware newer than 2005 (and
> some older Intel hardware) have to lie to the EDAC core, providing
> fake memory location information.
> 
> Also, the memory errors are reported via snprintk/printk's. As the
> printk ABI is not preserved among Kernel versions, applications can't
> (and don't) rely on it.
> 
> So, userspace applications rely, instead, on error counter sysfs
> nodes, with don't allow them to do decay and burst detection, nor
> to correlate errors among the same address range (with might help
> userspace to distinguish between a real error from a temporary
> interference.
> 
> -
> 
> v.26: 
> 
> - "RAS: Add a tracepoint for reporting memory..." patch was re-written
>    in order to send to userspace ABI integer fields as such;
> - added a fixup atch from Dan.
> - The other patches weren't touched on this version.
> 
> TODO: improve per-driver error message and error details.
> 
> Dan Carpenter (1):
>   edac_mc: check for allocation failure in edac_mc_alloc()
> 
> Joe Perches (2):
>   edac: Use more normal debugging macro style
>   edac: Convert debugfX to edac_dbg(X,
> 
> Mauro Carvalho Chehab (63):
>   edac: Create a dimm struct and move the labels into it
>   edac: move dimm properties to struct dimm_info
>   edac: Don't initialize csrow's first_page & friends when not needed
>   edac: move nr_pages to dimm struct
>   edac: rewrite edac_align_ptr()
>   edac.h: Add generic layers for describing a memory location
>   edac: Change internal representation to work with layers
>   amd64_edac: convert driver to use the new edac ABI
>   amd76x_edac: convert driver to use the new edac ABI
>   cell_edac: convert driver to use the new edac ABI
>   cpc925_edac: convert driver to use the new edac ABI
>   e752x_edac: convert driver to use the new edac ABI
>   e7xxx_edac: convert driver to use the new edac ABI
>   i3000_edac: convert driver to use the new edac ABI
>   i3200_edac: convert driver to use the new edac ABI
>   i5000_edac: convert driver to use the new edac ABI
>   i5100_edac: convert driver to use the new edac ABI
>   i5400_edac: convert driver to use the new edac ABI
>   i7300_edac: convert driver to use the new edac ABI
>   i7core_edac: convert driver to use the new edac ABI
>   i82443bxgx_edac: convert driver to use the new edac ABI
>   i82860_edac: convert driver to use the new edac ABI
>   i82875p_edac: convert driver to use the new edac ABI
>   i82975x_edac: convert driver to use the new edac ABI
>   mpc85xx_edac: convert driver to use the new edac ABI
>   mv64x60_edac: convert driver to use the new edac ABI
>   pasemi_edac: convert driver to use the new edac ABI
>   ppc4xx_edac: convert driver to use the new edac ABI
>   r82600_edac: convert driver to use the new edac ABI
>   sb_edac: convert driver to use the new edac ABI
>   tile_edac: convert driver to use the new edac ABI
>   x38_edac: convert driver to use the new edac ABI
>   edac: Remove the legacy EDAC ABI
>   edac: Initialize the dimm label with the known information
>   edac: Cleanup the logs for i7core and sb edac drivers
>   i5400_edac: improve debug messages to better represent the filled
>     memory
>   RAS: Add a tracepoint for reporting memory controller events

Are you kidding me?

You want to send patches upstream which are still in review and who
knows how untested: http://marc.info/?l=linux-next&m=133735830119299&w=2

I must be dreaming...

NACK from me.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
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/