Slightly correction:
“Persistent”-> EfiPersistentMemory (14)
“Reserved”  -> EfiReservedMemoryType(0)  

    On Thursday, July 20, 2017 10:56 AM, Soccer Liu <[email protected]> 
wrote:
 

 I am sorry for not being more clear.
In ACPI spec 2.6, the Table 15-317 has all the UEFI Memory Types and mapping to 
ACPI address range types.
Here are the actual types that I referred to:
“Persistent”-> EfiPersistentMemory (14)“Reserved”  -> Reserved type 15 
Apparently, only my private kernel works as expected when dealing with Reserved 
type (15) but cannot boot with any EfiPersistentMemory device. I did see a 
EfiPersistentMemory device working with Ubuntu OS. I am suspecting it's my 
environment issues (kconfig flags or others), I am curious about anyone has any 
idea on how to debug this kind of "does not boot issue" or anyone has seen 
EfiPersistentMemory  like this?

ThanksCheng-mean
 

    On Thursday, July 20, 2017 6:03 AM, Dan Williams <[email protected]> 
wrote:
 

 On Wed, Jul 19, 2017 at 5:04 PM, Soccer Liu <[email protected]> wrote:
> Hi:
>    I am trying to debug an issue related to  my private built kernel's (4.11 
>from upstream with ACPI/NFIT/NVDIMM enabled) interaction with a persistent 
>memory device's type.
> We have a way to emulate a software based NVDIMM device into a guest, which 
> is running my private built kernel. When the host set this emulated NVDIMM 
> device as Reserved type, I was able to see a pmem0 block device exposed and 
> everything seems to function correctly.however, when it's exposed as a 
> Persistent Memory type, the kernel does not boot and it has a black screen 
> and no usefully logging could help root cause this.
>  My questions are:
>  1. Is this a known issue for 4.11? 2. Is there any patches NIFT/NVDIMM 
>beyond 4.11 that's needed to get Persistent Memory type supported? 3. In this 
>case, is there anyway to debug this further?

When you say Persistent Memory Type, which type are you referring. The
spec compliant one is E820-type-7 or EFI- type-15. Linux also
understands E820-type-12 which went upstream before the official types
were defined.

E820-Type-12 is the problematic one, the others are equivalent to
Reserved (E820-Type-2).

All that said we have had functional support for all these types since
the 4.2 kernel, no kernel changes should be needed.

  
_______________________________________________
Linux-nvdimm mailing list
[email protected]
https://lists.01.org/mailman/listinfo/linux-nvdimm


   
_______________________________________________
Linux-nvdimm mailing list
[email protected]
https://lists.01.org/mailman/listinfo/linux-nvdimm

Reply via email to