Glad to know BIOS is good. :-) Thank you Yao Jiewen
> -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Friday, April 1, 2016 12:08 AM > 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 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
