On 31 March 2016 at 16:09, Yao, Jiewen <jiewen....@intel.com> wrote: > Thanks for your quick response. > > Then I will be waiting for your investigation result. > > If you see the value to have this dump tool check in, maybe we can put to > MdeModulePkg/Application. > Next time, we do not need share it via email. >
I have to apologise for the noise. This issue is an OS problem, not a firmware problem: if I dump the contents of the table very early during boot, it looks fine, but later when I process it, the first entry is corrupted. Thanks for the help! Ard. >> -----Original Message----- >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] >> Sent: Thursday, March 31, 2016 9:34 PM >> To: Yao, Jiewen <jiewen....@intel.com> >> Cc: Gao, Liming <liming....@intel.com>; edk2-devel@lists.01.org >> <edk2-de...@ml01.01.org> >> Subject: Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table >> type issue >> >> 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 >> 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
