From: Dan Williams <email@example.com>
To: "Kani, Toshi" <firstname.lastname@example.org>
Cc: "Luck, Tony" <email@example.com>,
Subject: Re: [PATCH 0/4] Adding support to parse BERT for libnvdimm
Date: Fri, 30 Mar 2018 09:38:48 -0700 [thread overview]
Message-ID: <CAPcyv4iBnOLrFyhZBpAhkrdkY42w7g125jQhxi2Qv6drC7HQdA@mail.gmail.com> (raw)
On Fri, Mar 30, 2018 at 8:04 AM, Kani, Toshi <firstname.lastname@example.org> 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 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 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
next prev parent reply other threads:[~2018-03-30 16:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-29 22:37 [PATCH 0/4] Adding support to parse BERT for libnvdimm Dave Jiang
2018-03-29 22:37 ` [PATCH 1/4] acpi: add find error record in BERT function Dave Jiang
2018-03-30 23:36 ` kbuild test robot
2018-03-29 22:37 ` [PATCH 2/4] acpi/libnvdimm: search through BERT records and add to nvdimm badblocks Dave Jiang
2018-03-29 22:37 ` [PATCH 3/4] acpi/nfit: removing ARS timeout and change scrubbing to delayed work Dave Jiang
2018-03-29 22:37 ` [PATCH 4/4] acpi/nfit: allow knob to disable ARS being issued at kernel boot Dave Jiang
2018-03-30 15:04 ` [PATCH 0/4] Adding support to parse BERT for libnvdimm Kani, Toshi
2018-03-30 16:38 ` Dan Williams [this message]
2018-03-30 16:45 ` Kani, Toshi
2018-03-30 16:49 ` Dave Jiang
2018-03-30 16:51 ` Kani, Toshi
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).