On 31 March 2016 at 15:33, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> On 31 March 2016 at 15:20, Yao, Jiewen <jiewen....@intel.com> wrote:
>> Hi Ard
>> Thanks for your log. Yes, it seems new issue, I have never encountered 
>> before.
>>
>> Here is what I found:
>>
>> 1) MemoryAttributeTable is always installed in ReadyToBoot event. (Sorry, I 
>> gave wrong info on EndOfDxe, that is for old properties table)
>>
>
> OK
>
>> 2) In this log, I have seen MemoryAttributeTable is installed 6 times. It 
>> means this system boot 6 boot options. First 5 fail, and last one success. I 
>> am not clear what device you want to boot, but it seems "Booting EFI Misc 
>> Device" category. It is also weird that RT_Data entry is changed every time. 
>> Does this boot device allocate/free RT_Data?
>>
>
> Good question, I can investigate
>
>> 3) In this log, it shows MemoryAttributeTable is always correct. See line 
>> 1427. I do not know why it is corrupt in efimemmap.log.
>> This memory attribute table is allocated in "BootServicesData" type memory. 
>> Are you sure that system does not corrupt BootServicesData when 
>> efimemmap.log is created?
>>
>> 4) So I suggest we check *when* this table is corrupted. I have 
>> MemoryAttributesDump UEFI APPLICATION (See attachment, password: 12345678). 
>> Maybe can you help run it in UEFI shell to see if MemoryAttributes table is 
>> correct or not?
>> We can use this way to narrow down the corruption - *when* it is created, or 
>> *after* it is created.
>>
>
> Shell> MemoryAttributesDump.efi
> MemoryAttributesTable:
>   Version         - 0x00000001
>   NumberOfEntries - 0x00000019
>   DescriptorSize  - 0x00000030
>
> Type       Start            End              # Pages          Attributes
> RT_Data    00000000F5B50000-0000000000000000 0000000000000030 8000000000004000
> RT_Code    00000000F5B80000-0000000000000000 0000000000000010 8000000000004000

Actually, I did find something strange here: these first two regions
are both set to EFI_MEMORY_XP, but the second one is
EfiRuntimeServicesCode

I am not sure if this is related, but it does look wrong to me.

Thanks,
Ard.


> RT_Code    00000000F5B90000-0000000000000000 0000000000000010 8000000000020000
> RT_Code    00000000F5BA0000-0000000000000000 0000000000000030 8000000000004000
> RT_Code    00000000F5BD0000-0000000000000000 0000000000000010 8000000000020000
> RT_Code    00000000F5BE0000-0000000000000000 0000000000000020 8000000000004000
> RT_Code    00000000F5C80000-0000000000000000 0000000000000010 8000000000004000
> RT_Code    00000000F5C90000-0000000000000000 0000000000000010 8000000000020000
> RT_Code    00000000F5CA0000-0000000000000000 0000000000000020 8000000000004000
> RT_Data    00000000F5CC0000-0000000000000000 0000000000000090 8000000000004000
> RT_Code    00000000F5D50000-0000000000000000 0000000000000010 8000000000004000
> RT_Code    00000000F5D60000-0000000000000000 0000000000000010 8000000000020000
> RT_Code    00000000F5D70000-0000000000000000 0000000000000030 8000000000004000
> RT_Data    00000000F5DA0000-0000000000000000 00000000000000F0 8000000000004000
> RT_Code    00000000F5E90000-0000000000000000 0000000000000010 8000000000004000
> RT_Code    00000000F5EA0000-0000000000000000 0000000000000010 8000000000020000
> RT_Code    00000000F5EB0000-0000000000000000 0000000000000030 8000000000004000
> RT_Data    00000000F5EE0000-0000000000000000 0000000000000050 8000000000004000
> RT_Code    00000000F5F30000-0000000000000000 0000000000000010 8000000000004000
> RT_Code    00000000F5F40000-0000000000000000 0000000000000010 8000000000020000
> RT_Code    00000000F5F50000-0000000000000000 0000000000000030 8000000000004000
> RT_Code    00000000FAF50000-0000000000000000 0000000000000010 8000000000004000
> RT_Code    00000000FAF60000-0000000000000000 0000000000000010 8000000000020000
> RT_Code    00000000FAF70000-0000000000000000 0000000000000020 8000000000004000
> RT_Data    00000000FAFA0000-0000000000000000 0000000000000050 8000000000004000
>
> So it looks like the table gets corrupted by the OS loader. I will
> investigate a bit more
>
> Thanks,
> Ard.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Reply via email to