Yes, that is weird.
Do you see the same issue in February 24 image? Or is this a new issue?


It seems some other module allocates RuntimeServicesData region in 
ReadyToBootEvent handler.
I am not sure if it is introduced by recent HiiDatabaseDxe change. Would you 
please try to set *PcdHiiOsRuntimeSupport|FALSE*?

I want to narrow down the issue.

If that is problem, we need consider a better place to construct the table.

Thank you
Yao Jiewen


> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ard Biesheuvel
> Sent: Friday, April 1, 2016 8:19 PM
> To: Yao, Jiewen <jiewen....@intel.com>
> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Gao, Liming
> <liming....@intel.com>
> Subject: Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table
> type issue
> 
> On 1 April 2016 at 14:16, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> > On 1 April 2016 at 09:25, Ard Biesheuvel <ard.biesheu...@linaro.org>
> wrote:
> >> On 1 April 2016 at 09:24, Ard Biesheuvel <ard.biesheu...@linaro.org>
> wrote:
> >>> 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.
> >>>
> >>
> >> Never mind, this is mandated by the spec for PE/COFF images.
> >
> > OK, looking at the debug output again, there is in fact a problem on
> > the BIOS side.
> > Please refer to the attached debug log.
> >
> > It shows this region in the memory map
> 
> Available  00000000F5B50000-00000000F5B6FFFF 0000000000000020
> 000000000000000F
> 
> and this region in the memory attributes table
> 
> RT_Data    00000000F5B50000-0000000000000000 0000000000000030
> 8000000000004000
> 
> This confuses the OS code, since it does not expect the available
> region in the memory map, but there is clearly something wrong on the
> firmware side.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Reply via email to