Re: [PATCH v4 3/6] libnvdimm, acpi, nfit: Add bus level dsm mask for pass thru.

On 07/04/2017 04:37 PM, Dan Williams wrote: > On Tue, Jul 4, 2017 at 1:08 PM, Jerry Hoemann wrote: >> On Sat, Jul 01, 2017 at 01:46:03PM -0700, Dan Williams wrote: >>> On Sat, Jul 1, 2017 at 1:38 PM, Jerry Hoemann wrote: On Sat, Jul 01, 2017 at

Re: [PATCH v4 3/6] libnvdimm, acpi, nfit: Add bus level dsm mask for pass thru.

On 07/04/2017 04:37 PM, Dan Williams wrote: > On Tue, Jul 4, 2017 at 1:08 PM, Jerry Hoemann wrote: >> On Sat, Jul 01, 2017 at 01:46:03PM -0700, Dan Williams wrote: >>> On Sat, Jul 1, 2017 at 1:38 PM, Jerry Hoemann wrote: On Sat, Jul 01, 2017 at 01:10:31PM -0700, Dan Williams wrote: > On

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 06/29/2017 06:58 PM, Dan Williams wrote: > On Thu, Jun 29, 2017 at 3:49 PM, Linda Knippers <linda.knipp...@hpe.com> > wrote: >>> The parent region of the namespace will have a 'volatile' type: >>> >>> # cat /sys/bus/nd/devices/region0/devtype >>>

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 06/29/2017 06:58 PM, Dan Williams wrote: > On Thu, Jun 29, 2017 at 3:49 PM, Linda Knippers > wrote: >>> The parent region of the namespace will have a 'volatile' type: >>> >>> # cat /sys/bus/nd/devices/region0/devtype >>> nd_volatile >> >>

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 6/29/2017 6:43 PM, Dan Williams wrote: On Thu, Jun 29, 2017 at 3:35 PM, Linda Knippers <linda.knipp...@hpe.com> wrote: On 06/29/2017 06:28 PM, Dan Williams wrote: On Thu, Jun 29, 2017 at 3:12 PM, Linda Knippers <linda.knipp...@hpe.com> wrote: [..] The /dev/pmem device name ju

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 6/29/2017 6:43 PM, Dan Williams wrote: On Thu, Jun 29, 2017 at 3:35 PM, Linda Knippers wrote: On 06/29/2017 06:28 PM, Dan Williams wrote: On Thu, Jun 29, 2017 at 3:12 PM, Linda Knippers wrote: [..] The /dev/pmem device name just tells you that your block device is hosted by a driver

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 06/29/2017 06:28 PM, Dan Williams wrote: > On Thu, Jun 29, 2017 at 3:12 PM, Linda Knippers <linda.knipp...@hpe.com> > wrote: > [..] >>> The /dev/pmem >>> device name just tells you that your block device is hosted by a >>> driver that knows how to han

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 06/29/2017 06:28 PM, Dan Williams wrote: > On Thu, Jun 29, 2017 at 3:12 PM, Linda Knippers > wrote: > [..] >>> The /dev/pmem >>> device name just tells you that your block device is hosted by a >>> driver that knows how to handle persistent memory constrai

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 6/29/2017 5:50 PM, Dan Williams wrote: On Thu, Jun 29, 2017 at 2:16 PM, Linda Knippers <linda.knipp...@hpe.com> wrote: On 06/29/2017 04:42 PM, Dan Williams wrote: On Thu, Jun 29, 2017 at 12:20 PM, Linda Knippers <linda.knipp...@hpe.com> wrote: On 06/29/2017 01:54 PM, Dan Wi

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 6/29/2017 5:50 PM, Dan Williams wrote: On Thu, Jun 29, 2017 at 2:16 PM, Linda Knippers wrote: On 06/29/2017 04:42 PM, Dan Williams wrote: On Thu, Jun 29, 2017 at 12:20 PM, Linda Knippers wrote: On 06/29/2017 01:54 PM, Dan Williams wrote: Allow volatile nfit ranges to participate

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 06/29/2017 04:42 PM, Dan Williams wrote: > On Thu, Jun 29, 2017 at 12:20 PM, Linda Knippers <linda.knipp...@hpe.com> > wrote: >> On 06/29/2017 01:54 PM, Dan Williams wrote: >>> Allow volatile nfit ranges to participate in all the same infrastructure >>> pr

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 06/29/2017 04:42 PM, Dan Williams wrote: > On Thu, Jun 29, 2017 at 12:20 PM, Linda Knippers > wrote: >> On 06/29/2017 01:54 PM, Dan Williams wrote: >>> Allow volatile nfit ranges to participate in all the same infrastructure >>> provided for persistent me

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 06/29/2017 01:54 PM, Dan Williams wrote: > Allow volatile nfit ranges to participate in all the same infrastructure > provided for persistent memory regions. This seems to be a bit more than "other rework". > A resulting resulting namespace > device will still be called "pmem", but the

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 06/29/2017 01:54 PM, Dan Williams wrote: > Allow volatile nfit ranges to participate in all the same infrastructure > provided for persistent memory regions. This seems to be a bit more than "other rework". > A resulting resulting namespace > device will still be called "pmem", but the

Re: [PATCH] Add support of NVDIMM memory error notification in ACPI 6.2

On 6/7/2017 5:33 PM, Kani, Toshimitsu wrote: On Wed, 2017-06-07 at 14:06 -0700, Dan Williams wrote: On Wed, Jun 7, 2017 at 1:57 PM, Kani, Toshimitsu wrote: On Wed, 2017-06-07 at 12:09 -0700, Dan Williams wrote: On Wed, Jun 7, 2017 at 11:49 AM, Toshi Kani

Re: [PATCH] Add support of NVDIMM memory error notification in ACPI 6.2

On 6/7/2017 5:33 PM, Kani, Toshimitsu wrote: On Wed, 2017-06-07 at 14:06 -0700, Dan Williams wrote: On Wed, Jun 7, 2017 at 1:57 PM, Kani, Toshimitsu wrote: On Wed, 2017-06-07 at 12:09 -0700, Dan Williams wrote: On Wed, Jun 7, 2017 at 11:49 AM, Toshi Kani wrote: : + +static void

Re: [PATCH] libnvdimm, region: sysfs trigger for nvdimm_flush()

On 04/21/2017 07:48 PM, Dan Williams wrote: > The nvdimm_flush() mechanism helps to reduce the impact of an ADR > (asynchronous-dimm-refresh) failure. The ADR mechanism handles flushing > platform WPQ (write-pending-queue) buffers when power is removed. The > nvdimm_flush() mechanism performs that

Re: [PATCH] libnvdimm, region: sysfs trigger for nvdimm_flush()

On 04/21/2017 07:48 PM, Dan Williams wrote: > The nvdimm_flush() mechanism helps to reduce the impact of an ADR > (asynchronous-dimm-refresh) failure. The ADR mechanism handles flushing > platform WPQ (write-pending-queue) buffers when power is removed. The > nvdimm_flush() mechanism performs that

Re: [PATCH 00/14] libnvdimm: support sub-divisions of pmem for 4.9

On 10/7/2016 3:52 PM, Dan Williams wrote: > On Fri, Oct 7, 2016 at 11:19 AM, Linda Knippers <linda.knipp...@hpe.com> > wrote: >> Hi Dan, >> >> A couple of general questions... >> >> On 10/7/2016 12:38 PM, Dan Williams wrote: >>> With t

Re: [PATCH 00/14] libnvdimm: support sub-divisions of pmem for 4.9

On 10/7/2016 3:52 PM, Dan Williams wrote: > On Fri, Oct 7, 2016 at 11:19 AM, Linda Knippers > wrote: >> Hi Dan, >> >> A couple of general questions... >> >> On 10/7/2016 12:38 PM, Dan Williams wrote: >>> With the arrival of the device-dax

Re: [PATCH 00/14] libnvdimm: support sub-divisions of pmem for 4.9

Hi Dan, A couple of general questions... On 10/7/2016 12:38 PM, Dan Williams wrote: > With the arrival of the device-dax facility in 4.7 a pmem namespace can > now be configured into a total of four distinct modes: 'raw', 'sector', > 'memory', and 'dax'. Where raw, sector, and memory are block

Re: [PATCH 00/14] libnvdimm: support sub-divisions of pmem for 4.9

Hi Dan, A couple of general questions... On 10/7/2016 12:38 PM, Dan Williams wrote: > With the arrival of the device-dax facility in 4.7 a pmem namespace can > now be configured into a total of four distinct modes: 'raw', 'sector', > 'memory', and 'dax'. Where raw, sector, and memory are block

Re: [PATCH] acpi, nfit: fix acpi event notifications for nfit

On 8/18/2016 3:48 PM, Dan Williams wrote: > On Thu, Aug 18, 2016 at 11:48 AM, Vishal Verma > wrote: >> The nfit driver had an acpi event notification handler, but it never >> would've worked because we weren't setting the >> ACPI_DRIVER_ALL_NOTIFY_EVENTS flag in

Re: [PATCH] acpi, nfit: fix acpi event notifications for nfit

On 8/18/2016 3:48 PM, Dan Williams wrote: > On Thu, Aug 18, 2016 at 11:48 AM, Vishal Verma > wrote: >> The nfit driver had an acpi event notification handler, but it never >> would've worked because we weren't setting the >> ACPI_DRIVER_ALL_NOTIFY_EVENTS flag in acpi_driver. > > Let's update

Re: [PATCH] Revert "cpufreq: pcc-cpufreq: update default value of cpuinfo_transition_latency"

On 07/22/2016 03:25 PM, Linda Knippers wrote: > > > On 7/22/2016 11:36 AM, Viresh Kumar wrote: >> On 22-07-16, 17:14, Andreas Herrmann wrote: >>> diff --git a/drivers/cpufreq/pcc-cpufreq.c b/drivers/cpufreq/pcc-cpufreq.c >>> index a7ecb9a..3f0ce2a 100644 >&g

Re: [PATCH] Revert "cpufreq: pcc-cpufreq: update default value of cpuinfo_transition_latency"

On 07/22/2016 03:25 PM, Linda Knippers wrote: > > > On 7/22/2016 11:36 AM, Viresh Kumar wrote: >> On 22-07-16, 17:14, Andreas Herrmann wrote: >>> diff --git a/drivers/cpufreq/pcc-cpufreq.c b/drivers/cpufreq/pcc-cpufreq.c >>> index a7ecb9a..3f0ce2a 100644 >&g

Re: [PATCH] Revert "cpufreq: pcc-cpufreq: update default value of cpuinfo_transition_latency"

On 7/22/2016 11:36 AM, Viresh Kumar wrote: > On 22-07-16, 17:14, Andreas Herrmann wrote: >> diff --git a/drivers/cpufreq/pcc-cpufreq.c b/drivers/cpufreq/pcc-cpufreq.c >> index a7ecb9a..3f0ce2a 100644 >> --- a/drivers/cpufreq/pcc-cpufreq.c >> +++ b/drivers/cpufreq/pcc-cpufreq.c >> @@ -555,8

Re: [PATCH] Revert "cpufreq: pcc-cpufreq: update default value of cpuinfo_transition_latency"

On 7/22/2016 11:36 AM, Viresh Kumar wrote: > On 22-07-16, 17:14, Andreas Herrmann wrote: >> diff --git a/drivers/cpufreq/pcc-cpufreq.c b/drivers/cpufreq/pcc-cpufreq.c >> index a7ecb9a..3f0ce2a 100644 >> --- a/drivers/cpufreq/pcc-cpufreq.c >> +++ b/drivers/cpufreq/pcc-cpufreq.c >> @@ -555,8

Re: [PATCH v2 3/3] nfit: do an ARS scrub on hitting a latent media error

On 7/20/2016 9:50 PM, Vishal Verma wrote: > When a latent (unknown to 'badblocks') error is encountered, it will > trigger a machine check exception. On a system with machine check > recovery, this will only SIGBUS the process(es) which had the bad page > mapped (as opposed to a kernel panic on

Re: [PATCH v2 3/3] nfit: do an ARS scrub on hitting a latent media error

On 7/20/2016 9:50 PM, Vishal Verma wrote: > When a latent (unknown to 'badblocks') error is encountered, it will > trigger a machine check exception. On a system with machine check > recovery, this will only SIGBUS the process(es) which had the bad page > mapped (as opposed to a kernel panic on

Re: [PATCH v2 3/3] nfit: do an ARS scrub on hitting a latent media error

On 7/21/2016 5:10 PM, Vishal Verma wrote: > On 07/21, Linda Knippers wrote: >> >> >> On 7/20/2016 9:50 PM, Vishal Verma wrote: >>> When a latent (unknown to 'badblocks') error is encountered, it will >>> trigger a machine check exception. On a

Re: [PATCH v2 3/3] nfit: do an ARS scrub on hitting a latent media error

On 7/21/2016 5:10 PM, Vishal Verma wrote: > On 07/21, Linda Knippers wrote: >> >> >> On 7/20/2016 9:50 PM, Vishal Verma wrote: >>> When a latent (unknown to 'badblocks') error is encountered, it will >>> trigger a machine check exception. On a

Re: [PATCH v2 2/3] nfit, libnvdimm: allow an ARS scrub to be triggered on demand

On 07/20/2016 09:50 PM, Vishal Verma wrote: > Normally, an ARS (Address Range Scrub) only happens at > boot/initialization time. There can however arise situations where a > bus-wide rescan is needed - notably, in the case of discovering a latent > media error, we should do a full rescan to figure

Re: [PATCH v2 2/3] nfit, libnvdimm: allow an ARS scrub to be triggered on demand

On 07/20/2016 09:50 PM, Vishal Verma wrote: > Normally, an ARS (Address Range Scrub) only happens at > boot/initialization time. There can however arise situations where a > bus-wide rescan is needed - notably, in the case of discovering a latent > media error, we should do a full rescan to figure

Re: [PATCH v2 2/3] nfit, libnvdimm: allow an ARS scrub to be triggered on demand

On 7/21/2016 3:46 PM, Dan Williams wrote: > On Thu, Jul 21, 2016 at 12:40 PM, Linda Knippers <linda.knipp...@hpe.com> > wrote: >> On 07/20/2016 09:50 PM, Vishal Verma wrote: >>> Normally, an ARS (Address Range Scrub) only happens at >>> boot/initiali

Re: [PATCH v2 2/3] nfit, libnvdimm: allow an ARS scrub to be triggered on demand

On 7/21/2016 3:46 PM, Dan Williams wrote: > On Thu, Jul 21, 2016 at 12:40 PM, Linda Knippers > wrote: >> On 07/20/2016 09:50 PM, Vishal Verma wrote: >>> Normally, an ARS (Address Range Scrub) only happens at >>> boot/initialization time. There can however arise s

Re: IOMMU+DMAR causing NMIs-s

On 7/13/2016 10:48 AM, Alex Williamson wrote: > On Wed, 13 Jul 2016 12:18:59 +0200 > Joerg Roedel wrote: > >> On Wed, Jul 13, 2016 at 12:58:24PM +0300, Meelis Roos wrote: > Just got http://kodu.ut.ee/~mroos/4.6-dmar-fault2.png when playing with > BIOS settings

Re: IOMMU+DMAR causing NMIs-s

On 7/13/2016 10:48 AM, Alex Williamson wrote: > On Wed, 13 Jul 2016 12:18:59 +0200 > Joerg Roedel wrote: > >> On Wed, Jul 13, 2016 at 12:58:24PM +0300, Meelis Roos wrote: > Just got http://kodu.ut.ee/~mroos/4.6-dmar-fault2.png when playing with > BIOS settings (disabling NUMA). It is

Re: [PATCH v2] libnvdimm, nfit: treat volatile virtual CD region as pmem

ed_. >> >> If we had multiple VCD regions userspace would benefit from some way >> to the distinguish them which is why sysfs exports the spa range >> index. If there are no memdev associations the spa range index is >> likely the only identifying attribute we have

Re: [PATCH v2] libnvdimm, nfit: treat volatile virtual CD region as pmem

gions userspace would benefit from some way >> to the distinguish them which is why sysfs exports the spa range >> index. If there are no memdev associations the spa range index is >> likely the only identifying attribute we have left. >> > > Yes, this is a benefit wh

Re: [PATCH] libnvdimm, nfit: treat volatile virtual CD region as read-only pmem

On 6/4/2016 7:01 AM, joeyli wrote: > Hi Dan, > > Thanks for your review. > > On Fri, Jun 03, 2016 at 12:27:34PM -0700, Dan Williams wrote: >> On Fri, Jun 3, 2016 at 12:13 AM, Lee, Chun-Yi >> wrote: >>> This patch adds codes to treat a volatile virtual CD region as a

Re: [PATCH] libnvdimm, nfit: treat volatile virtual CD region as read-only pmem

On 6/4/2016 7:01 AM, joeyli wrote: > Hi Dan, > > Thanks for your review. > > On Fri, Jun 03, 2016 at 12:27:34PM -0700, Dan Williams wrote: >> On Fri, Jun 3, 2016 at 12:13 AM, Lee, Chun-Yi >> wrote: >>> This patch adds codes to treat a volatile virtual CD region as a >>> read-only pmem region,

Re: [PATCH 01/13] driver core, libnvdimm: disable manual unbind of dimms while region active

On 6/6/2016 4:36 PM, Dan Williams wrote: > On Mon, Jun 6, 2016 at 1:20 PM, Linda Knippers <linda.knipp...@hpe.com> wrote: > [..] >>> A solution to the posted-write-queue flushing needs to be available >>> and a platform can choose to use flush hints or ADR. If

Re: [PATCH 01/13] driver core, libnvdimm: disable manual unbind of dimms while region active

On 6/6/2016 4:36 PM, Dan Williams wrote: > On Mon, Jun 6, 2016 at 1:20 PM, Linda Knippers wrote: > [..] >>> A solution to the posted-write-queue flushing needs to be available >>> and a platform can choose to use flush hints or ADR. If the NFIT >>> defines

Re: [PATCH 01/13] driver core, libnvdimm: disable manual unbind of dimms while region active

On 6/6/2016 3:46 PM, Dan Williams wrote: > On Mon, Jun 6, 2016 at 12:36 PM, Linda Knippers <linda.knipp...@hpe.com> > wrote: >> >> >> On 6/6/2016 3:31 PM, Dan Williams wrote: >>> On Mon, Jun 6, 2016 at 12:25 PM, Linda Knippers <linda.knipp...@hpe.com&

Re: [PATCH 01/13] driver core, libnvdimm: disable manual unbind of dimms while region active

On 6/6/2016 3:46 PM, Dan Williams wrote: > On Mon, Jun 6, 2016 at 12:36 PM, Linda Knippers > wrote: >> >> >> On 6/6/2016 3:31 PM, Dan Williams wrote: >>> On Mon, Jun 6, 2016 at 12:25 PM, Linda Knippers >>> wrote: >>>> On 6/4/2016 4:52 P

Re: [PATCH 01/13] driver core, libnvdimm: disable manual unbind of dimms while region active

On 6/6/2016 3:31 PM, Dan Williams wrote: > On Mon, Jun 6, 2016 at 12:25 PM, Linda Knippers <linda.knipp...@hpe.com> > wrote: >> On 6/4/2016 4:52 PM, Dan Williams wrote: >>> There are scenarios where we need a middle ground between disabling all >>> man

Re: [PATCH 01/13] driver core, libnvdimm: disable manual unbind of dimms while region active

On 6/6/2016 3:31 PM, Dan Williams wrote: > On Mon, Jun 6, 2016 at 12:25 PM, Linda Knippers > wrote: >> On 6/4/2016 4:52 PM, Dan Williams wrote: >>> There are scenarios where we need a middle ground between disabling all >>> manual bind/unbind attempts (v

Re: [PATCH 01/13] driver core, libnvdimm: disable manual unbind of dimms while region active

On 6/4/2016 4:52 PM, Dan Williams wrote: > There are scenarios where we need a middle ground between disabling all > manual bind/unbind attempts (via driver->suppress_bind_attrs) and > allowing unbind at any userspace-determined time. Pinning modules takes > away one vector for unwanted

Re: [PATCH 01/13] driver core, libnvdimm: disable manual unbind of dimms while region active

On 6/4/2016 4:52 PM, Dan Williams wrote: > There are scenarios where we need a middle ground between disabling all > manual bind/unbind attempts (via driver->suppress_bind_attrs) and > allowing unbind at any userspace-determined time. Pinning modules takes > away one vector for unwanted

Re: [PATCH v6] acpi: Issue _OSC call for native thermal interrupt handling

I raised a general concern on a previous patch so I found a 1P server with Skylake and HWP to try. This doesn't qualify as a tested-by since all I did was apply the patch and boot the server but hey, it booted. I do have a question below... On 3/23/2016 12:07 AM, Srinivas Pandruvada wrote: >

Re: [PATCH v6] acpi: Issue _OSC call for native thermal interrupt handling

I raised a general concern on a previous patch so I found a 1P server with Skylake and HWP to try. This doesn't qualify as a tested-by since all I did was apply the patch and boot the server but hey, it booted. I do have a question below... On 3/23/2016 12:07 AM, Srinivas Pandruvada wrote: >

Re: [PATCH v4] acpi: Issue _OSC call for native thermal interrupt handling

On 3/17/2016 2:24 PM, Srinivas Pandruvada wrote: > There are several reports of freeze on enabling HWP (Hardware PStates) > feature on Skylake based systems by Intel P states driver. The root > cause is identified as the HWP interrupts causing BIOS code to freeze. > HWP interrupts uses thermal

Re: [PATCH v4] acpi: Issue _OSC call for native thermal interrupt handling

On 3/17/2016 2:24 PM, Srinivas Pandruvada wrote: > There are several reports of freeze on enabling HWP (Hardware PStates) > feature on Skylake based systems by Intel P states driver. The root > cause is identified as the HWP interrupts causing BIOS code to freeze. > HWP interrupts uses thermal

Re: [PATCH v4] acpi: Issue _OSC call for native thermal interrupt handling

On 3/17/2016 4:36 PM, Srinivas Pandruvada wrote: > On Thu, 2016-03-17 at 16:03 -0400, Linda Knippers wrote: >> On 3/17/2016 2:24 PM, Srinivas Pandruvada wrote: >>> >>> There are several reports of freeze on enabling HWP (Hardware >>> PStates) >>>

Re: [PATCH v4] acpi: Issue _OSC call for native thermal interrupt handling

On 3/17/2016 4:36 PM, Srinivas Pandruvada wrote: > On Thu, 2016-03-17 at 16:03 -0400, Linda Knippers wrote: >> On 3/17/2016 2:24 PM, Srinivas Pandruvada wrote: >>> >>> There are several reports of freeze on enabling HWP (Hardware >>> PStates) >>>

Re: [PATCH v4] acpi: Issue _OSC call for native thermal interrupt handling

On 3/17/2016 5:12 PM, Srinivas Pandruvada wrote: > This needs to be done > before SMM code path looks for _OSC capabilities. The bit 12 of > _OSC in processor scope defines whether OS will handle thermal > interrupts. > When bit 12 is set to 1, OS will handle thermal

Re: [PATCH v4] acpi: Issue _OSC call for native thermal interrupt handling

On 3/17/2016 5:12 PM, Srinivas Pandruvada wrote: > This needs to be done > before SMM code path looks for _OSC capabilities. The bit 12 of > _OSC in processor scope defines whether OS will handle thermal > interrupts. > When bit 12 is set to 1, OS will handle thermal

Re: [PATCH v4] acpi: Issue _OSC call for native thermal interrupt handling

On 3/17/2016 8:17 PM, Rafael J. Wysocki wrote: >>> This change introduces a new function >>> acpi_early_processor_set_osc(), >>> which walks acpi name space and finds acpi processor object and >>> set capability via _OSC method to take over thermal LVT. >> Does this change

Re: [PATCH v4] acpi: Issue _OSC call for native thermal interrupt handling

On 3/17/2016 8:17 PM, Rafael J. Wysocki wrote: >>> This change introduces a new function >>> acpi_early_processor_set_osc(), >>> which walks acpi name space and finds acpi processor object and >>> set capability via _OSC method to take over thermal LVT. >> Does this change

Re: [PATCH 1/3] nfit: fix multi-interface dimm handling, acpi6.1 compatibility

On 2/8/2016 2:10 PM, Linda Knippers wrote: > On 2/8/2016 1:30 PM, Dan Williams wrote: >> ACPI 6.1 clarified that multi-interface dimms require multiple control >> region entries (DCRs) per dimm. Previously we were assuming that a >> control region is only present wh

Re: [PATCH 1/3] nfit: fix multi-interface dimm handling, acpi6.1 compatibility

On 2/8/2016 1:30 PM, Dan Williams wrote: > ACPI 6.1 clarified that multi-interface dimms require multiple control > region entries (DCRs) per dimm. Previously we were assuming that a > control region is only present when block-data-windows are present. We need to give this a quick test with

Re: [PATCH 1/3] nfit: fix multi-interface dimm handling, acpi6.1 compatibility

On 2/8/2016 1:30 PM, Dan Williams wrote: > ACPI 6.1 clarified that multi-interface dimms require multiple control > region entries (DCRs) per dimm. Previously we were assuming that a > control region is only present when block-data-windows are present. We need to give this a quick test with

Re: [PATCH 1/3] nfit: fix multi-interface dimm handling, acpi6.1 compatibility

On 2/8/2016 2:10 PM, Linda Knippers wrote: > On 2/8/2016 1:30 PM, Dan Williams wrote: >> ACPI 6.1 clarified that multi-interface dimms require multiple control >> region entries (DCRs) per dimm. Previously we were assuming that a >> control region is only present wh

Re: [PATCH 1/4] nvdimm: Add wrapper for IOCTL pass thru.

On 11/10/2015 3:27 PM, Dan Williams wrote: On Tue, Nov 10, 2015 at 11:49 AM, Jerry Hoemann wrote: On Tue, Nov 10, 2015 at 12:51:59PM -0500, Jeff Moyer wrote: Jerry Hoemann writes: Add IOCTL type 'P' to denote NVDIMM_TYPE_PASSTHRU. Can't you just make passthrough a separate command? If

Re: [PATCH 1/4] nvdimm: Add wrapper for IOCTL pass thru.

On 11/10/2015 3:27 PM, Dan Williams wrote: On Tue, Nov 10, 2015 at 11:49 AM, Jerry Hoemann wrote: On Tue, Nov 10, 2015 at 12:51:59PM -0500, Jeff Moyer wrote: Jerry Hoemann writes: Add IOCTL type 'P' to denote NVDIMM_TYPE_PASSTHRU. Can't you

Re: [PATCH 1/2] dax: fix O_DIRECT I/O to the last block of a blockdev

This patch and the 2/2 patch don't seem to have gone anywhere. Willy? or Ross? -- ljk On 8/14/2015 4:53 PM, Linda Knippers wrote: > On 8/14/2015 4:15 PM, Jeff Moyer wrote: >> commit bbab37ddc20b (block: Add support for DAX reads/writes to >> block devices) caused a regress

Re: [PATCH 1/2] dax: fix O_DIRECT I/O to the last block of a blockdev

This patch and the 2/2 patch don't seem to have gone anywhere. Willy? or Ross? -- ljk On 8/14/2015 4:53 PM, Linda Knippers wrote: > On 8/14/2015 4:15 PM, Jeff Moyer wrote: >> commit bbab37ddc20b (block: Add support for DAX reads/writes to >> block devices) caused a regress

[tip:x86/urgent] x86/mm/srat: Print non-volatile flag in SRAT

Commit-ID: 31e09b18c863718939e3e9c30eee55f9011d85ee Gitweb: http://git.kernel.org/tip/31e09b18c863718939e3e9c30eee55f9011d85ee Author: Linda Knippers AuthorDate: Tue, 1 Sep 2015 15:41:55 -0400 Committer: Ingo Molnar CommitDate: Wed, 2 Sep 2015 09:33:25 +0200 x86/mm/srat: Print non

[tip:x86/urgent] x86/mm/srat: Print non-volatile flag in SRAT

Commit-ID: 31e09b18c863718939e3e9c30eee55f9011d85ee Gitweb: http://git.kernel.org/tip/31e09b18c863718939e3e9c30eee55f9011d85ee Author: Linda Knippers <linda.knipp...@hp.com> AuthorDate: Tue, 1 Sep 2015 15:41:55 -0400 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed

[PATCH v2] arch/x86/mm/srat: Print non-volatile flag in SRAT

. If someone is setting it, we might want to ask them what they expect to happen with it. Right now this bit is only printed if all the ACPI debug information is turned on. Signed-off-by: Linda Knippers --- arch/x86/mm/srat.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch

Re: [PATCH] arch/x86/mm/srat: Print non-volatile flag in SRAT

On 9/1/2015 3:17 PM, Thomas Gleixner wrote: > On Tue, 1 Sep 2015, Linda Knippers wrote: >> Nobody checks this flag but it would be interesting to know if it's being >> set on any platforms. > > What you're omitting to explain, is WHY it would be interesting. With the addit

[PATCH] arch/x86/mm/srat: Print non-volatile flag in SRAT

Nobody checks this flag but it would be interesting to know if it's being set on any platforms. Signed-off-by: Linda Knippers --- arch/x86/mm/srat.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c index 66338a6..c2aea63 100644

Re: [PATCH] arch/x86/mm/srat: Print non-volatile flag in SRAT

On 9/1/2015 3:17 PM, Thomas Gleixner wrote: > On Tue, 1 Sep 2015, Linda Knippers wrote: >> Nobody checks this flag but it would be interesting to know if it's being >> set on any platforms. > > What you're omitting to explain, is WHY it would be interesting. With the addit

[PATCH v2] arch/x86/mm/srat: Print non-volatile flag in SRAT

. If someone is setting it, we might want to ask them what they expect to happen with it. Right now this bit is only printed if all the ACPI debug information is turned on. Signed-off-by: Linda Knippers <linda.knipp...@hp.com> --- arch/x86/mm/srat.c | 5 +++-- 1 file changed, 3 insertions

[PATCH] arch/x86/mm/srat: Print non-volatile flag in SRAT

Nobody checks this flag but it would be interesting to know if it's being set on any platforms. Signed-off-by: Linda Knippers <linda.knipp...@hp.com> --- arch/x86/mm/srat.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c

Re: [PATCH 2/2]: acpica/nfit: Rename not-armed bit definition

On 8/27/2015 1:04 PM, Dan Williams wrote: > On Thu, Aug 27, 2015 at 9:32 AM, Linda Knippers wrote: >> I know this seems like a nit but we've going to live with this stuff for >> a long time. > > Along those lines, Bob just came by my office and gave me a decisive > argu

Re: [PATCH 2/2]: acpica/nfit: Rename not-armed bit definition

On 8/27/2015 11:54 AM, Dan Williams wrote: > On Thu, Aug 27, 2015 at 8:35 AM, Linda Knippers wrote: >> On 8/27/2015 11:30 AM, Dan Williams wrote: >>> On Thu, Aug 27, 2015 at 7:43 AM, Linda Knippers >>> wrote: >>>> I don't see why we can't fix

Re: [PATCH 2/2]: acpica/nfit: Rename not-armed bit definition

On 8/27/2015 11:30 AM, Dan Williams wrote: > On Thu, Aug 27, 2015 at 7:43 AM, Linda Knippers wrote: >> I don't see why we can't fix the names so they make sense now before there >> is hardware in the market. People doing testing and debugging look at stuff >> in /sys and

Re: [PATCH 2/2]: acpica/nfit: Rename not-armed bit definition

On 8/26/2015 6:00 PM, Dan Williams wrote: > On Wed, Aug 26, 2015 at 2:44 PM, Toshi Kani wrote: >> On Wed, 2015-08-26 at 14:30 -0700, Dan Williams wrote: >>> On Wed, Aug 26, 2015 at 2:12 PM, Toshi Kani wrote: On Wed, 2015-08-26 at 10:16 -0700, Dan Williams wrote: > On Wed, Aug 26, 2015

Re: [PATCH 2/2]: acpica/nfit: Rename not-armed bit definition

On 8/26/2015 6:00 PM, Dan Williams wrote: On Wed, Aug 26, 2015 at 2:44 PM, Toshi Kani toshi.k...@hp.com wrote: On Wed, 2015-08-26 at 14:30 -0700, Dan Williams wrote: On Wed, Aug 26, 2015 at 2:12 PM, Toshi Kani toshi.k...@hp.com wrote: On Wed, 2015-08-26 at 10:16 -0700, Dan Williams wrote: On

Re: [PATCH 2/2]: acpica/nfit: Rename not-armed bit definition

On 8/27/2015 11:30 AM, Dan Williams wrote: On Thu, Aug 27, 2015 at 7:43 AM, Linda Knippers linda.knipp...@hp.com wrote: I don't see why we can't fix the names so they make sense now before there is hardware in the market. People doing testing and debugging look at stuff in /sys and they write

Re: [PATCH 2/2]: acpica/nfit: Rename not-armed bit definition

On 8/27/2015 1:04 PM, Dan Williams wrote: On Thu, Aug 27, 2015 at 9:32 AM, Linda Knippers linda.knipp...@hp.com wrote: I know this seems like a nit but we've going to live with this stuff for a long time. Along those lines, Bob just came by my office and gave me a decisive argument that I

Re: [PATCH 2/2]: acpica/nfit: Rename not-armed bit definition

On 8/27/2015 11:54 AM, Dan Williams wrote: On Thu, Aug 27, 2015 at 8:35 AM, Linda Knippers linda.knipp...@hp.com wrote: On 8/27/2015 11:30 AM, Dan Williams wrote: On Thu, Aug 27, 2015 at 7:43 AM, Linda Knippers linda.knipp...@hp.com wrote: I don't see why we can't fix the names so they make

Re: [PATCH 2/2]: acpica/nfit: Rename not-armed bit definition

On 8/26/2015 1:16 PM, Dan Williams wrote: > On Wed, Aug 26, 2015 at 9:20 AM, Toshi Kani wrote: >> ACPI 6.0 NFIT Memory Device State Flags in Table 5-129 defines >> bit 3 as follows. >> >> Bit [3] set to 1 to indicate that the Memory Device is observed >> to be not armed prior to OSPM hand

Re: [PATCH 2/2]: acpica/nfit: Rename not-armed bit definition

On 8/26/2015 1:16 PM, Dan Williams wrote: On Wed, Aug 26, 2015 at 9:20 AM, Toshi Kani toshi.k...@hp.com wrote: ACPI 6.0 NFIT Memory Device State Flags in Table 5-129 defines bit 3 as follows. Bit [3] set to 1 to indicate that the Memory Device is observed to be not armed prior to OSPM

Re: [PATCH 1/2] dax: fix O_DIRECT I/O to the last block of a blockdev

ng > get_block. > > Thanks to willy for simplifying my original patch. > > Signed-off-by: Jeff Moyer Tested-by: Linda Knippers > --- > fs/dax.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/fs/dax.c b/fs/dax.c > index a7f77e1..ef35a20

Re: [PATCH 1/2] dax: fix O_DIRECT I/O to the last block of a blockdev

for simplifying my original patch. Signed-off-by: Jeff Moyer jmo...@redhat.com Tested-by: Linda Knippers linda.knipp...@hp.com --- fs/dax.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/dax.c b/fs/dax.c index a7f77e1..ef35a20 100644 --- a/fs/dax.c +++ b/fs/dax.c

Re: regression introduced by "block: Add support for DAX reads/writes to block devices"

On 8/13/2015 1:14 PM, Jeff Moyer wrote: > Linda Knippers writes: > >>> I'd be fine with changing the persistent memory block device to only >>> support 4k logical, 4k physical block size. That probably makes the >>> most sense. >> >> If that

Re: regression introduced by "block: Add support for DAX reads/writes to block devices"

On 8/13/2015 10:00 AM, Jeff Moyer wrote: > Boaz Harrosh writes: > >> On 08/13/2015 12:11 AM, Jeff Moyer wrote: >>> Boaz Harrosh writes: >>> On 08/07/2015 11:41 PM, Jeff Moyer wrote: <> > >> We need to cope with the case where the end of a partition isn't on a >> page

Re: regression introduced by block: Add support for DAX reads/writes to block devices

On 8/13/2015 10:00 AM, Jeff Moyer wrote: Boaz Harrosh b...@plexistor.com writes: On 08/13/2015 12:11 AM, Jeff Moyer wrote: Boaz Harrosh b...@plexistor.com writes: On 08/07/2015 11:41 PM, Jeff Moyer wrote: We need to cope with the case where the end of a partition isn't on a page

Re: regression introduced by block: Add support for DAX reads/writes to block devices

On 8/13/2015 1:14 PM, Jeff Moyer wrote: Linda Knippers linda.knipp...@hp.com writes: I'd be fine with changing the persistent memory block device to only support 4k logical, 4k physical block size. That probably makes the most sense. If that's what we want, the current patch doesn't do

Re: regression introduced by "block: Add support for DAX reads/writes to block devices"

On 8/10/2015 5:27 PM, Dave Chinner wrote: > On Mon, Aug 10, 2015 at 12:32:08PM -0400, Linda Knippers wrote: >> On 8/9/2015 4:52 AM, Boaz Harrosh wrote: >>> On 08/06/2015 11:34 PM, Dave Chinner wrote: >>>> On Thu, Aug 06, 2015 at 10:52:47AM +0300, Boaz Harrosh wrote

Re: regression introduced by "block: Add support for DAX reads/writes to block devices"

On 8/9/2015 4:52 AM, Boaz Harrosh wrote: > On 08/06/2015 11:34 PM, Dave Chinner wrote: >> On Thu, Aug 06, 2015 at 10:52:47AM +0300, Boaz Harrosh wrote: >>> On 08/06/2015 06:24 AM, Dave Chinner wrote: >>>> On Wed, Aug 05, 2015 at 09:42:54PM -0400, Linda Knippers wrote

Re: regression introduced by block: Add support for DAX reads/writes to block devices

On 8/9/2015 4:52 AM, Boaz Harrosh wrote: On 08/06/2015 11:34 PM, Dave Chinner wrote: On Thu, Aug 06, 2015 at 10:52:47AM +0300, Boaz Harrosh wrote: On 08/06/2015 06:24 AM, Dave Chinner wrote: On Wed, Aug 05, 2015 at 09:42:54PM -0400, Linda Knippers wrote: On 08/05/2015 06:01 PM, Dave Chinner

Re: regression introduced by block: Add support for DAX reads/writes to block devices

On 8/10/2015 5:27 PM, Dave Chinner wrote: On Mon, Aug 10, 2015 at 12:32:08PM -0400, Linda Knippers wrote: On 8/9/2015 4:52 AM, Boaz Harrosh wrote: On 08/06/2015 11:34 PM, Dave Chinner wrote: On Thu, Aug 06, 2015 at 10:52:47AM +0300, Boaz Harrosh wrote: On 08/06/2015 06:24 AM, Dave Chinner

Re: regression introduced by "block: Add support for DAX reads/writes to block devices"

On 08/05/2015 06:01 PM, Dave Chinner wrote: > On Wed, Aug 05, 2015 at 04:19:08PM -0400, Jeff Moyer wrote: >> Hi, Matthew, >> >> Linda Knippers noticed that commit (bbab37ddc20b) breaks mkfs.xfs: >> >> # mkfs -t xfs -f /dev/pmem0 >> meta-data=/dev/pmem0

Re: regression introduced by block: Add support for DAX reads/writes to block devices

On 08/05/2015 06:01 PM, Dave Chinner wrote: On Wed, Aug 05, 2015 at 04:19:08PM -0400, Jeff Moyer wrote: Hi, Matthew, Linda Knippers noticed that commit (bbab37ddc20b) breaks mkfs.xfs: # mkfs -t xfs -f /dev/pmem0 meta-data=/dev/pmem0 isize=256agcount=4, agsize=524288 blks

Re: [Linux-nvdimm] [PATCH v2 08/20] libnd, nd_acpi: regions (block-data-window, persistent memory, volatile memory)

On 5/28/2015 3:59 PM, Dan Williams wrote: > On Thu, May 28, 2015 at 11:36 AM, Toshi Kani wrote: >> On Sat, 2015-05-09 at 16:55 -0700, Dan Williams wrote: >>> On Mon, May 4, 2015 at 1:26 PM, Toshi Kani wrote: On Tue, 2015-04-28 at 14:24 -0400, Dan Williams wrote: >> : The libnd

Re: [Linux-nvdimm] [PATCH v2 08/20] libnd, nd_acpi: regions (block-data-window, persistent memory, volatile memory)

On 5/28/2015 3:59 PM, Dan Williams wrote: On Thu, May 28, 2015 at 11:36 AM, Toshi Kani toshi.k...@hp.com wrote: On Sat, 2015-05-09 at 16:55 -0700, Dan Williams wrote: On Mon, May 4, 2015 at 1:26 PM, Toshi Kani toshi.k...@hp.com wrote: On Tue, 2015-04-28 at 14:24 -0400, Dan Williams wrote: :

  1   2   >