8:23 a.m.
You can try to force a legacy pmem device with memmap=XX!YY kernel
parameter.
On Thu, Dec 28, 2017 at 8:16 PM, Dan Williams <dan.j.williams(a)intel.com>
wrote:
Type-7 only tells the kernel to reserve the memory range. NFIT carves
that
reservation into pmem devices. Type-12 skips the reservation and creates a
pmem device directly. There is no workaround if the platform only has a
BIOS that produces a type-12 range.
On Thursday, December 28, 2017, Oren Berman <oren(a)lightbitslabs.com>
wrote:
> Thanks Dan.
> I understand the shortcomings of using legacy mode but currently my
problem
> is that TYPE 12 is detected and I can use dax even in legacy mode but for
> some reason type 7 is not. Is there a way to force it be treated as
legacy
> as well.
> The reason I am asking is that I am not sure I can change my bios and I
> know at least that type 12 NVDIMM is working for me.
>
> BR
> Oren
>
>
>
> On 28 December 2017 at 11:14, Dan Williams <dan.j.williams(a)intel.com>
> wrote:
>
> > [sent from my phone, forgive formatting]
> >
> > Your BIOS would need to put SPA range entries in the ACPI NFIT. The
> > problem with legacy pmem ranges in the e820 table is that it omits
> critical
> > details like battery status and whether the platform supports flushing
> > memory controller buffers at power loss (ADR).
> >
> > The NFIT can also reliably communicate NUMA information for NVDIMMs
that
> > e820 does not.
> >
> > On Wednesday, December 27, 2017, Oren Berman <oren(a)lightbitslabs.com>
> > wrote:
> >
> >> Hi
> >>
> >> I have a question regrading NVDIMM detection.
> >>
> >> When we are working with NVDIMM of type 12 it is detected by the linux
> in
> >> legacy mode and we can
> >> accesses it as pmem or dax device. we have an e820 bios.
> >>
> >> When we are using a type 7 NVDIMM it is reported by the linux as
> >> persistence type 7 memory but there is no pmem or dax device created.
> >> Linux Kernel identifies this memory in the e820 table but it does not
> >> trigger nvdimm probe for it.
> >> Do you know what could be the cause? Is their a workaround for that?
> >> Can it still be treated as legacy mode so we can access it through
> >> pmem/dax
> >> device?
> >>
> >> BR
> >> Oren Berman
> >>
> >> On 22 October 2017 at 16:52, Dan Williams <dan.j.williams(a)intel.com>
> >> wrote:
> >>
> >> > On Sun, Oct 22, 2017 at 4:33 AM, Oren Berman <
oren(a)lightbitslabs.com>
> >> > wrote:
> >> > > Hi Ross
> >> > >
> >> > > Thanks for the speedy reply. I am also adding the public list to
> this
> >> > > thread as you suggested.
> >> > >
> >> > > We have tried to dump the SPA table and this is what we get:
> >> > >
> >> > > /*
> >> > > * Intel ACPI Component Architecture
> >> > > * AML/ASL+ Disassembler version 20160108-64
> >> > > * Copyright (c) 2000 - 2016 Intel Corporation
> >> > > *
> >> > > * Disassembly of NFIT, Sun Oct 22 10:46:19 2017
> >> > > *
> >> > > * ACPI Data Table [NFIT]
> >> > > *
> >> > > * Format: [HexOffset DecimalOffset ByteLength] FieldName :
> >> FieldValue
> >> > > */
> >> > >
> >> > > [000h 0000 4] Signature : "NFIT"
[NVDIMM
> >> Firmware
> >> > > Interface Table]
> >> > > [004h 0004 4] Table Length : 00000028
> >> > > [008h 0008 1] Revision : 01
> >> > > [009h 0009 1] Checksum : B2
> >> > > [00Ah 0010 6] Oem ID :
"SUPERM"
> >> > > [010h 0016 8] Oem Table ID :
"SMCI--MB"
> >> > > [018h 0024 4] Oem Revision : 00000001
> >> > > [01Ch 0028 4] Asl Compiler ID : " "
> >> > > [020h 0032 4] Asl Compiler Revision : 00000001
> >> > >
> >> > > [024h 0036 4] Reserved : 00000000
> >> > >
> >> > > Raw Table Data: Length 40 (0x28)
> >> > >
> >> > > 0000: 4E 46 49 54 28 00 00 00 01 B2 53 55 50 45 52 4D //
> >> > NFIT(.....SUPERM
> >> > > 0010: 53 4D 43 49 2D 2D 4D 42 01 00 00 00 01 00 00 00 //
> >> > SMCI--MB........
> >> > > 0020: 01 00 00 00 00 00 00 00
> >> > >
> >> > > As you can see the memory region info is missing.
> >> > >
> >> > > This specific check was done on a supermicro server.
> >> > > We also performed a bios update but the results were the same.
> >> > >
> >> > > As said before ,the pmem devices are detected correctly and we
> >> verified
> >> > > that they correspond to different numa nodes using the PCM
> >> > utility.However,
> >> > > linux still reports both pmem devices to be on the same numa -
Numa
> >> 0.
> >> > >
> >> > > If this information is missing, why pmem devices and address
ranges
> >> are
> >> > > still detected correctly?
> >> >
> >> > I suspect your BIOS might be using E820-type-12 to describe the pmem
> >> > ranges which is not compliant with the ACPI specification and would
> >> > need a BIOS change.
> >> >
> >> > > Is there another table that we need to check?
> >> >
> >> > You can dump /proc/iomem. If it shows "Persistent Memory
(legacy)"
> >> > then the BIOS is using the E820-type-12 description scheme which
does
> >> > not include NUMA information.
> >> >
> >> _______________________________________________
> >> Linux-nvdimm mailing list
> >> Linux-nvdimm(a)lists.01.org
> >> https://lists.01.org/mailman/listinfo/linux-nvdimm
> >>
> >
> _______________________________________________
> Linux-nvdimm mailing list
> Linux-nvdimm(a)lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm
>
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm(a)lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm