From: "Kani, Toshimitsu" <toshi.kani@hpe.com>
To: "mchehab@s-opensource.com" <mchehab@s-opensource.com>
CC: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "mchehab@kernel.org" <mchehab@kernel.org>,
        "rjw@rjwysocki.net" <rjw@rjwysocki.net>,
        "srinivas.pandruvada@linux.intel.com" 
        <srinivas.pandruvada@linux.intel.com>,
        "bp@alien8.de" <bp@alien8.de>,
        "tony.luck@intel.com" <tony.luck@intel.com>,
        "lenb@kernel.org" <lenb@kernel.org>,
        "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
        "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac
Thread-Topic: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac
Thread-Index: AQHS/0lGOl4i5ss6QUSn88C0VF1rJqJZF6OAgADnxYCAABgPgIABQtCA
Date: Wed, 19 Jul 2017 16:40:25 +0000
Message-ID: <1500481869.2042.29.camel@hpe.com>
References: <20170717215912.26070-1-toshi.kani@hpe.com>
         <20170717215912.26070-4-toshi.kani@hpe.com>
         <20170718060007.GB8736@nazgul.tnic> <1500407379.2042.21.camel@hpe.com>
         <20170718181545.32bd9181@vento.lan>
In-Reply-To: <20170718181545.32bd9181@vento.lan>
Accept-Language: en-US
Content-Language: en-US
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <EFF7B37275259642922ED0E09AEB1FCB@NAMPRD84.PROD.OUTLOOK.COM>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 16:40:25.2158
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DF4PR84MB0186
X-OriginatorOrg: hpe.com
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by nfs id v6JGeaZA010551
Content-Length: 3457
Lines: 78

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