From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 8EC6A224A9ED3 for ; Fri, 30 Mar 2018 09:38:49 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id 126-v6so8207057oig.0 for ; Fri, 30 Mar 2018 09:38:49 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1522422276.2693.268.camel@hpe.com> References: <152236282506.35558.2067249639136170490.stgit@djiang5-desk3.ch.intel.com> <1522422276.2693.268.camel@hpe.com> From: Dan Williams Date: Fri, 30 Mar 2018 09:38:48 -0700 Message-ID: Subject: Re: [PATCH 0/4] Adding support to parse BERT for libnvdimm List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: "Kani, Toshi" Cc: "Luck, Tony" , "linux-nvdimm@lists.01.org" , "rjw@rjwysocki.net" , "linux-acpi@vger.kernel.org" , "lenb@kernel.org" List-ID: On Fri, Mar 30, 2018 at 8:04 AM, Kani, Toshi wrote: > On Thu, 2018-03-29 at 15:37 -0700, Dave Jiang wrote: >> The following series implements support for parsing of the BERT records >> and adding the error memory ranges to nvdimm badblocks in order for the >> kernel to avoid prevent the kernel from accessing those areas. And with >> the addition of this support, we can surface the nd regions instead of waiting >> for ARS to complete. So the ARS handling is reworked to run in the >> background and not block nd region registration. > > Hi Dave, > > I agree on the problem, and adding an ability to obtain pmem badblocks > records at boot-time without waiting for a new ARS scan to complete is a > good option for users. > > However, I do not think using the BERT table is a good approach. This > requires FW to report pmem badblocks records with a new interface in > addition to ARS records, which FW already implements for pmem. ACPI 6.2 > defines Start ARS with Flags Bit[1] set to report badblocks record > without starting a new ARS scan. We set this bit after receiving a 0x81 > notification at this point. > > Can we use ARS with Flags bit[1] set at boot-time so that both OS and FW > can use the same ARS implementation? You have a point. The other benefit I see to this policy is that it hopefully convinces BIOS implementations to not run ARS at boot and leave it to the OS to manage it in the background. If the platform has any critical errors to report, i.e. ones that triggered a system reset, then it should be able to report them in the flag-bit1 case. This also lets the implementation be completely self contained to the nfit driver, and not grow any BERT entanglements that may or may not be valid for the persistent memory case. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm