From: "Kani, Toshi" <toshi.kani-ZPxbGqLxI0U@public.gmane.org>
To: "dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org"
<dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"dave.jiang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org"
<dave.jiang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: "linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org"
<linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org>,
"tony.luck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org"
<tony.luck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org"
<rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>,
"linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org"
<lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH 0/4] Adding support to parse BERT for libnvdimm
Date: Fri, 30 Mar 2018 15:04:58 +0000 [thread overview]
Message-ID: <1522422276.2693.268.camel@hpe.com> (raw)
In-Reply-To: <152236282506.35558.2067249639136170490.stgit-Cxk7aZI4ujnJARH06PadV2t3HXsI98Cx0E9HWUfgJXw@public.gmane.org>
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?
Thanks,
-Toshi
WARNING: multiple messages have this Message-ID (diff)
From: "Kani, Toshi" <toshi.kani@hpe.com>
To: "dan.j.williams@intel.com" <dan.j.williams@intel.com>,
"dave.jiang@intel.com" <dave.jiang@intel.com>
Cc: "linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
"tony.luck@intel.com" <tony.luck@intel.com>,
"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [PATCH 0/4] Adding support to parse BERT for libnvdimm
Date: Fri, 30 Mar 2018 15:04:58 +0000 [thread overview]
Message-ID: <1522422276.2693.268.camel@hpe.com> (raw)
In-Reply-To: <152236282506.35558.2067249639136170490.stgit@djiang5-desk3.ch.intel.com>
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?
Thanks,
-Toshi
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
next prev parent reply other threads:[~2018-03-30 15:04 UTC|newest]
Thread overview: 22+ 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 ` Dave Jiang
[not found] ` <152236282506.35558.2067249639136170490.stgit-Cxk7aZI4ujnJARH06PadV2t3HXsI98Cx0E9HWUfgJXw@public.gmane.org>
2018-03-29 22:37 ` [PATCH 1/4] acpi: add find error record in BERT function Dave Jiang
2018-03-29 22:37 ` Dave Jiang
[not found] ` <152236302712.35558.17322719540329044966.stgit-Cxk7aZI4ujnJARH06PadV2t3HXsI98Cx0E9HWUfgJXw@public.gmane.org>
2018-03-30 23:36 ` kbuild test robot
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 ` 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 ` 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-29 22:37 ` Dave Jiang
2018-03-30 15:04 ` Kani, Toshi [this message]
2018-03-30 15:04 ` [PATCH 0/4] Adding support to parse BERT for libnvdimm Kani, Toshi
[not found] ` <1522422276.2693.268.camel-ZPxbGqLxI0U@public.gmane.org>
2018-03-30 16:38 ` Dan Williams
2018-03-30 16:38 ` Dan Williams
[not found] ` <CAPcyv4iBnOLrFyhZBpAhkrdkY42w7g125jQhxi2Qv6drC7HQdA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-03-30 16:45 ` Kani, Toshi
2018-03-30 16:45 ` Kani, Toshi
[not found] ` <1522428337.2693.271.camel-ZPxbGqLxI0U@public.gmane.org>
2018-03-30 16:49 ` Dave Jiang
2018-03-30 16:49 ` Dave Jiang
[not found] ` <02d3c416-6840-2d72-6ebf-75b9da606f7c-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-03-30 16:51 ` Kani, Toshi
2018-03-30 16:51 ` Kani, Toshi
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1522422276.2693.268.camel@hpe.com \
--to=toshi.kani-zpxbgqlxi0u@public.gmane.org \
--cc=dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=dave.jiang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org \
--cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \
--cc=tony.luck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.