Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

[Kani, Toshimitsu]

On Tue, 2017-07-18 at 18:15 -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 18 Jul 2017 19:58:54 +0000
 :
> We had a similar discussion several years ago when I wrote this
> driver. On that time, I talked with Red Hat, HP, Dell, Intel people
> and with some customers with large clusters.
> 
> The way it is, ghes_edac is a poor man's driver. What it hopefully
> provide is a detection that an error happened, without really telling
> the user what component should be replaced.

"poor man's driver" is a bit misleading, but yes, firmware-first
platforms have RAS features built-into the platforms, and they do not
need intelligence in EDAC drivers, which may conflict with the
platform's RAS features.  I cannot speak for other vendors, but HPE
platforms log errors and provide FRU info.  ghes_edac allows to report
errors to OS management tools like rasdaemon in addition to platform-
specific managements.

> Ok, on machines with their own error reporting mechanism (like
> HP servers), a sys admin can look on some proprietary software
> (or bios), in order to identify what happened.
> 
> Yet, BIOS doesn't provide any glue about what's the memory
> architecture, as it maps memory as if it was a single DIMM memory:
> 
> (from ghes_edac_register)
> 
> 	layers[0].type = EDAC_MC_LAYER_ALL_MEM;
> 	layers[0].size = num_dimm;
> 	layers[0].is_virt_csrow = true;
> 
> So, even on systems where the BIOS actually knows how the memory
> cards are wired, it will mask the memory controller data.
> 
> Now, the EDAC driver can also be used to identify what
> channels are used. That helps the sys admin to know if the
> memories are connected in a way that it will be using multiple
> channels, or not, helping to setup the machine to obtain
> the maximum possible performance.
> 
> So, for example, on my Intel-based HP server, I can check
> such info with:
> 
> $ ras-mc-ctl --mainboard
> ras-mc-ctl: mainboard: HP model ProLiant ML350 Gen9
> $ ras-mc-ctl --layout
> ÂÂÂÂÂÂÂ+-------------------------------------------------------------
> ----------+
> ÂÂÂÂÂÂÂ|ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂmc0ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ|ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂmc1ÂÂÂÂÂÂ
> ÂÂÂÂÂÂÂÂÂÂ|
> ÂÂÂÂÂÂÂ| channel0ÂÂ| channel1ÂÂ| channel2ÂÂ| channel0ÂÂ| channel1ÂÂ|
> channel2ÂÂ|
> -------+-------------------------------------------------------------
> ----------+
> slot2: |ÂÂÂÂÂ0 MBÂÂ|ÂÂÂÂÂ0 MBÂÂ|ÂÂÂÂÂ0 MBÂÂ|ÂÂÂÂÂ0 MBÂÂ|ÂÂÂÂÂ0
> MBÂÂ|ÂÂÂÂÂ0 MBÂÂ|
> slot1: |ÂÂÂÂÂ0 MBÂÂ|ÂÂÂÂÂ0 MBÂÂ|ÂÂÂÂÂ0 MBÂÂ|ÂÂÂÂÂ0 MBÂÂ|ÂÂÂÂÂ0
> MBÂÂ|ÂÂÂÂÂ0 MBÂÂ|
> slot0: |ÂÂ16384 MBÂÂ|ÂÂÂÂÂ0 MBÂÂ|ÂÂ16384 MBÂÂ|ÂÂ16384 MBÂÂ|ÂÂÂÂÂ0
> MBÂÂ|ÂÂ16384 MBÂÂ|
> -------+-------------------------------------------------------------
> --------------+
> 
> So, I know that both CPUs will be connected to my memories, and,
> on both, it is using 2 channels.
> 
> If I was using the ghes driver, that information would be hidden.
> 
> So, due to all problems with ghes, it is enabled only if there are no
> better solution, e. g. on systems where there's no way to talk
> directly to the hardware (like on E7 Xeon machines, where the memory
> controller is actually on a separate chip that are controlled only by
> the BIOS).

Thanks for the info!  That's very helpful.  I will check to see if
ghes_edac provides enough info that we need.
-Toshi