Re: [RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

On Wed, 2017-11-01 at 16:30 +0100, Borislav Petkov wrote: > On Wed, Nov 01, 2017 at 02:58:33PM +, James Morse wrote: > > Does anyone have an x86 machine that does firmware-first using NOTIFY_NMI? > > AFAIK, the only one who has access to a reportedly somewhat working GHES > implementation is

Re: [RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

On Wed, 2017-11-01 at 16:30 +0100, Borislav Petkov wrote: > On Wed, Nov 01, 2017 at 02:58:33PM +, James Morse wrote: > > Does anyone have an x86 machine that does firmware-first using NOTIFY_NMI? > > AFAIK, the only one who has access to a reportedly somewhat working GHES > implementation is

RE: linux-next: manual merge of the pm tree with the dmi tree

> Hi Jean, > > On Fri, 01 Sep 2017 15:20:21 +0200 Jean Delvare wrote: > > > > On jeu., 2017-08-31 at 11:07 +1000, Stephen Rothwell wrote: > > > > > > Today's linux-next merge of the pm tree got a conflict in: > > > > > > drivers/acpi/blacklist.c > > > > > > between commit: >

RE: linux-next: manual merge of the pm tree with the dmi tree

> Hi Jean, > > On Fri, 01 Sep 2017 15:20:21 +0200 Jean Delvare wrote: > > > > On jeu., 2017-08-31 at 11:07 +1000, Stephen Rothwell wrote: > > > > > > Today's linux-next merge of the pm tree got a conflict in: > > > > > > drivers/acpi/blacklist.c > > > > > > between commit: > > > > > >

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

On Thu, 2017-08-31 at 12:56 +0200, Borislav Petkov wrote: > On Wed, Aug 23, 2017 at 04:54:45PM -0600, Toshi Kani wrote: : > > --- > >  drivers/edac/ghes_edac.c |   29 - > >  1 file changed, 24 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/edac/ghes_edac.c

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

On Thu, 2017-08-31 at 12:56 +0200, Borislav Petkov wrote: > On Wed, Aug 23, 2017 at 04:54:45PM -0600, Toshi Kani wrote: : > > --- > >  drivers/edac/ghes_edac.c |   29 - > >  1 file changed, 24 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/edac/ghes_edac.c

Re: [PATCH v3 2/5] intel_pstate: convert to use acpi_match_platform_list()

On Wed, 2017-08-23 at 17:46 +0200, Borislav Petkov wrote: > On Fri, Aug 18, 2017 at 01:46:41PM -0600, Toshi Kani wrote: > > Convert to use acpi_match_platform_list() for the platform check. > > There is no change in functionality. > > : > > Btw, why is that ACPI_SIG_FADT's description not

Re: [PATCH v3 2/5] intel_pstate: convert to use acpi_match_platform_list()

On Wed, 2017-08-23 at 17:46 +0200, Borislav Petkov wrote: > On Fri, Aug 18, 2017 at 01:46:41PM -0600, Toshi Kani wrote: > > Convert to use acpi_match_platform_list() for the platform check. > > There is no change in functionality. > > : > > Btw, why is that ACPI_SIG_FADT's description not

Re: [PATCH v3 1/5] ACPI / blacklist: add acpi_match_platform_list()

On Mon, 2017-08-21 at 23:49 +0200, Rafael J. Wysocki wrote: > On Mon, Aug 21, 2017 at 11:06 PM, Kani, Toshimitsu <toshi.k...@hpe.co > m> wrote: > > On Mon, 2017-08-21 at 22:31 +0200, Rafael J. Wysocki wrote: > > > On Mon, Aug 21, 2017 at 7:36 PM, Borislav Petkov &

Re: [PATCH v3 1/5] ACPI / blacklist: add acpi_match_platform_list()

On Mon, 2017-08-21 at 23:49 +0200, Rafael J. Wysocki wrote: > On Mon, Aug 21, 2017 at 11:06 PM, Kani, Toshimitsu m> wrote: > > On Mon, 2017-08-21 at 22:31 +0200, Rafael J. Wysocki wrote: > > > On Mon, Aug 21, 2017 at 7:36 PM, Borislav Petkov > > > wrote: > &g

Re: [PATCH v3 1/5] ACPI / blacklist: add acpi_match_platform_list()

On Mon, 2017-08-21 at 22:31 +0200, Rafael J. Wysocki wrote: > On Mon, Aug 21, 2017 at 7:36 PM, Borislav Petkov <b...@alien8.de> > wrote: > > On Mon, Aug 21, 2017 at 05:23:37PM +, Kani, Toshimitsu wrote: > > > > > 'data' here is private to the caller.  So,

Re: [PATCH v3 1/5] ACPI / blacklist: add acpi_match_platform_list()

On Mon, 2017-08-21 at 22:31 +0200, Rafael J. Wysocki wrote: > On Mon, Aug 21, 2017 at 7:36 PM, Borislav Petkov > wrote: > > On Mon, Aug 21, 2017 at 05:23:37PM +, Kani, Toshimitsu wrote: > > > > > 'data' here is private to the caller.  So, I do not think we > &

Re: [PATCH v3 1/5] ACPI / blacklist: add acpi_match_platform_list()

On Mon, 2017-08-21 at 19:04 +0200, Borislav Petkov wrote: > On Mon, Aug 21, 2017 at 04:41:38PM +0000, Kani, Toshimitsu wrote: > > Putting to a single line leads to "line over 80 characters" warning > > from checkpatch.pl.  Would you still advice to do that? > > Yes,

Re: [PATCH v3 1/5] ACPI / blacklist: add acpi_match_platform_list()

On Mon, 2017-08-21 at 19:04 +0200, Borislav Petkov wrote: > On Mon, Aug 21, 2017 at 04:41:38PM +0000, Kani, Toshimitsu wrote: > > Putting to a single line leads to "line over 80 characters" warning > > from checkpatch.pl.  Would you still advice to do that? > > Yes,

Re: [PATCH v3 1/5] ACPI / blacklist: add acpi_match_platform_list()

On Mon, 2017-08-21 at 13:27 +0200, Borislav Petkov wrote: > On Fri, Aug 18, 2017 at 01:46:40PM -0600, Toshi Kani wrote: > > ACPI OEM ID / OEM Table ID / Revision can be used to identify > > a platform based on ACPI firmware info.  acpi_blacklisted(), > > intel_pstate_platform_pwr_mgmt_exists(),

Re: [PATCH v3 1/5] ACPI / blacklist: add acpi_match_platform_list()

On Mon, 2017-08-21 at 13:27 +0200, Borislav Petkov wrote: > On Fri, Aug 18, 2017 at 01:46:40PM -0600, Toshi Kani wrote: > > ACPI OEM ID / OEM Table ID / Revision can be used to identify > > a platform based on ACPI firmware info.  acpi_blacklisted(), > > intel_pstate_platform_pwr_mgmt_exists(),

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Wed, 2017-08-16 at 11:51 -0600, Toshi Kani wrote: > On Wed, 2017-08-16 at 19:40 +0200, Borislav Petkov wrote: > > On Wed, Aug 16, 2017 at 05:28:50PM +0000, Kani, Toshimitsu wrote: : > > > I will test the patch with an SCI when I got a chance.  I won't > > > be able

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Wed, 2017-08-16 at 11:51 -0600, Toshi Kani wrote: > On Wed, 2017-08-16 at 19:40 +0200, Borislav Petkov wrote: > > On Wed, Aug 16, 2017 at 05:28:50PM +0000, Kani, Toshimitsu wrote: : > > > I will test the patch with an SCI when I got a chance.  I won't > > > be able

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Wed, 2017-08-16 at 19:40 +0200, Borislav Petkov wrote: > On Wed, Aug 16, 2017 at 05:28:50PM +0000, Kani, Toshimitsu wrote: > > Assuming this big spinlock works, yes, this addresses my concern > > that > > You mean, lengthy locked section. We can always switch

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Wed, 2017-08-16 at 19:40 +0200, Borislav Petkov wrote: > On Wed, Aug 16, 2017 at 05:28:50PM +0000, Kani, Toshimitsu wrote: > > Assuming this big spinlock works, yes, this addresses my concern > > that > > You mean, lengthy locked section. We can always switch

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Wed, 2017-08-16 at 18:42 +0200, Borislav Petkov wrote: > On Wed, Aug 16, 2017 at 03:26:04PM +0000, Kani, Toshimitsu wrote: > > I believe you now need to protect from a race condition that a > > single mci and pvt can be initialized / consumed from multiple > > thre

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Wed, 2017-08-16 at 18:42 +0200, Borislav Petkov wrote: > On Wed, Aug 16, 2017 at 03:26:04PM +0000, Kani, Toshimitsu wrote: > > I believe you now need to protect from a race condition that a > > single mci and pvt can be initialized / consumed from multiple > > thre

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Wed, 2017-08-16 at 10:29 +0200, Borislav Petkov wrote: > On Tue, Aug 15, 2017 at 08:48:16AM -0700, Luck, Tony wrote: > > Won't the user see all their DIMMs reported for each memory > > controller > > under /sys/devices/system/edac/mc/mc*/dimm* ? > > > > That sounds confusing. > > Right, and

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Wed, 2017-08-16 at 10:29 +0200, Borislav Petkov wrote: > On Tue, Aug 15, 2017 at 08:48:16AM -0700, Luck, Tony wrote: > > Won't the user see all their DIMMs reported for each memory > > controller > > under /sys/devices/system/edac/mc/mc*/dimm* ? > > > > That sounds confusing. > > Right, and

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Tue, 2017-08-15 at 17:50 +0200, Borislav Petkov wrote: > On Tue, Aug 15, 2017 at 03:35:51PM +0000, Kani, Toshimitsu wrote: > > ghes_edac instantiates an mci as a pseudo device representing a > > GHES error source.  Each error source associates with all DIMMs, > >

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Tue, 2017-08-15 at 17:50 +0200, Borislav Petkov wrote: > On Tue, Aug 15, 2017 at 03:35:51PM +0000, Kani, Toshimitsu wrote: > > ghes_edac instantiates an mci as a pseudo device representing a > > GHES error source.  Each error source associates with all DIMMs, > >

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Tue, 2017-08-15 at 08:48 -0700, Luck, Tony wrote: > On Tue, Aug 15, 2017 at 08:35:51AM -0700, Kani, Toshimitsu wrote: > > User apps like ras-mc-ctl works as expected for a given (not-so- > > great) DIMM info from SMBIOS as well.  I do not see a probelm from > > use

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Tue, 2017-08-15 at 08:48 -0700, Luck, Tony wrote: > On Tue, Aug 15, 2017 at 08:35:51AM -0700, Kani, Toshimitsu wrote: > > User apps like ras-mc-ctl works as expected for a given (not-so- > > great) DIMM info from SMBIOS as well.  I do not see a probelm from > > use

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Mon, 2017-08-14 at 22:39 +0200, Borislav Petkov wrote: > On Mon, Aug 14, 2017 at 08:17:54PM +0000, Kani, Toshimitsu wrote: > > I think the current code design of allocating mci & ghes_edac_pvt > > for each GHES source entry makes sense. > > And I don't. > > &g

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Mon, 2017-08-14 at 22:39 +0200, Borislav Petkov wrote: > On Mon, Aug 14, 2017 at 08:17:54PM +0000, Kani, Toshimitsu wrote: > > I think the current code design of allocating mci & ghes_edac_pvt > > for each GHES source entry makes sense. > > And I don't. > > &g

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Mon, 2017-08-14 at 21:34 +0200, Borislav Petkov wrote: > On Mon, Aug 14, 2017 at 07:02:15PM +0000, Kani, Toshimitsu wrote: > > I do not know how likely we see such case, but the code should be > > written according to the spec. > > Well, then you'll have to make ghes_

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Mon, 2017-08-14 at 21:34 +0200, Borislav Petkov wrote: > On Mon, Aug 14, 2017 at 07:02:15PM +0000, Kani, Toshimitsu wrote: > > I do not know how likely we see such case, but the code should be > > written according to the spec. > > Well, then you'll have to make ghes_

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Mon, 2017-08-14 at 20:35 +0200, Borislav Petkov wrote: > On Mon, Aug 14, 2017 at 06:17:47PM +0000, Kani, Toshimitsu wrote: > > Right, ghes_edac_report_mem_error() gets serialized per a GHES > > entry, but not globally. > > Globally what? GHES v2's ACK is not a glob

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Mon, 2017-08-14 at 20:35 +0200, Borislav Petkov wrote: > On Mon, Aug 14, 2017 at 06:17:47PM +0000, Kani, Toshimitsu wrote: > > Right, ghes_edac_report_mem_error() gets serialized per a GHES > > entry, but not globally. > > Globally what? GHES v2's ACK is not a glob

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Mon, 2017-08-14 at 20:05 +0200, Borislav Petkov wrote: > On Mon, Aug 14, 2017 at 05:52:25PM +0000, Kani, Toshimitsu wrote: > > Yes, but this ACK is done per a GHES entry as well. > > So is the ghes_edac_report_mem_error() call. Right, ghes_edac_report_mem_error() gets serial

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Mon, 2017-08-14 at 20:05 +0200, Borislav Petkov wrote: > On Mon, Aug 14, 2017 at 05:52:25PM +0000, Kani, Toshimitsu wrote: > > Yes, but this ACK is done per a GHES entry as well. > > So is the ghes_edac_report_mem_error() call. Right, ghes_edac_report_mem_error() gets serial

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Mon, 2017-08-14 at 19:05 +0200, Borislav Petkov wrote: > On Mon, Aug 14, 2017 at 04:48:57PM +0000, Kani, Toshimitsu wrote: > > Right, but the issue is how [ghes_edac_]report_mem_error() protects > > from possible concurrent calls from multiple GHES sources when > > there

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Mon, 2017-08-14 at 19:05 +0200, Borislav Petkov wrote: > On Mon, Aug 14, 2017 at 04:48:57PM +0000, Kani, Toshimitsu wrote: > > Right, but the issue is how [ghes_edac_]report_mem_error() protects > > from possible concurrent calls from multiple GHES sources when > > there

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Mon, 2017-08-14 at 18:24 +0200, Borislav Petkov wrote: > On Mon, Aug 14, 2017 at 03:57:35PM +0000, Kani, Toshimitsu wrote: > > Hmm... Sorry, I failed to see how your patchset solved it.  Would > > you mind to explain how it is done? > > +static int __init gh

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Mon, 2017-08-14 at 18:24 +0200, Borislav Petkov wrote: > On Mon, Aug 14, 2017 at 03:57:35PM +0000, Kani, Toshimitsu wrote: > > Hmm... Sorry, I failed to see how your patchset solved it.  Would > > you mind to explain how it is done? > > +static int __init gh

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Fri, 2017-08-11 at 11:04 +0200, Borislav Petkov wrote: > On Mon, Aug 07, 2017 at 05:59:15PM +0000, Kani, Toshimitsu wrote: > > I think we should keep the current scheme, which registers an mci > > for > > No we shouldn't. > > > each GHES entry.  ghes_edac_report_

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Fri, 2017-08-11 at 11:04 +0200, Borislav Petkov wrote: > On Mon, Aug 07, 2017 at 05:59:15PM +0000, Kani, Toshimitsu wrote: > > I think we should keep the current scheme, which registers an mci > > for > > No we shouldn't. > > > each GHES entry.  ghes_edac_report_

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Sat, 2017-08-05 at 07:16 +0200, Borislav Petkov wrote: > On Fri, Aug 04, 2017 at 09:02:17PM +0000, Kani, Toshimitsu wrote: > > GHES platform devices correspond to GHES entries, which define > > firmware interfaces to report generic memory errors to the OS, such >

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Sat, 2017-08-05 at 07:16 +0200, Borislav Petkov wrote: > On Fri, Aug 04, 2017 at 09:02:17PM +0000, Kani, Toshimitsu wrote: > > GHES platform devices correspond to GHES entries, which define > > firmware interfaces to report generic memory errors to the OS, such >

Re: [PATCH v2 7/7] edac drivers: add MC owner check in init

On Sat, 2017-08-05 at 07:49 +0200, Borislav Petkov wrote: > On Fri, Aug 04, 2017 at 09:48:23PM +0000, Kani, Toshimitsu wrote: > > Not sure if anyone cares, but I thought it should return with > > -ENODEV when this modules found no target, and -EBUSY when it found > > a target

Re: [PATCH v2 7/7] edac drivers: add MC owner check in init

On Sat, 2017-08-05 at 07:49 +0200, Borislav Petkov wrote: > On Fri, Aug 04, 2017 at 09:48:23PM +0000, Kani, Toshimitsu wrote: > > Not sure if anyone cares, but I thought it should return with > > -ENODEV when this modules found no target, and -EBUSY when it found > > a target

Re: [PATCH v2 6/7] EDAC: add edac_check_mc_owner() to check MC owner

On Sat, 2017-08-05 at 07:44 +0200, Borislav Petkov wrote: > On Fri, Aug 04, 2017 at 09:35:05PM +0000, Kani, Toshimitsu wrote: > > 1 means the caller's init function can continue its initialization > > -- > > such conditions are free or owned by itself. > > Make that

Re: [PATCH v2 6/7] EDAC: add edac_check_mc_owner() to check MC owner

On Sat, 2017-08-05 at 07:44 +0200, Borislav Petkov wrote: > On Fri, Aug 04, 2017 at 09:35:05PM +0000, Kani, Toshimitsu wrote: > > 1 means the caller's init function can continue its initialization > > -- > > such conditions are free or owned by itself. > > Make that

Re: [PATCH v2 5/7] ghes_edac: add platform check to enable ghes_edac

On Sat, 2017-08-05 at 07:37 +0200, Borislav Petkov wrote: > On Fri, Aug 04, 2017 at 09:06:27PM +0000, Kani, Toshimitsu wrote: > > How about "ghes_edac.any_platform"? > > ghes_edac.force_load Sounds good. Will do. Thanks, -Toshi

Re: [PATCH v2 5/7] ghes_edac: add platform check to enable ghes_edac

On Sat, 2017-08-05 at 07:37 +0200, Borislav Petkov wrote: > On Fri, Aug 04, 2017 at 09:06:27PM +0000, Kani, Toshimitsu wrote: > > How about "ghes_edac.any_platform"? > > ghes_edac.force_load Sounds good. Will do. Thanks, -Toshi

Re: [PATCH v2 3/7] ACPI / APEI: add OSC APEI bit check for ghes_edac

On Sat, 2017-08-05 at 07:14 +0200, Borislav Petkov wrote: > On Fri, Aug 04, 2017 at 08:49:51PM +0000, Kani, Toshimitsu wrote: > > Some firmware features can be enabled / disabled in BIOS.  While > > HPE firmware does not allow to disable FF, it's possible that other > >

Re: [PATCH v2 3/7] ACPI / APEI: add OSC APEI bit check for ghes_edac

On Sat, 2017-08-05 at 07:14 +0200, Borislav Petkov wrote: > On Fri, Aug 04, 2017 at 08:49:51PM +0000, Kani, Toshimitsu wrote: > > Some firmware features can be enabled / disabled in BIOS.  While > > HPE firmware does not allow to disable FF, it's possible that other > >

Re: [PATCH v2 1/7] ACPI / blacklist: add acpi_match_oemlist() interface

On Sat, 2017-08-05 at 07:12 +0200, Borislav Petkov wrote: > On Fri, Aug 04, 2017 at 08:39:35PM +0000, Kani, Toshimitsu wrote: > > Well, we did talk a lot about your suggested name, > > "acpi_blacklist", and I explained that it did not work since it'd > > be use

Re: [PATCH v2 1/7] ACPI / blacklist: add acpi_match_oemlist() interface

On Sat, 2017-08-05 at 07:12 +0200, Borislav Petkov wrote: > On Fri, Aug 04, 2017 at 08:39:35PM +0000, Kani, Toshimitsu wrote: > > Well, we did talk a lot about your suggested name, > > "acpi_blacklist", and I explained that it did not work since it'd > > be use

Re: [PATCH v2 7/7] edac drivers: add MC owner check in init

On Fri, 2017-08-04 at 10:39 +0200, Borislav Petkov wrote: > On Thu, Aug 03, 2017 at 03:57:53PM -0600, Toshi Kani wrote: > > Change generic x86 edac drivers, which probe CPU type with > > x86_match_cpu(), to call edac_check_mc_owner() in their > > module init functions.  This allows them to fail

Re: [PATCH v2 7/7] edac drivers: add MC owner check in init

On Fri, 2017-08-04 at 10:39 +0200, Borislav Petkov wrote: > On Thu, Aug 03, 2017 at 03:57:53PM -0600, Toshi Kani wrote: > > Change generic x86 edac drivers, which probe CPU type with > > x86_match_cpu(), to call edac_check_mc_owner() in their > > module init functions.  This allows them to fail

Re: [PATCH v2 6/7] EDAC: add edac_check_mc_owner() to check MC owner

On Fri, 2017-08-04 at 10:30 +0200, Borislav Petkov wrote: > On Thu, Aug 03, 2017 at 03:57:52PM -0600, Toshi Kani wrote: > > Only a single edac driver can be enabled for EDAC MC.  When > > ghes_edac is enabled, a regular edac driver for the CPU type / > > platform still attempts to register itself

Re: [PATCH v2 6/7] EDAC: add edac_check_mc_owner() to check MC owner

On Fri, 2017-08-04 at 10:30 +0200, Borislav Petkov wrote: > On Thu, Aug 03, 2017 at 03:57:52PM -0600, Toshi Kani wrote: > > Only a single edac driver can be enabled for EDAC MC.  When > > ghes_edac is enabled, a regular edac driver for the CPU type / > > platform still attempts to register itself

Re: [PATCH v2 5/7] ghes_edac: add platform check to enable ghes_edac

On Fri, 2017-08-04 at 10:31 +0200, Borislav Petkov wrote: > On Thu, Aug 03, 2017 at 03:57:51PM -0600, Toshi Kani wrote: > > The ghes_edac driver was introduced in 2013 [1], but it has not > > been enabled by any distro yet.  This driver obtains error info > > from firmware interfaces, which are

Re: [PATCH v2 5/7] ghes_edac: add platform check to enable ghes_edac

On Fri, 2017-08-04 at 10:31 +0200, Borislav Petkov wrote: > On Thu, Aug 03, 2017 at 03:57:51PM -0600, Toshi Kani wrote: > > The ghes_edac driver was introduced in 2013 [1], but it has not > > been enabled by any distro yet.  This driver obtains error info > > from firmware interfaces, which are

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Fri, 2017-08-04 at 06:05 +0200, Borislav Petkov wrote: > On Thu, Aug 03, 2017 at 03:57:50PM -0600, Toshi Kani wrote: > > ghes_edac_register() is called for each GHES platform device > > instantiated per a GHES entry in ACPI HEST table.  dmi_walk() > > counts the number of DIMMs on the system,

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Fri, 2017-08-04 at 06:05 +0200, Borislav Petkov wrote: > On Thu, Aug 03, 2017 at 03:57:50PM -0600, Toshi Kani wrote: > > ghes_edac_register() is called for each GHES platform device > > instantiated per a GHES entry in ACPI HEST table.  dmi_walk() > > counts the number of DIMMs on the system,

Re: [PATCH v2 3/7] ACPI / APEI: add OSC APEI bit check for ghes_edac

On Fri, 2017-08-04 at 05:44 +0200, Borislav Petkov wrote: > On Thu, Aug 03, 2017 at 03:57:49PM -0600, Toshi Kani wrote: > > When 'osc_sb_apei_support_acked' is set, it indicates that > > the platform supports APEI, firmware-first mode, as ACPI _OSC > > capability bit 4, APEI Support, was set in

Re: [PATCH v2 3/7] ACPI / APEI: add OSC APEI bit check for ghes_edac

On Fri, 2017-08-04 at 05:44 +0200, Borislav Petkov wrote: > On Thu, Aug 03, 2017 at 03:57:49PM -0600, Toshi Kani wrote: > > When 'osc_sb_apei_support_acked' is set, it indicates that > > the platform supports APEI, firmware-first mode, as ACPI _OSC > > capability bit 4, APEI Support, was set in

Re: [PATCH v2 1/7] ACPI / blacklist: add acpi_match_oemlist() interface

On Fri, 2017-08-04 at 05:42 +0200, Borislav Petkov wrote: > On Thu, Aug 03, 2017 at 03:57:47PM -0600, Toshi Kani wrote: > > ACPI OEM ID / OEM Table ID / Revision can be used to identify > > a platform based on ACPI firmware info.  acpi_blacklisted(), > > intel_pstate_platform_pwr_mgmt_exists(),

Re: [PATCH v2 1/7] ACPI / blacklist: add acpi_match_oemlist() interface

On Fri, 2017-08-04 at 05:42 +0200, Borislav Petkov wrote: > On Thu, Aug 03, 2017 at 03:57:47PM -0600, Toshi Kani wrote: > > ACPI OEM ID / OEM Table ID / Revision can be used to identify > > a platform based on ACPI firmware info.  acpi_blacklisted(), > > intel_pstate_platform_pwr_mgmt_exists(),

Re: [PATCH v2 6/7] EDAC: add edac_check_mc_owner() to check MC owner

On Fri, 2017-08-04 at 21:06 +0800, kbuild test robot wrote: > Hi Toshi, > > [auto build test WARNING on pm/linux-next] > [also build test WARNING on v4.13-rc3] > [cannot apply to edac/linux_next bp/for-next next-20170804] > [if your patch is applied to the wrong git tree, please drop us a > note

Re: [PATCH v2 6/7] EDAC: add edac_check_mc_owner() to check MC owner

On Fri, 2017-08-04 at 21:06 +0800, kbuild test robot wrote: > Hi Toshi, > > [auto build test WARNING on pm/linux-next] > [also build test WARNING on v4.13-rc3] > [cannot apply to edac/linux_next bp/for-next next-20170804] > [if your patch is applied to the wrong git tree, please drop us a > note

Re: [PATCH 3/3] EDAC, ghes: Make it a proper module

On Wed, 2017-08-02 at 05:18 +0200, Borislav Petkov wrote: > On Wed, Aug 02, 2017 at 12:19:29AM +0000, Kani, Toshimitsu wrote: > > 1. Device-probing-logic should belong to a driver, and should > > remain private to a driver.  When we add the white-list, it should > >

Re: [PATCH 3/3] EDAC, ghes: Make it a proper module

On Wed, 2017-08-02 at 05:18 +0200, Borislav Petkov wrote: > On Wed, Aug 02, 2017 at 12:19:29AM +0000, Kani, Toshimitsu wrote: > > 1. Device-probing-logic should belong to a driver, and should > > remain private to a driver.  When we add the white-list, it should > >

Re: [PATCH 3/3] EDAC, ghes: Make it a proper module

On Tue, 2017-08-01 at 11:46 +0200, Borislav Petkov wrote: > On Mon, Jul 31, 2017 at 08:19:32PM +0000, Kani, Toshimitsu wrote: > > I'd prefer to add the whitelist check to ghes_edac first.  This > > makes the existing code to work.  We can then work on refactoring > > cha

Re: [PATCH 3/3] EDAC, ghes: Make it a proper module

On Tue, 2017-08-01 at 11:46 +0200, Borislav Petkov wrote: > On Mon, Jul 31, 2017 at 08:19:32PM +0000, Kani, Toshimitsu wrote: > > I'd prefer to add the whitelist check to ghes_edac first.  This > > makes the existing code to work.  We can then work on refactoring > > cha

Re: [PATCH 3/3] EDAC, ghes: Make it a proper module

On Sat, 2017-07-29 at 08:47 +0200, Borislav Petkov wrote: > On Fri, Jul 28, 2017 at 06:50:56PM +0000, Kani, Toshimitsu wrote: > > This simply sets NULL to pvt, and does not initialize ghes_pvt. > > Yeah, I guess we need this ontop: Yes, this fix looks good. > >  As Mauro p

Re: [PATCH 3/3] EDAC, ghes: Make it a proper module

On Sat, 2017-07-29 at 08:47 +0200, Borislav Petkov wrote: > On Fri, Jul 28, 2017 at 06:50:56PM +0000, Kani, Toshimitsu wrote: > > This simply sets NULL to pvt, and does not initialize ghes_pvt. > > Yeah, I guess we need this ontop: Yes, this fix looks good. > >  As Mauro p

Re: [PATCH 3/3] EDAC, ghes: Make it a proper module

On Wed, 2017-07-26 at 10:48 +0200, Borislav Petkov wrote: > From: Borislav Petkov > > Register with the GHES notifier chain so that there's no need to call > into the module with ghes_edac_report_mem_error(). > > Signed-off-by: Borislav Petkov : > +static int

Re: [PATCH 3/3] EDAC, ghes: Make it a proper module

On Wed, 2017-07-26 at 10:48 +0200, Borislav Petkov wrote: > From: Borislav Petkov > > Register with the GHES notifier chain so that there's no need to call > into the module with ghes_edac_report_mem_error(). > > Signed-off-by: Borislav Petkov : > +static int report_mem_error(struct

Re: [PATCH 3/3] EDAC, ghes: Make it a proper module

On Wed, 2017-07-26 at 07:24 -0300, Mauro Carvalho Chehab wrote: > Em Wed, 26 Jul 2017 10:48:27 +0200 > Borislav Petkov escreveu: > > > From: Borislav Petkov > > > > Register with the GHES notifier chain so that there's no need to > > call into the module with

Re: [PATCH 3/3] EDAC, ghes: Make it a proper module

On Wed, 2017-07-26 at 07:24 -0300, Mauro Carvalho Chehab wrote: > Em Wed, 26 Jul 2017 10:48:27 +0200 > Borislav Petkov escreveu: > > > From: Borislav Petkov > > > > Register with the GHES notifier chain so that there's no need to > > call into the module with ghes_edac_report_mem_error(). > >

Re: [PATCH 3/3] EDAC, ghes: Make it a proper module

On Wed, 2017-07-26 at 15:17 -0300, Mauro Carvalho Chehab wrote: > Em Wed, 26 Jul 2017 17:27:12 + : > I didn't try to inject an error, as I'm not sure if EINJ feature is > enabled on this BIOS. Probably not. I believe it has EINJ support. > At least on this machine, I very much prefer to use

Re: [PATCH 3/3] EDAC, ghes: Make it a proper module

On Wed, 2017-07-26 at 15:17 -0300, Mauro Carvalho Chehab wrote: > Em Wed, 26 Jul 2017 17:27:12 + : > I didn't try to inject an error, as I'm not sure if EINJ feature is > enabled on this BIOS. Probably not. I believe it has EINJ support. > At least on this machine, I very much prefer to use

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

On Mon, 2017-07-24 at 20:30 +0200, Borislav Petkov wrote: : > > So I don't want to break existing users and thus make only explicitly > known platforms load ghes_edac. In the current case, the HPE > machines. All the rest will simply use the platform drivers and > nothing will change for them.

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

On Mon, 2017-07-24 at 20:30 +0200, Borislav Petkov wrote: : > > So I don't want to break existing users and thus make only explicitly > known platforms load ghes_edac. In the current case, the HPE > machines. All the rest will simply use the platform drivers and > nothing will change for them.

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

On Mon, 2017-07-24 at 14:56 -0300, Mauro Carvalho Chehab wrote: > Em Mon, 24 Jul 2017 15:56:27 + : > That's probably too late for me as I received a new HP machine > we bought just last week, but for the next time I would need to > get a new hardware, what would be the non-RAS equivalent to >

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

On Mon, 2017-07-24 at 14:56 -0300, Mauro Carvalho Chehab wrote: > Em Mon, 24 Jul 2017 15:56:27 + : > That's probably too late for me as I received a new HP machine > we bought just last week, but for the next time I would need to > get a new hardware, what would be the non-RAS equivalent to >

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

On Mon, 2017-07-24 at 20:50 +0300, Boris Petkov wrote: > On July 24, 2017 8:44:03 PM GMT+03:00, "Kani, Toshimitsu" @hpe.com> wrote: > > I assumed our platforms w/o build-in RAS do not implement GHES, > > If we make it a normal module, it will be decoupled from

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

On Mon, 2017-07-24 at 20:50 +0300, Boris Petkov wrote: > On July 24, 2017 8:44:03 PM GMT+03:00, "Kani, Toshimitsu" @hpe.com> wrote: > > I assumed our platforms w/o build-in RAS do not implement GHES, > > If we make it a normal module, it will be decoupled from

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

On Mon, 2017-07-24 at 18:37 +0200, Borislav Petkov wrote: > On Mon, Jul 24, 2017 at 03:56:27PM +0000, Kani, Toshimitsu wrote: > > Yes, Mauro has already pointed this out.  As I replied to him, we > > do have a separate series of platforms that do not have built-in >

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

On Mon, 2017-07-24 at 18:37 +0200, Borislav Petkov wrote: > On Mon, Jul 24, 2017 at 03:56:27PM +0000, Kani, Toshimitsu wrote: > > Yes, Mauro has already pointed this out.  As I replied to him, we > > do have a separate series of platforms that do not have built-in >

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

On Mon, 2017-07-24 at 17:37 +0200, Borislav Petkov wrote: > On Mon, Jul 24, 2017 at 03:25:34PM +0000, Kani, Toshimitsu wrote: : > > > We've been providing this model for many years now. > > Dude, relax, I'm only trying to point out to you that there are > customers who want

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

On Mon, 2017-07-24 at 17:37 +0200, Borislav Petkov wrote: > On Mon, Jul 24, 2017 at 03:25:34PM +0000, Kani, Toshimitsu wrote: : > > > We've been providing this model for many years now. > > Dude, relax, I'm only trying to point out to you that there are > customers who want

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

On Mon, 2017-07-24 at 17:04 +0200, Borislav Petkov wrote: > On Mon, Jul 24, 2017 at 02:49:30PM +0000, Kani, Toshimitsu wrote: > > We do not tell the error counts to customers. > > Please read what I said: do you tell your customers that the error > counts they're seeing (o

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

On Mon, 2017-07-24 at 17:04 +0200, Borislav Petkov wrote: > On Mon, Jul 24, 2017 at 02:49:30PM +0000, Kani, Toshimitsu wrote: > > We do not tell the error counts to customers. > > Please read what I said: do you tell your customers that the error > counts they're seeing (o

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

On Sat, 2017-07-22 at 08:28 +0200, Borislav Petkov wrote: > On Fri, Jul 21, 2017 at 06:38:52PM +0000, Kani, Toshimitsu wrote: > > Enterprise platforms have very different model (I do not say it's > > better for everyone from the cost perspective).  Typically, such > >

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

On Sat, 2017-07-22 at 08:28 +0200, Borislav Petkov wrote: > On Fri, Jul 21, 2017 at 06:38:52PM +0000, Kani, Toshimitsu wrote: > > Enterprise platforms have very different model (I do not say it's > > better for everyone from the cost perspective).  Typically, such > >

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

On Fri, 2017-07-21 at 19:23 +0200, Borislav Petkov wrote: : > Not only that: thresholds depend on the DIMM types which means, BIOS > must know what DIMM types are in there which I doubt. BIOS knows DIMM model from the SPD data. > So exposing that to configuration instead of "deciding" for

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

On Fri, 2017-07-21 at 19:23 +0200, Borislav Petkov wrote: : > Not only that: thresholds depend on the DIMM types which means, BIOS > must know what DIMM types are in there which I doubt. BIOS knows DIMM model from the SPD data. > So exposing that to configuration instead of "deciding" for

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

On Fri, 2017-07-21 at 14:01 -0300, Mauro Carvalho Chehab wrote: > Em Fri, 21 Jul 2017 16:40:20 + > "Kani, Toshimitsu" <toshi.k...@hpe.com> escreveu: > > > On Fri, 2017-07-21 at 12:44 -0300, Mauro Carvalho Chehab wrote: > > > Em Fri, 21 Jul 2017 15:34:50

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

On Fri, 2017-07-21 at 14:01 -0300, Mauro Carvalho Chehab wrote: > Em Fri, 21 Jul 2017 16:40:20 + > "Kani, Toshimitsu" escreveu: > > > On Fri, 2017-07-21 at 12:44 -0300, Mauro Carvalho Chehab wrote: > > > Em Fri, 21 Jul 2017 15:34:50 +

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

On Fri, 2017-07-21 at 12:44 -0300, Mauro Carvalho Chehab wrote: > Em Fri, 21 Jul 2017 15:34:50 + > "Kani, Toshimitsu" <toshi.k...@hpe.com> escreveu: > > > On Fri, 2017-07-21 at 17:13 +0200, Borislav Petkov wrote: > > > On Fri, Jul 21, 2017 at 03:08:

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

On Fri, 2017-07-21 at 12:44 -0300, Mauro Carvalho Chehab wrote: > Em Fri, 21 Jul 2017 15:34:50 + > "Kani, Toshimitsu" escreveu: > > > On Fri, 2017-07-21 at 17:13 +0200, Borislav Petkov wrote: > > > On Fri, Jul 21, 2017 at 03:08:41PM +, Kani, Tos

  1   2   3   4   >