[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 <o...@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.willi...@intel.com> > wrote: > > > On Sun, Oct 22, 2017 at 4:33 AM, Oren Berman <o...@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@lists.01.org > https://lists.01.org/mailman/listinfo/linux-nvdimm > _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
