Re: [edk2] Question about memory map entries
Hi Andrew. Thanks for the clarification! Rafael Em qua, 8 de ago de 2018 às 16:14, Andrew Fish escreveu: > > On Aug 8, 2018, at 10:31 AM, Rafael Machado < > rafaelrodrigues.mach...@gmail.com> wrote: > > Hi everyone > > One question that was not answered and that could help us, is about > skipping the MemoryTypeInfo variable usage. > Is there any way to do this skip at a UEFI App ? > Simple erasing the MemoryTypeInfo var seems a little to violent from our > perspective. What do you think? > > Seems the system we're having this problem has some inconsistency when > filling the MemoryTypeInfo var before exiting the previous boot, and > seems to consider the BootServices memory type also to be stored at the > var. Does anyone remember of this kind of issue on some system in the past? > > > No we do that all the time to remove fragmentation from the memory map and > it does not > > Thanks, > > Andrew Fish > > Thanks and Regards > Rafael > > Em qua, 8 de ago de 2018 às 08:55, Rafael Machado < > rafaelrodrigues.mach...@gmail.com> escreveu: > >> Hi Jiewen >> >> Thanks for highlighting this. >> Just checked and we just add the Reserved/Acpi/Runtime types. >> >> Seems the guess that this would be related to the MemoryTypeInfo var is >> not the correct way to follow. >> >> We'll keep working on it, maybe asking more questions to the community in >> future. >> Thank you all for the help and guidance! >> In case someone has any comment or idea, please feel free to share. >> >> Rafael >> >> >> >> Em ter, 7 de ago de 2018 às 19:42, Yao, Jiewen >> escreveu: >> >>> Hi >>> >>> It is unclear to me that which type you have put to MemoryTypeInfo table. >>> >>> >>> >>> By design, we only need put Reserved/Acpi/Runtime, which should be quite >>> small. >>> >>> >>> >>> Do you put any other type into MemoryTypeInfo table? >>> >>> >>> >>> Thank you >>> >>> Yao Jiewen >>> >>> >>> >>> *From:* Rafael Machado [mailto:rafaelrodrigues.mach...@gmail.com] >>> *Sent:* Wednesday, August 8, 2018 3:12 AM >>> *To:* Laszlo Ersek >>> *Cc:* Andrew Fish ; Ni, Ruiyu ; >>> edk2-devel@lists.01.org; Yao, Jiewen >>> >>> >>> *Subject:* Re: [edk2] Question about memory map entries >>> >>> >>> >>> Hi everyone >>> >>> >>> >>> Based on the information shared by the members, the understanding is >>> that the current state of the system may impact fuutre boots. >>> >>> The problem is that in my case, due to specific requirements, before >>> booting we need to stress the system's memory, allocating a big amount of >>> memory and doing some memory validation algorithms. >>> >>> So the high number of allocations and frees is by choice and not by >>> mistakes. >>> >>> >>> >>> Considering this. Is there any way to bypass the MemoryTypeInformation >>> var store actions? >>> >>> >>> >>> Thanks and Regards >>> >>> Rafael >>> >>> >>> >>> Em qui, 2 de ago de 2018 às 17:39, Laszlo Ersek >>> escreveu: >>> >>> On 08/02/18 21:18, Rafael Machado wrote: >>> > Just found something interesting. >>> > Based on the logs from the serial port. >>> > >>> > This system works fine: >>> > >>> > "PeiInstallPeiMemory MemoryBegin 0x93D5, MemoryLength 0xA2B >>> > Temp Stack : BaseAddress=0x40 Length=0x8 >>> > Temp Heap : BaseAddress=0x48 Length=0x8 >>> > Total temporary memory:1048576 bytes. >>> > temporary memory stack ever used: 524288 bytes. >>> > temporary memory heap used: 63304 bytes. >>> > Old Stack size 524288, New stack size 524288 >>> > Stack Hob: BaseAddress=0x93D5 Length=0x8 >>> > Heap Offset = 0x9395 Stack Offset = 0x9395 >>> > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi" >>> > ... >>> > "CoreInitializeMemoryServices: >>> > BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded - >>> > 0x5AC" >>> > >>> > This one is bricked: >>> > >>> > "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9
Re: [edk2] Question about memory map entries
> On Aug 8, 2018, at 10:31 AM, Rafael Machado > wrote: > > Hi everyone > > One question that was not answered and that could help us, is about skipping > the MemoryTypeInfo variable usage. > Is there any way to do this skip at a UEFI App ? > Simple erasing the MemoryTypeInfo var seems a little to violent from our > perspective. What do you think? > > Seems the system we're having this problem has some inconsistency when > filling the MemoryTypeInfo var before exiting the previous boot, and seems > to consider the BootServices memory type also to be stored at the var. Does > anyone remember of this kind of issue on some system in the past? > No we do that all the time to remove fragmentation from the memory map and it does not Thanks, Andrew Fish > Thanks and Regards > Rafael > > Em qua, 8 de ago de 2018 às 08:55, Rafael Machado > <mailto:rafaelrodrigues.mach...@gmail.com>> escreveu: > Hi Jiewen > > Thanks for highlighting this. > Just checked and we just add the Reserved/Acpi/Runtime types. > > Seems the guess that this would be related to the MemoryTypeInfo var is not > the correct way to follow. > > We'll keep working on it, maybe asking more questions to the community in > future. > Thank you all for the help and guidance! > In case someone has any comment or idea, please feel free to share. > > Rafael > > > > Em ter, 7 de ago de 2018 às 19:42, Yao, Jiewen <mailto:jiewen@intel.com>> escreveu: > Hi > > It is unclear to me that which type you have put to MemoryTypeInfo table. > > > > By design, we only need put Reserved/Acpi/Runtime, which should be quite > small. > > > > Do you put any other type into MemoryTypeInfo table? > > > > Thank you > > Yao Jiewen > > <> > <>From: Rafael Machado [mailto:rafaelrodrigues.mach...@gmail.com > <mailto:rafaelrodrigues.mach...@gmail.com>] > Sent: Wednesday, August 8, 2018 3:12 AM > To: Laszlo Ersek mailto:ler...@redhat.com>> > Cc: Andrew Fish mailto:af...@apple.com>>; Ni, Ruiyu > mailto:ruiyu...@intel.com>>; edk2-devel@lists.01.org > <mailto:edk2-devel@lists.01.org>; Yao, Jiewen <mailto:jiewen@intel.com>> > > > Subject: Re: [edk2] Question about memory map entries > > > > > Hi everyone > > > > Based on the information shared by the members, the understanding is that the > current state of the system may impact fuutre boots. > > The problem is that in my case, due to specific requirements, before booting > we need to stress the system's memory, allocating a big amount of memory and > doing some memory validation algorithms. > > So the high number of allocations and frees is by choice and not by mistakes. > > > > Considering this. Is there any way to bypass the MemoryTypeInformation var > store actions? > > > > Thanks and Regards > > Rafael > > > > Em qui, 2 de ago de 2018 às 17:39, Laszlo Ersek <mailto:ler...@redhat.com>> escreveu: > > On 08/02/18 21:18, Rafael Machado wrote: > > Just found something interesting. > > Based on the logs from the serial port. > > > > This system works fine: > > > > "PeiInstallPeiMemory MemoryBegin 0x93D5, MemoryLength 0xA2B > > Temp Stack : BaseAddress=0x40 Length=0x8 > > Temp Heap : BaseAddress=0x48 Length=0x8 > > Total temporary memory:1048576 bytes. > > temporary memory stack ever used: 524288 bytes. > > temporary memory heap used: 63304 bytes. > > Old Stack size 524288, New stack size 524288 > > Stack Hob: BaseAddress=0x93D5 Length=0x8 > > Heap Offset = 0x9395 Stack Offset = 0x9395 > > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi" > > ... > > "CoreInitializeMemoryServices: > > BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded - > > 0x5AC" > > > > This one is bricked: > > > > "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000 > > Temp Stack : BaseAddress=0x40 Length=0x8 > > Temp Heap : BaseAddress=0x48 Length=0x8 > > Total temporary memory:1048576 bytes. > > temporary memory stack ever used: 524288 bytes. > > temporary memory heap used: 63304 bytes. > > Old Stack size 524288, New stack size 524288 > > Stack Hob: BaseAddress=0x9C9000 Length=0x8 > > Heap Offset = 0x5C9000 Stack Offset = 0x5C9000 > > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi" > > ... > &g
Re: [edk2] Question about memory map entries
Hi everyone One question that was not answered and that could help us, is about skipping the MemoryTypeInfo variable usage. Is there any way to do this skip at a UEFI App ? Simple erasing the MemoryTypeInfo var seems a little to violent from our perspective. What do you think? Seems the system we're having this problem has some inconsistency when filling the MemoryTypeInfo var before exiting the previous boot, and seems to consider the BootServices memory type also to be stored at the var. Does anyone remember of this kind of issue on some system in the past? Thanks and Regards Rafael Em qua, 8 de ago de 2018 às 08:55, Rafael Machado < rafaelrodrigues.mach...@gmail.com> escreveu: > Hi Jiewen > > Thanks for highlighting this. > Just checked and we just add the Reserved/Acpi/Runtime types. > > Seems the guess that this would be related to the MemoryTypeInfo var is > not the correct way to follow. > > We'll keep working on it, maybe asking more questions to the community in > future. > Thank you all for the help and guidance! > In case someone has any comment or idea, please feel free to share. > > Rafael > > > > Em ter, 7 de ago de 2018 às 19:42, Yao, Jiewen > escreveu: > >> Hi >> >> It is unclear to me that which type you have put to MemoryTypeInfo table. >> >> >> >> By design, we only need put Reserved/Acpi/Runtime, which should be quite >> small. >> >> >> >> Do you put any other type into MemoryTypeInfo table? >> >> >> >> Thank you >> >> Yao Jiewen >> >> >> >> *From:* Rafael Machado [mailto:rafaelrodrigues.mach...@gmail.com] >> *Sent:* Wednesday, August 8, 2018 3:12 AM >> *To:* Laszlo Ersek >> *Cc:* Andrew Fish ; Ni, Ruiyu ; >> edk2-devel@lists.01.org; Yao, Jiewen >> >> >> *Subject:* Re: [edk2] Question about memory map entries >> >> >> >> Hi everyone >> >> >> >> Based on the information shared by the members, the understanding is that >> the current state of the system may impact fuutre boots. >> >> The problem is that in my case, due to specific requirements, before >> booting we need to stress the system's memory, allocating a big amount of >> memory and doing some memory validation algorithms. >> >> So the high number of allocations and frees is by choice and not by >> mistakes. >> >> >> >> Considering this. Is there any way to bypass the MemoryTypeInformation >> var store actions? >> >> >> >> Thanks and Regards >> >> Rafael >> >> >> >> Em qui, 2 de ago de 2018 às 17:39, Laszlo Ersek >> escreveu: >> >> On 08/02/18 21:18, Rafael Machado wrote: >> > Just found something interesting. >> > Based on the logs from the serial port. >> > >> > This system works fine: >> > >> > "PeiInstallPeiMemory MemoryBegin 0x93D5, MemoryLength 0xA2B >> > Temp Stack : BaseAddress=0x40 Length=0x8 >> > Temp Heap : BaseAddress=0x48 Length=0x8 >> > Total temporary memory:1048576 bytes. >> > temporary memory stack ever used: 524288 bytes. >> > temporary memory heap used: 63304 bytes. >> > Old Stack size 524288, New stack size 524288 >> > Stack Hob: BaseAddress=0x93D5 Length=0x8 >> > Heap Offset = 0x9395 Stack Offset = 0x9395 >> > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi" >> > ... >> > "CoreInitializeMemoryServices: >> > BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded - >> > 0x5AC" >> > >> > This one is bricked: >> > >> > "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000 >> > Temp Stack : BaseAddress=0x40 Length=0x8 >> > Temp Heap : BaseAddress=0x48 Length=0x8 >> > Total temporary memory:1048576 bytes. >> > temporary memory stack ever used: 524288 bytes. >> > temporary memory heap used: 63304 bytes. >> > Old Stack size 524288, New stack size 524288 >> > Stack Hob: BaseAddress=0x9C9000 Length=0x8 >> > Heap Offset = 0x5C9000 Stack Offset = 0x5C9000 >> > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi" >> > ... >> > "CoreInitializeMemoryServices: >> > BaseAddress - 0x0 Length - 0x0 MinimalMemorySizeNeeded - 0x98E47000 >> > " >> > ... >> > "ASSERT_EFI_ERROR (Status = Out of Resources) >> > ASSERT [DxeCore] ...\MdeMod
Re: [edk2] Question about memory map entries
Hi Jiewen Thanks for highlighting this. Just checked and we just add the Reserved/Acpi/Runtime types. Seems the guess that this would be related to the MemoryTypeInfo var is not the correct way to follow. We'll keep working on it, maybe asking more questions to the community in future. Thank you all for the help and guidance! In case someone has any comment or idea, please feel free to share. Rafael Em ter, 7 de ago de 2018 às 19:42, Yao, Jiewen escreveu: > Hi > > It is unclear to me that which type you have put to MemoryTypeInfo table. > > > > By design, we only need put Reserved/Acpi/Runtime, which should be quite > small. > > > > Do you put any other type into MemoryTypeInfo table? > > > > Thank you > > Yao Jiewen > > > > *From:* Rafael Machado [mailto:rafaelrodrigues.mach...@gmail.com] > *Sent:* Wednesday, August 8, 2018 3:12 AM > *To:* Laszlo Ersek > *Cc:* Andrew Fish ; Ni, Ruiyu ; > edk2-devel@lists.01.org; Yao, Jiewen > > > *Subject:* Re: [edk2] Question about memory map entries > > > > Hi everyone > > > > Based on the information shared by the members, the understanding is that > the current state of the system may impact fuutre boots. > > The problem is that in my case, due to specific requirements, before > booting we need to stress the system's memory, allocating a big amount of > memory and doing some memory validation algorithms. > > So the high number of allocations and frees is by choice and not by > mistakes. > > > > Considering this. Is there any way to bypass the MemoryTypeInformation > var store actions? > > > > Thanks and Regards > > Rafael > > > > Em qui, 2 de ago de 2018 às 17:39, Laszlo Ersek > escreveu: > > On 08/02/18 21:18, Rafael Machado wrote: > > Just found something interesting. > > Based on the logs from the serial port. > > > > This system works fine: > > > > "PeiInstallPeiMemory MemoryBegin 0x93D5, MemoryLength 0xA2B > > Temp Stack : BaseAddress=0x40 Length=0x8 > > Temp Heap : BaseAddress=0x48 Length=0x8 > > Total temporary memory:1048576 bytes. > > temporary memory stack ever used: 524288 bytes. > > temporary memory heap used: 63304 bytes. > > Old Stack size 524288, New stack size 524288 > > Stack Hob: BaseAddress=0x93D5 Length=0x8 > > Heap Offset = 0x9395 Stack Offset = 0x9395 > > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi" > > ... > > "CoreInitializeMemoryServices: > > BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded - > > 0x5AC" > > > > This one is bricked: > > > > "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000 > > Temp Stack : BaseAddress=0x40 Length=0x8 > > Temp Heap : BaseAddress=0x48 Length=0x8 > > Total temporary memory:1048576 bytes. > > temporary memory stack ever used: 524288 bytes. > > temporary memory heap used: 63304 bytes. > > Old Stack size 524288, New stack size 524288 > > Stack Hob: BaseAddress=0x9C9000 Length=0x8 > > Heap Offset = 0x5C9000 Stack Offset = 0x5C9000 > > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi" > > ... > > "CoreInitializeMemoryServices: > > BaseAddress - 0x0 Length - 0x0 MinimalMemorySizeNeeded - 0x98E47000 > > " > > ... > > "ASSERT_EFI_ERROR (Status = Out of Resources) > > ASSERT [DxeCore] ...\MdeModulePkg\Core\Dxe\DxeMain\DxeMain.c(299): > > !EFI_ERROR (Status) > > AllocatePoolPages: failed to allocate 1 pages > > AllocatePool: failed to allocate 120 bytes" > > The location and the size of the permanent PEI RAM are extremely > different between the two cases. > > - Functional system: > > PeiInstallPeiMemory MemoryBegin 0x93D5, MemoryLength 0xA2B > > Base address is ~2365 MB, size is ~162 MB > > - Unbootable system: > > PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000 > > Base address is ~9 MB, size is ~2518 MB > > The numbers in the second (unbootable) case look very unusual to me. The > permanent PEI RAM is usually tens or (maybe) hundreds of megabytes in > size, and tends to start much higher (usually as high as possible under > 4GB, on x86 anyway). > > > Consult the following sections in the PI spec (v1.6), volume 3: > > - 4.3 Example HOB Producer Phase Memory Map and Usage > - 5.3 PHIT HOB > > The CoreInitializeMemoryServices() function searches the HOB list for a > tested system memory "Resource Descriptor HOB that contains PHI
Re: [edk2] Question about memory map entries
Hi It is unclear to me that which type you have put to MemoryTypeInfo table. By design, we only need put Reserved/Acpi/Runtime, which should be quite small. Do you put any other type into MemoryTypeInfo table? Thank you Yao Jiewen From: Rafael Machado [mailto:rafaelrodrigues.mach...@gmail.com] Sent: Wednesday, August 8, 2018 3:12 AM To: Laszlo Ersek Cc: Andrew Fish ; Ni, Ruiyu ; edk2-devel@lists.01.org; Yao, Jiewen Subject: Re: [edk2] Question about memory map entries Hi everyone Based on the information shared by the members, the understanding is that the current state of the system may impact fuutre boots. The problem is that in my case, due to specific requirements, before booting we need to stress the system's memory, allocating a big amount of memory and doing some memory validation algorithms. So the high number of allocations and frees is by choice and not by mistakes. Considering this. Is there any way to bypass the MemoryTypeInformation var store actions? Thanks and Regards Rafael Em qui, 2 de ago de 2018 às 17:39, Laszlo Ersek mailto:ler...@redhat.com>> escreveu: On 08/02/18 21:18, Rafael Machado wrote: > Just found something interesting. > Based on the logs from the serial port. > > This system works fine: > > "PeiInstallPeiMemory MemoryBegin 0x93D5, MemoryLength 0xA2B > Temp Stack : BaseAddress=0x40 Length=0x8 > Temp Heap : BaseAddress=0x48 Length=0x8 > Total temporary memory:1048576 bytes. > temporary memory stack ever used: 524288 bytes. > temporary memory heap used: 63304 bytes. > Old Stack size 524288, New stack size 524288 > Stack Hob: BaseAddress=0x93D5 Length=0x8 > Heap Offset = 0x9395 Stack Offset = 0x9395 > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi" > ... > "CoreInitializeMemoryServices: > BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded - > 0x5AC" > > This one is bricked: > > "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000 > Temp Stack : BaseAddress=0x40 Length=0x8 > Temp Heap : BaseAddress=0x48 Length=0x8 > Total temporary memory:1048576 bytes. > temporary memory stack ever used: 524288 bytes. > temporary memory heap used: 63304 bytes. > Old Stack size 524288, New stack size 524288 > Stack Hob: BaseAddress=0x9C9000 Length=0x8 > Heap Offset = 0x5C9000 Stack Offset = 0x5C9000 > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi" > ... > "CoreInitializeMemoryServices: > BaseAddress - 0x0 Length - 0x0 MinimalMemorySizeNeeded - 0x98E47000 > " > ... > "ASSERT_EFI_ERROR (Status = Out of Resources) > ASSERT [DxeCore] ...\MdeModulePkg\Core\Dxe\DxeMain\DxeMain.c(299): > !EFI_ERROR (Status) > AllocatePoolPages: failed to allocate 1 pages > AllocatePool: failed to allocate 120 bytes" The location and the size of the permanent PEI RAM are extremely different between the two cases. - Functional system: PeiInstallPeiMemory MemoryBegin 0x93D5, MemoryLength 0xA2B Base address is ~2365 MB, size is ~162 MB - Unbootable system: PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000 Base address is ~9 MB, size is ~2518 MB The numbers in the second (unbootable) case look very unusual to me. The permanent PEI RAM is usually tens or (maybe) hundreds of megabytes in size, and tends to start much higher (usually as high as possible under 4GB, on x86 anyway). Consult the following sections in the PI spec (v1.6), volume 3: - 4.3 Example HOB Producer Phase Memory Map and Usage - 5.3 PHIT HOB The CoreInitializeMemoryServices() function searches the HOB list for a tested system memory "Resource Descriptor HOB that contains PHIT range EfiFreeMemoryBottom..EfiFreeMemoryTop". (Quoted a comment from the code.) Basically, the function locates the system RAM HOB that contains the free permanent PEI RAM. If the search fails, then we trip an ASSERT(). This does not happen in your case, the search succeeds. If the search succeeds, then the DXE core will try to initialize itself in one of three locations in the RAM area defined by that HOB. In descending preference order: above the permanent PEI RAM, within the free permanent PEI RAM, and below the permanent PEI RAM. There is also a fallback (a fourth option) when even the third one from before proves too small -- the function will then search again for a memory descriptor HOB, top-down, avoiding the one HOB that it found earlier to contain the permanent PEI RAM (because, all three options for that have already failed, see above). As the result of this search, your broken system finishes with: BaseAddress - 0x0 Length - 0x0 MinimalMemorySizeNeeded - 0x98E47000 "MinimalMemorySizeNeeded" includes the previous measurements from MemoryTy
Re: [edk2] Question about memory map entries
Hi everyone Based on the information shared by the members, the understanding is that the current state of the system may impact fuutre boots. The problem is that in my case, due to specific requirements, before booting we need to stress the system's memory, allocating a big amount of memory and doing some memory validation algorithms. So the high number of allocations and frees is by choice and not by mistakes. Considering this. Is there any way to bypass the MemoryTypeInformation var store actions? Thanks and Regards Rafael Em qui, 2 de ago de 2018 às 17:39, Laszlo Ersek escreveu: > On 08/02/18 21:18, Rafael Machado wrote: > > Just found something interesting. > > Based on the logs from the serial port. > > > > This system works fine: > > > > "PeiInstallPeiMemory MemoryBegin 0x93D5, MemoryLength 0xA2B > > Temp Stack : BaseAddress=0x40 Length=0x8 > > Temp Heap : BaseAddress=0x48 Length=0x8 > > Total temporary memory:1048576 bytes. > > temporary memory stack ever used: 524288 bytes. > > temporary memory heap used: 63304 bytes. > > Old Stack size 524288, New stack size 524288 > > Stack Hob: BaseAddress=0x93D5 Length=0x8 > > Heap Offset = 0x9395 Stack Offset = 0x9395 > > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi" > > ... > > "CoreInitializeMemoryServices: > > BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded - > > 0x5AC" > > > > This one is bricked: > > > > "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000 > > Temp Stack : BaseAddress=0x40 Length=0x8 > > Temp Heap : BaseAddress=0x48 Length=0x8 > > Total temporary memory:1048576 bytes. > > temporary memory stack ever used: 524288 bytes. > > temporary memory heap used: 63304 bytes. > > Old Stack size 524288, New stack size 524288 > > Stack Hob: BaseAddress=0x9C9000 Length=0x8 > > Heap Offset = 0x5C9000 Stack Offset = 0x5C9000 > > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi" > > ... > > "CoreInitializeMemoryServices: > > BaseAddress - 0x0 Length - 0x0 MinimalMemorySizeNeeded - 0x98E47000 > > " > > ... > > "ASSERT_EFI_ERROR (Status = Out of Resources) > > ASSERT [DxeCore] ...\MdeModulePkg\Core\Dxe\DxeMain\DxeMain.c(299): > > !EFI_ERROR (Status) > > AllocatePoolPages: failed to allocate 1 pages > > AllocatePool: failed to allocate 120 bytes" > > The location and the size of the permanent PEI RAM are extremely > different between the two cases. > > - Functional system: > > PeiInstallPeiMemory MemoryBegin 0x93D5, MemoryLength 0xA2B > > Base address is ~2365 MB, size is ~162 MB > > - Unbootable system: > > PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000 > > Base address is ~9 MB, size is ~2518 MB > > The numbers in the second (unbootable) case look very unusual to me. The > permanent PEI RAM is usually tens or (maybe) hundreds of megabytes in > size, and tends to start much higher (usually as high as possible under > 4GB, on x86 anyway). > > > Consult the following sections in the PI spec (v1.6), volume 3: > > - 4.3 Example HOB Producer Phase Memory Map and Usage > - 5.3 PHIT HOB > > The CoreInitializeMemoryServices() function searches the HOB list for a > tested system memory "Resource Descriptor HOB that contains PHIT range > EfiFreeMemoryBottom..EfiFreeMemoryTop". (Quoted a comment from the code.) > > Basically, the function locates the system RAM HOB that contains the > free permanent PEI RAM. > > If the search fails, then we trip an ASSERT(). This does not happen in > your case, the search succeeds. > > If the search succeeds, then the DXE core will try to initialize itself > in one of three locations in the RAM area defined by that HOB. In > descending preference order: above the permanent PEI RAM, within the > free permanent PEI RAM, and below the permanent PEI RAM. > > There is also a fallback (a fourth option) when even the third one from > before proves too small -- the function will then search again for a > memory descriptor HOB, top-down, avoiding the one HOB that it found > earlier to contain the permanent PEI RAM (because, all three options for > that have already failed, see above). > > As the result of this search, your broken system finishes with: > > BaseAddress - 0x0 Length - 0x0 MinimalMemorySizeNeeded - 0x98E47000 > > "MinimalMemorySizeNeeded" includes the previous measurements from > MemoryTypeInformation, and the concrete value is very strange -- it > seems to imply that you need ~2446 MB for initializing the DXE core. > It's not surprising that the function cannot fit that anywhere, in > either of the four options described above. > > If your system has more (high) RAM to spare, try to install a resource > descriptor HOB for it. Then the fourth option might succeed. > > Honestly though, those permanent PEI RAM values (base address at ~9 MB, > size ~2518 MB) look super fishy to me in the first place. Something must > be
Re: [edk2] Question about memory map entries
On 08/02/18 21:18, Rafael Machado wrote:
> Just found something interesting.
> Based on the logs from the serial port.
>
> This system works fine:
>
> "PeiInstallPeiMemory MemoryBegin 0x93D5, MemoryLength 0xA2B
> Temp Stack : BaseAddress=0x40 Length=0x8
> Temp Heap : BaseAddress=0x48 Length=0x8
> Total temporary memory:1048576 bytes.
> temporary memory stack ever used: 524288 bytes.
> temporary memory heap used: 63304 bytes.
> Old Stack size 524288, New stack size 524288
> Stack Hob: BaseAddress=0x93D5 Length=0x8
> Heap Offset = 0x9395 Stack Offset = 0x9395
> Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi"
> ...
> "CoreInitializeMemoryServices:
> BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded -
> 0x5AC"
>
> This one is bricked:
>
> "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000
> Temp Stack : BaseAddress=0x40 Length=0x8
> Temp Heap : BaseAddress=0x48 Length=0x8
> Total temporary memory:1048576 bytes.
> temporary memory stack ever used: 524288 bytes.
> temporary memory heap used: 63304 bytes.
> Old Stack size 524288, New stack size 524288
> Stack Hob: BaseAddress=0x9C9000 Length=0x8
> Heap Offset = 0x5C9000 Stack Offset = 0x5C9000
> Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi"
> ...
> "CoreInitializeMemoryServices:
> BaseAddress - 0x0 Length - 0x0 MinimalMemorySizeNeeded - 0x98E47000
> "
> ...
> "ASSERT_EFI_ERROR (Status = Out of Resources)
> ASSERT [DxeCore] ...\MdeModulePkg\Core\Dxe\DxeMain\DxeMain.c(299):
> !EFI_ERROR (Status)
> AllocatePoolPages: failed to allocate 1 pages
> AllocatePool: failed to allocate 120 bytes"
The location and the size of the permanent PEI RAM are extremely
different between the two cases.
- Functional system:
PeiInstallPeiMemory MemoryBegin 0x93D5, MemoryLength 0xA2B
Base address is ~2365 MB, size is ~162 MB
- Unbootable system:
PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000
Base address is ~9 MB, size is ~2518 MB
The numbers in the second (unbootable) case look very unusual to me. The
permanent PEI RAM is usually tens or (maybe) hundreds of megabytes in
size, and tends to start much higher (usually as high as possible under
4GB, on x86 anyway).
Consult the following sections in the PI spec (v1.6), volume 3:
- 4.3 Example HOB Producer Phase Memory Map and Usage
- 5.3 PHIT HOB
The CoreInitializeMemoryServices() function searches the HOB list for a
tested system memory "Resource Descriptor HOB that contains PHIT range
EfiFreeMemoryBottom..EfiFreeMemoryTop". (Quoted a comment from the code.)
Basically, the function locates the system RAM HOB that contains the
free permanent PEI RAM.
If the search fails, then we trip an ASSERT(). This does not happen in
your case, the search succeeds.
If the search succeeds, then the DXE core will try to initialize itself
in one of three locations in the RAM area defined by that HOB. In
descending preference order: above the permanent PEI RAM, within the
free permanent PEI RAM, and below the permanent PEI RAM.
There is also a fallback (a fourth option) when even the third one from
before proves too small -- the function will then search again for a
memory descriptor HOB, top-down, avoiding the one HOB that it found
earlier to contain the permanent PEI RAM (because, all three options for
that have already failed, see above).
As the result of this search, your broken system finishes with:
BaseAddress - 0x0 Length - 0x0 MinimalMemorySizeNeeded - 0x98E47000
"MinimalMemorySizeNeeded" includes the previous measurements from
MemoryTypeInformation, and the concrete value is very strange -- it
seems to imply that you need ~2446 MB for initializing the DXE core.
It's not surprising that the function cannot fit that anywhere, in
either of the four options described above.
If your system has more (high) RAM to spare, try to install a resource
descriptor HOB for it. Then the fourth option might succeed.
Honestly though, those permanent PEI RAM values (base address at ~9 MB,
size ~2518 MB) look super fishy to me in the first place. Something must
be wrong in the PEI phase with the calculation of those parameters.
Possibly, the memory resource descriptor HOBs could be wrong too.
... Considering commit 3a05b13106d1 ("MdeModulePkg DxeCore: Take the
range in resource HOB for PHIT as higher priority", 2015-09-18), it writes,
"Also let the minimal memory size needed include the total memory bin
size needed to make sure memory bin could be allocated successfully."
This is the reason "MinimalMemorySizeNeeded" includes
MemoryTypeInformation. Normally, MemoryTypeInformation tracks long-term
maximums that are necessary for booting an OS without memory map
fragmentation (including S4 resume). However, if you have a UEFI
application that allocates huge amounts of memory, and then *doesn't*
boot an OS, then it could invalidate
Re: [edk2] Question about memory map entries
Just found something interesting. Based on the logs from the serial port. This system works fine: "PeiInstallPeiMemory MemoryBegin 0x93D5, MemoryLength 0xA2B Temp Stack : BaseAddress=0x40 Length=0x8 Temp Heap : BaseAddress=0x48 Length=0x8 Total temporary memory:1048576 bytes. temporary memory stack ever used: 524288 bytes. temporary memory heap used: 63304 bytes. Old Stack size 524288, New stack size 524288 Stack Hob: BaseAddress=0x93D5 Length=0x8 Heap Offset = 0x9395 Stack Offset = 0x9395 Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi" ... "CoreInitializeMemoryServices: BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded - 0x5AC" This one is bricked: "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000 Temp Stack : BaseAddress=0x40 Length=0x8 Temp Heap : BaseAddress=0x48 Length=0x8 Total temporary memory:1048576 bytes. temporary memory stack ever used: 524288 bytes. temporary memory heap used: 63304 bytes. Old Stack size 524288, New stack size 524288 Stack Hob: BaseAddress=0x9C9000 Length=0x8 Heap Offset = 0x5C9000 Stack Offset = 0x5C9000 Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi" ... "CoreInitializeMemoryServices: BaseAddress - 0x0 Length - 0x0 MinimalMemorySizeNeeded - 0x98E47000 " ... "ASSERT_EFI_ERROR (Status = Out of Resources) ASSERT [DxeCore] ...\MdeModulePkg\Core\Dxe\DxeMain\DxeMain.c(299): !EFI_ERROR (Status) AllocatePoolPages: failed to allocate 1 pages AllocatePool: failed to allocate 120 bytes" It's really strange that the "Stack Hob base address" is so different, and the "MemoryBegin" also. This is making the memory to be detected incorrectly as far as I could understand. So CoreInitializeMemoryServices does not have enougth memory to work on. Any idea about what could cause this difference? Unfortunately I don't have the system in hands. And also cannot share the entire log due to legal. But these are the differences between the bricked system and the normal one. Any idea? Thanks and Regards Rafael R. Machado Em qui, 2 de ago de 2018 às 16:02, Rafael Machado < rafaelrodrigues.mach...@gmail.com> escreveu: > Hi Laszlo > > Got your point. Thanks for the comment. > > I'll keep working on it. > In case someone has some other information or idea feel free to share. > > Thanks > Rafael > > Em qui, 2 de ago de 2018 às 14:48, Laszlo Ersek > escreveu: > >> On 08/02/18 18:42, Rafael Machado wrote: >> > Thanks Andrew and Laszlo for the clarification and guidance. >> > >> > About Laszlo questions >> > >> >> Is the reboot automatic (from the platform firmware), or application / >> >> user initiated? >> > Yes. We just do some clean up, finish the events and "return >> EFI_SUCCESS;" >> >> That's really strange. I don't think that's valid or expected behavior. >> If a boot option exits with success, then, as I understand it, the boot >> manager is expected to return to the setup UI at once. (I don't have a >> reference ready for this, but I remember someone mentioning it.) Boot >> option processing continues only if the current boot option exits with >> failure. >> >> I think the reboot you see is actually a crash. (Not saying that the >> issue is in your application, just that the reboot should not be >> triggered by either the application or the platform firmware.) >> >> Thanks, >> Laszlo >> > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Question about memory map entries
Hi Laszlo Got your point. Thanks for the comment. I'll keep working on it. In case someone has some other information or idea feel free to share. Thanks Rafael Em qui, 2 de ago de 2018 às 14:48, Laszlo Ersek escreveu: > On 08/02/18 18:42, Rafael Machado wrote: > > Thanks Andrew and Laszlo for the clarification and guidance. > > > > About Laszlo questions > > > >> Is the reboot automatic (from the platform firmware), or application / > >> user initiated? > > Yes. We just do some clean up, finish the events and "return > EFI_SUCCESS;" > > That's really strange. I don't think that's valid or expected behavior. > If a boot option exits with success, then, as I understand it, the boot > manager is expected to return to the setup UI at once. (I don't have a > reference ready for this, but I remember someone mentioning it.) Boot > option processing continues only if the current boot option exits with > failure. > > I think the reboot you see is actually a crash. (Not saying that the > issue is in your application, just that the reboot should not be > triggered by either the application or the platform firmware.) > > Thanks, > Laszlo > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Question about memory map entries
On 08/02/18 18:42, Rafael Machado wrote: > Thanks Andrew and Laszlo for the clarification and guidance. > > About Laszlo questions > >> Is the reboot automatic (from the platform firmware), or application / >> user initiated? > Yes. We just do some clean up, finish the events and "return EFI_SUCCESS;" That's really strange. I don't think that's valid or expected behavior. If a boot option exits with success, then, as I understand it, the boot manager is expected to return to the setup UI at once. (I don't have a reference ready for this, but I remember someone mentioning it.) Boot option processing continues only if the current boot option exits with failure. I think the reboot you see is actually a crash. (Not saying that the issue is in your application, just that the reboot should not be triggered by either the application or the platform firmware.) Thanks, Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Question about memory map entries
Thanks Andrew and Laszlo for the clarification and guidance. About Laszlo questions >Is the reboot automatic (from the platform firmware), or application / >user initiated? Yes. We just do some clean up, finish the events and "return EFI_SUCCESS;" >Do you exit the application before the system is powered off? No. At this test we just let the application finishes it's work and power off the system. No "return EFI_SUCCESS;" Thanks and Regards Rafael Em qui, 2 de ago de 2018 às 11:44, Laszlo Ersek escreveu: > On 08/02/18 14:39, Rafael Machado wrote: > > Hi everyone > > > > After some other tasks I am back to this case :) > > > > After some debug, we detected the moment where things start to go wrong, > > but I am not sure what may cause this. > > > > What we noticed is that the following assert is reached: > > > https://github.com/tianocore/edk2/blob/87acb6e298e718250dd8b741b6888a3a54c7cb5a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L2199 > > > > Just to remember, this assert is reached with the following steps: > > 1 - Boot the application (renamed to BOOTX64.efi) from a usb stick > > 2 - Execute the application tasks > > 3 - exit the application (free everything, all events closed and no > memory > > leaks detected as suggested to check by Andrew on the previous e-mail, > then > > return efi_success) > > 4 - the system will reboot and reach the assert > > Is the reboot automatic (from the platform firmware), or application / > user initiated? > > > But it does not happen with the following scenario: > > 1 - Boot the application (renamed to BOOTX64.efi) from a usb stick > > 2 - Execute the application tasks > > 3 - Power off the system > > Do you exit the application before the system is powered off? > > > > > As far as I could understand (please correct my understanding that may be > > wrong since is the first time I look at this part of the code), at this > > point the HOBs passed from sec phase are processed by PEI so the memory > > could be "detected/mapped/initialized" correctly. But for some reason the > > required HOB is no present at the list. > > > > Could someone with more experience at this part of the code please > confirm > > my understanding, and if possible give some guesses about what could > cause > > this scenario? > > PEI may act differently (produce different HOBs) dependent on boot mode. > The PI spec defines several boot modes; it's platform-dependent what > hardware states / transitions are mapped to what PI boot modes by the > firmware. > > > My guess is that some memory cleanup that should be done by the bios > after > > the application exits is not being done correctly. So I believe the > problem > > is not at the application, but at the BIOS. A friend here mentioned about > > the MemoryTypeInformation efi var, that may be corrupted, and considering > > it's used to guide the boot process it may impact the boot, but I am not > > sure if this is the case and also I didn't find to much information about > > this var and it's usage, so any help about this would be well received > also. > > MemoryTypeInformation measures peak usage (of various UEFI memory types) > during boot, so that at next boot, the internal allocation "bins" can be > primed with large enough sizes. The goal is to reduce fragmentation due > to "unforeseen" allocations. > > If you exit the application gracefully in both scenarios (and the only > difference is whether you reboot the system, or power it down, > afterwards, e.g. by passing different options to the RESET command of > the UEFI shell), then I don't see how MemoryTypeInformation could be > relevant. > > Thanks > Laszlo > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Question about memory map entries
On 08/02/18 14:39, Rafael Machado wrote: > Hi everyone > > After some other tasks I am back to this case :) > > After some debug, we detected the moment where things start to go wrong, > but I am not sure what may cause this. > > What we noticed is that the following assert is reached: > https://github.com/tianocore/edk2/blob/87acb6e298e718250dd8b741b6888a3a54c7cb5a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L2199 > > Just to remember, this assert is reached with the following steps: > 1 - Boot the application (renamed to BOOTX64.efi) from a usb stick > 2 - Execute the application tasks > 3 - exit the application (free everything, all events closed and no memory > leaks detected as suggested to check by Andrew on the previous e-mail, then > return efi_success) > 4 - the system will reboot and reach the assert Is the reboot automatic (from the platform firmware), or application / user initiated? > But it does not happen with the following scenario: > 1 - Boot the application (renamed to BOOTX64.efi) from a usb stick > 2 - Execute the application tasks > 3 - Power off the system Do you exit the application before the system is powered off? > > As far as I could understand (please correct my understanding that may be > wrong since is the first time I look at this part of the code), at this > point the HOBs passed from sec phase are processed by PEI so the memory > could be "detected/mapped/initialized" correctly. But for some reason the > required HOB is no present at the list. > > Could someone with more experience at this part of the code please confirm > my understanding, and if possible give some guesses about what could cause > this scenario? PEI may act differently (produce different HOBs) dependent on boot mode. The PI spec defines several boot modes; it's platform-dependent what hardware states / transitions are mapped to what PI boot modes by the firmware. > My guess is that some memory cleanup that should be done by the bios after > the application exits is not being done correctly. So I believe the problem > is not at the application, but at the BIOS. A friend here mentioned about > the MemoryTypeInformation efi var, that may be corrupted, and considering > it's used to guide the boot process it may impact the boot, but I am not > sure if this is the case and also I didn't find to much information about > this var and it's usage, so any help about this would be well received also. MemoryTypeInformation measures peak usage (of various UEFI memory types) during boot, so that at next boot, the internal allocation "bins" can be primed with large enough sizes. The goal is to reduce fragmentation due to "unforeseen" allocations. If you exit the application gracefully in both scenarios (and the only difference is whether you reboot the system, or power it down, afterwards, e.g. by passing different options to the RESET command of the UEFI shell), then I don't see how MemoryTypeInformation could be relevant. Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Question about memory map entries
ryBottom; /// /// The end of the HOB list. /// EFI_PHYSICAL_ADDRESSEfiEndOfHobList; } EFI_HOB_HANDOFF_INFO_TABLE; Thanks, Andrew Fish > Thanks and Regards > Rafael R. Machado > > Em sáb, 30 de jun de 2018 às 16:23, Andrew Fish <mailto:af...@apple.com>> escreveu: > > > > On Jun 30, 2018, at 5:02 AM, Rafael Machado > > > <mailto:rafaelrodrigues.mach...@gmail.com>> wrote: > > > > Hi everyone. Thanks for the answers! > > In this case, I just executed 3 shell command: > > > > memmap >> before.txt > > app.efi > > memmap >> after.txt > > > > Does anyone could clarify what could cause a new entry to be created at the > > memmap output command? > > There is fragmentation caused the Apps high usage of memory and this can > cause a lot more entries. I guess the DXE Core might also need to allocate > some extra pages to track the fragmentation of the memory pool caused by the > App. > > > My understanding was that the entries at the memmap command reflect the GCD > > (global coherence domain), that is something that should not change too > > much after the system is already at BDS phase. > > It is not really showing you GCD, it is showing the UEFI memory map. GCD > implies the memory is being used as DRAM by the CPU , the UEFI memory map > tracks the type of allocation and what areas of memory are free. That usage > patter is changed by your App running. > > > As mentioned, the > > application does a lot of AllocatePool() FreePool() calls. And these calls > > are, as far as I could understand, creating a lot of entries of type > > "BS_Data" > > and "Available". > > Shouldn't the bios allocation routines try to reuse the pools already used > > and freed to avoid massing and fragmenting the memory? > > > > Besides that, we just found a system that hangs on the subsequent boot > > after executing the application. The strange is that the system just hangs > > if you do the following steps: > > > > 1 - execute the application: app.efi > > 2 - exit the shell with the command: exit > > 3 - boot hangs not presenting the shell prompt > > > > > > In case you do the following steps the hang doesn't happen: > > > > 1 - execute the application: app.efi > > 2 - shut down the system by pressing the power button > > 3 - boots normally entering at the shell prompt > > > > Any idea about what could cause this strange behavior, and if this may have > > some relation with the increase of the memmap output entries? > > A common bug is for an Application to not clean up something and have the > resource get freed. For example the App starts a timer event, forgets to stop > it and when the App exits the memory gets freed back and if some one else > allocates that memory they overwrite the code that executes in the timer > event and kaboom. Same goes for publishing a protocol, etc. > > Given the issue is only with your App I'd focus on the App and not the delta > in the memory map. > > On thing that may be helpful is to turn on this property it will cause the > freed pool to get filled with 0xAF. 0xAFAFAFAFAFAFAFAF will GP fault if it is > used as a memory address so this helps catch using freed resources closer to > the source. > PcdDebugPropertyMask set DEBUG_PROPERTY_CLEAR_MEMORY_ENABLED > > Thanks, > > Andrew Fish > > > (maybe > > something related with the MemoryTypeInformation information that seems to > > be saved to make the subsequent boots easier from the bios perspective. > > This guess is based on [1] page 19, that explains the creation of the > > BIN.DXE, but things are a little dark to me yet. Not sure if my > > understanding is correct.) > > > > [1] > > https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Memory_Map_in%20UEFI_BIOS.pdf > > > > <https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Memory_Map_in%20UEFI_BIOS.pdf> > > > > Thanks and Regards > > Rafael R. Machado > > > > Em sex, 29 de jun de 2018 às 22:31, Ni, Ruiyu > <mailto:ruiyu...@intel.com>> escreveu: > > > >> Yes. > >> Check the PCD PcdShellMaxHistoryCommandCount (0x20) which sets > >> the maximum command history. > >> The memmap output should be stable after you run more than > >> 0x20 commands. > >> > >>> -Original Message- > >>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org > >>> <mailto:edk2-devel-boun...@lists.01.
Re: [edk2] Question about memory map entries
issue is only with your App I'd focus on the App and not the > delta in the memory map. > > On thing that may be helpful is to turn on this property it will cause the > freed pool to get filled with 0xAF. 0xAFAFAFAFAFAFAFAF will GP fault if it > is used as a memory address so this helps catch using freed resources > closer to the source. > PcdDebugPropertyMask set DEBUG_PROPERTY_CLEAR_MEMORY_ENABLED > > Thanks, > > Andrew Fish > > > (maybe > > something related with the MemoryTypeInformation information that seems > to > > be saved to make the subsequent boots easier from the bios perspective. > > This guess is based on [1] page 19, that explains the creation of the > > BIN.DXE, but things are a little dark to me yet. Not sure if my > > understanding is correct.) > > > > [1] > > > https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Memory_Map_in%20UEFI_BIOS.pdf > > > > Thanks and Regards > > Rafael R. Machado > > > > Em sex, 29 de jun de 2018 às 22:31, Ni, Ruiyu > escreveu: > > > >> Yes. > >> Check the PCD PcdShellMaxHistoryCommandCount (0x20) which sets > >> the maximum command history. > >> The memmap output should be stable after you run more than > >> 0x20 commands. > >> > >>> -Original Message- > >>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > >> Yao, > >>> Jiewen > >>> Sent: Saturday, June 30, 2018 3:28 AM > >>> To: Rafael Machado ; edk2- > >>> de...@lists.01.org > >>> Subject: Re: [edk2] Question about memory map entries > >>> > >>> Shell itself may allocate internal buffer to save something, such as > >> history. > >>> > >>> Thank you > >>> Yao Jiewen > >>> > >>>> -Original Message- > >>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > Of > >>>> Rafael Machado > >>>> Sent: Friday, June 29, 2018 12:06 PM > >>>> To: edk2-devel@lists.01.org > >>>> Subject: [edk2] Question about memory map entries > >>>> > >>>> Hi everyone > >>>> > >>>> I have a question related to the memory map entries. > >>>> Doing some tests, we noticed that if I have an application that has a > >>>> lot of allocatepool() and freepool() calls, when this app is closed > >>>> the amount of entries returned by the memmap shell commands increases > a > >>> lot. > >>>> > >>>> Just for reference. This is the mapping before executing the > >> application: > >>>> > >>>> Type StartEnd # Pages > >>>> Attributes > >>>> BS_Code-0FFF 0001 > >>>> 000F > >>>> BS_Data1000-1FFF 0001 > >>>> 000F > >>>> BS_Code2000-BFFF 000A > >>>> 000F > >>>> Available C000-00057FFF 004C > >>>> 000F > >>>> Reserved 00058000-00058FFF 0001 > >>>> 000F > >>>> Available 00059000-00069FFF 0011 > >>>> 000F > >>>> BS_Data0006A000-0006AFFF 0001 > >>>> 000F > >>>> BS_Code0006B000-0008BFFF 0021 > >>>> 000F > >>>> Reserved 0008C000-0009 0014 > >>>> 000F > >>>> BS_Code0010-0010 0010 > >>>> 000F > >>>> Available 0011-4D684FFF 0004D575 > >>>> 000F > >>>> BS_Data4D685000-4D6A4FFF 0020 > >>>> 000F > >>>> Available 4D6A5000-4E34EFFF 0CAA > >>>> 000F LoaderCode 4E34F000-4E42CFFF > >>>> 00DE 000F > >>>> BS_Data4E42D000-50510FFF 20E4 > >>>> 000F > >>>> ACPI_NVS 50511000-50511FFF 0001 > >&g
Re: [edk2] Question about memory map entries
> On Jun 30, 2018, at 5:02 AM, Rafael Machado > wrote: > > Hi everyone. Thanks for the answers! > In this case, I just executed 3 shell command: > > memmap >> before.txt > app.efi > memmap >> after.txt > > Does anyone could clarify what could cause a new entry to be created at the > memmap output command? There is fragmentation caused the Apps high usage of memory and this can cause a lot more entries. I guess the DXE Core might also need to allocate some extra pages to track the fragmentation of the memory pool caused by the App. > My understanding was that the entries at the memmap command reflect the GCD > (global coherence domain), that is something that should not change too > much after the system is already at BDS phase. It is not really showing you GCD, it is showing the UEFI memory map. GCD implies the memory is being used as DRAM by the CPU , the UEFI memory map tracks the type of allocation and what areas of memory are free. That usage patter is changed by your App running. > As mentioned, the > application does a lot of AllocatePool() FreePool() calls. And these calls > are, as far as I could understand, creating a lot of entries of type "BS_Data" > and "Available". > Shouldn't the bios allocation routines try to reuse the pools already used > and freed to avoid massing and fragmenting the memory? > > Besides that, we just found a system that hangs on the subsequent boot > after executing the application. The strange is that the system just hangs > if you do the following steps: > > 1 - execute the application: app.efi > 2 - exit the shell with the command: exit > 3 - boot hangs not presenting the shell prompt > > > In case you do the following steps the hang doesn't happen: > > 1 - execute the application: app.efi > 2 - shut down the system by pressing the power button > 3 - boots normally entering at the shell prompt > > Any idea about what could cause this strange behavior, and if this may have > some relation with the increase of the memmap output entries? A common bug is for an Application to not clean up something and have the resource get freed. For example the App starts a timer event, forgets to stop it and when the App exits the memory gets freed back and if some one else allocates that memory they overwrite the code that executes in the timer event and kaboom. Same goes for publishing a protocol, etc. Given the issue is only with your App I'd focus on the App and not the delta in the memory map. On thing that may be helpful is to turn on this property it will cause the freed pool to get filled with 0xAF. 0xAFAFAFAFAFAFAFAF will GP fault if it is used as a memory address so this helps catch using freed resources closer to the source. PcdDebugPropertyMask set DEBUG_PROPERTY_CLEAR_MEMORY_ENABLED Thanks, Andrew Fish > (maybe > something related with the MemoryTypeInformation information that seems to > be saved to make the subsequent boots easier from the bios perspective. > This guess is based on [1] page 19, that explains the creation of the > BIN.DXE, but things are a little dark to me yet. Not sure if my > understanding is correct.) > > [1] > https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Memory_Map_in%20UEFI_BIOS.pdf > > Thanks and Regards > Rafael R. Machado > > Em sex, 29 de jun de 2018 às 22:31, Ni, Ruiyu escreveu: > >> Yes. >> Check the PCD PcdShellMaxHistoryCommandCount (0x20) which sets >> the maximum command history. >> The memmap output should be stable after you run more than >> 0x20 commands. >> >>> -----Original Message----- >>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >> Yao, >>> Jiewen >>> Sent: Saturday, June 30, 2018 3:28 AM >>> To: Rafael Machado ; edk2- >>> de...@lists.01.org >>> Subject: Re: [edk2] Question about memory map entries >>> >>> Shell itself may allocate internal buffer to save something, such as >> history. >>> >>> Thank you >>> Yao Jiewen >>> >>>> -Original Message- >>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >>>> Rafael Machado >>>> Sent: Friday, June 29, 2018 12:06 PM >>>> To: edk2-devel@lists.01.org >>>> Subject: [edk2] Question about memory map entries >>>> >>>> Hi everyone >>>> >>>> I have a question related to the memory map entries. >>>> Doing some tests, we noticed that if I have an application that has a >>>> lot of allocatepool() and freepool() calls, when this app is closed >>>>
Re: [edk2] Question about memory map entries
Hi everyone. Thanks for the answers! In this case, I just executed 3 shell command: memmap >> before.txt app.efi memmap >> after.txt Does anyone could clarify what could cause a new entry to be created at the memmap output command? My understanding was that the entries at the memmap command reflect the GCD (global coherence domain), that is something that should not change too much after the system is already at BDS phase. As mentioned, the application does a lot of AllocatePool() FreePool() calls. And these calls are, as far as I could understand, creating a lot of entries of type "BS_Data" and "Available". Shouldn't the bios allocation routines try to reuse the pools already used and freed to avoid massing and fragmenting the memory? Besides that, we just found a system that hangs on the subsequent boot after executing the application. The strange is that the system just hangs if you do the following steps: 1 - execute the application: app.efi 2 - exit the shell with the command: exit 3 - boot hangs not presenting the shell prompt In case you do the following steps the hang doesn't happen: 1 - execute the application: app.efi 2 - shut down the system by pressing the power button 3 - boots normally entering at the shell prompt Any idea about what could cause this strange behavior, and if this may have some relation with the increase of the memmap output entries? (maybe something related with the MemoryTypeInformation information that seems to be saved to make the subsequent boots easier from the bios perspective. This guess is based on [1] page 19, that explains the creation of the BIN.DXE, but things are a little dark to me yet. Not sure if my understanding is correct.) [1] https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Memory_Map_in%20UEFI_BIOS.pdf Thanks and Regards Rafael R. Machado Em sex, 29 de jun de 2018 às 22:31, Ni, Ruiyu escreveu: > Yes. > Check the PCD PcdShellMaxHistoryCommandCount (0x20) which sets > the maximum command history. > The memmap output should be stable after you run more than > 0x20 commands. > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Yao, > > Jiewen > > Sent: Saturday, June 30, 2018 3:28 AM > > To: Rafael Machado ; edk2- > > de...@lists.01.org > > Subject: Re: [edk2] Question about memory map entries > > > > Shell itself may allocate internal buffer to save something, such as > history. > > > > Thank you > > Yao Jiewen > > > > > -Original Message- > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > > Rafael Machado > > > Sent: Friday, June 29, 2018 12:06 PM > > > To: edk2-devel@lists.01.org > > > Subject: [edk2] Question about memory map entries > > > > > > Hi everyone > > > > > > I have a question related to the memory map entries. > > > Doing some tests, we noticed that if I have an application that has a > > > lot of allocatepool() and freepool() calls, when this app is closed > > > the amount of entries returned by the memmap shell commands increases a > > lot. > > > > > > Just for reference. This is the mapping before executing the > application: > > > > > > Type StartEnd # Pages > > > Attributes > > > BS_Code-0FFF 0001 > > > 000F > > > BS_Data1000-1FFF 0001 > > > 000F > > > BS_Code2000-BFFF 000A > > > 000F > > > Available C000-00057FFF 004C > > > 000F > > > Reserved 00058000-00058FFF 0001 > > > 000F > > > Available 00059000-00069FFF 0011 > > > 000F > > > BS_Data0006A000-0006AFFF 0001 > > > 000F > > > BS_Code0006B000-0008BFFF 0021 > > > 000F > > > Reserved 0008C000-0009 0014 > > > 000F > > > BS_Code0010-0010 0010 > > > 000F > > > Available 0011-4D684FFF 0004D575 > > > 000F > > > BS_Data4D685000-4D6A4FFF 0020 > > > 000F > > > Available 4D6A5000-4E34EFFF 0CAA > > > 000F
Re: [edk2] Question about memory map entries
Yes. Check the PCD PcdShellMaxHistoryCommandCount (0x20) which sets the maximum command history. The memmap output should be stable after you run more than 0x20 commands. > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao, > Jiewen > Sent: Saturday, June 30, 2018 3:28 AM > To: Rafael Machado ; edk2- > de...@lists.01.org > Subject: Re: [edk2] Question about memory map entries > > Shell itself may allocate internal buffer to save something, such as history. > > Thank you > Yao Jiewen > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > Rafael Machado > > Sent: Friday, June 29, 2018 12:06 PM > > To: edk2-devel@lists.01.org > > Subject: [edk2] Question about memory map entries > > > > Hi everyone > > > > I have a question related to the memory map entries. > > Doing some tests, we noticed that if I have an application that has a > > lot of allocatepool() and freepool() calls, when this app is closed > > the amount of entries returned by the memmap shell commands increases a > lot. > > > > Just for reference. This is the mapping before executing the application: > > > > Type StartEnd # Pages > > Attributes > > BS_Code-0FFF 0001 > > 000F > > BS_Data1000-1FFF 0001 > > 000F > > BS_Code2000-BFFF 000A > > 000F > > Available C000-00057FFF 004C > > 000F > > Reserved 00058000-00058FFF 0001 > > 000F > > Available 00059000-00069FFF 0011 > > 000F > > BS_Data0006A000-0006AFFF 0001 > > 000F > > BS_Code0006B000-0008BFFF 0021 > > 000F > > Reserved 0008C000-0009 0014 > > 000F > > BS_Code0010-0010 0010 > > 000F > > Available 0011-4D684FFF 0004D575 > > 000F > > BS_Data4D685000-4D6A4FFF 0020 > > 000F > > Available 4D6A5000-4E34EFFF 0CAA > > 000F LoaderCode 4E34F000-4E42CFFF > > 00DE 000F > > BS_Data4E42D000-50510FFF 20E4 > > 000F > > ACPI_NVS 50511000-50511FFF 0001 > > 000F > > RT_Data50512000-50512FFF 0001 > > 800F > > BS_Data50513000-50673FFF 0161 > > 000F > > BS_Code50674000-50674FFF 0001 > > 000F > > Available 50675000-52B6EFFF 24FA > > 000F > > BS_Data52B6F000-53572FFF 0A04 > > 000F > > Available 53573000-53834FFF 02C2 > > 000F > > BS_Data53835000-53A0DFFF 01D9 > > 000F > > Available 53A0E000-53A64FFF 0057 > > 000F > > BS_Data53A65000-54778FFF 0D14 > > 000F > > Available 54779000-54785FFF 000D > > 000F > > BS_Data54786000-547CAFFF 0045 > > 000F > > Available 547CB000-547D3FFF 0009 > > 000F > > BS_Data547D4000-5481DFFF 004A > > 000F > > Available 5481E000-5481 0002 > > 000F > > BS_Data5482-56683FFF 1E64 > > 000F > > Available 56684000-590C2FFF 2A3F > > 000F > > BS_Code590C3000-59E83FFF 0DC1 > > 000F > > RT_Code59E84000-59F4BFFF 00C8 > > 800F > > RT_Data59F4C000-5B164FFF 1219 > > 800F > > Reserved 5B165000-5B566FFF 0402 > > 000F > > A
Re: [edk2] Question about memory map entries
Shell itself may allocate internal buffer to save something, such as history. Thank you Yao Jiewen > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Rafael > Machado > Sent: Friday, June 29, 2018 12:06 PM > To: edk2-devel@lists.01.org > Subject: [edk2] Question about memory map entries > > Hi everyone > > I have a question related to the memory map entries. > Doing some tests, we noticed that if I have an application that has a lot > of allocatepool() and freepool() calls, when this app is closed the amount > of entries returned by the memmap shell commands increases a lot. > > Just for reference. This is the mapping before executing the application: > > Type StartEnd # Pages > Attributes > BS_Code-0FFF 0001 > 000F > BS_Data1000-1FFF 0001 > 000F > BS_Code2000-BFFF 000A > 000F > Available C000-00057FFF 004C > 000F > Reserved 00058000-00058FFF 0001 > 000F > Available 00059000-00069FFF 0011 > 000F > BS_Data0006A000-0006AFFF 0001 > 000F > BS_Code0006B000-0008BFFF 0021 > 000F > Reserved 0008C000-0009 0014 > 000F > BS_Code0010-0010 0010 > 000F > Available 0011-4D684FFF 0004D575 > 000F > BS_Data4D685000-4D6A4FFF 0020 > 000F > Available 4D6A5000-4E34EFFF 0CAA > 000F > LoaderCode 4E34F000-4E42CFFF 00DE > 000F > BS_Data4E42D000-50510FFF 20E4 > 000F > ACPI_NVS 50511000-50511FFF 0001 > 000F > RT_Data50512000-50512FFF 0001 > 800F > BS_Data50513000-50673FFF 0161 > 000F > BS_Code50674000-50674FFF 0001 > 000F > Available 50675000-52B6EFFF 24FA > 000F > BS_Data52B6F000-53572FFF 0A04 > 000F > Available 53573000-53834FFF 02C2 > 000F > BS_Data53835000-53A0DFFF 01D9 > 000F > Available 53A0E000-53A64FFF 0057 > 000F > BS_Data53A65000-54778FFF 0D14 > 000F > Available 54779000-54785FFF 000D > 000F > BS_Data54786000-547CAFFF 0045 > 000F > Available 547CB000-547D3FFF 0009 > 000F > BS_Data547D4000-5481DFFF 004A > 000F > Available 5481E000-5481 0002 > 000F > BS_Data5482-56683FFF 1E64 > 000F > Available 56684000-590C2FFF 2A3F > 000F > BS_Code590C3000-59E83FFF 0DC1 > 000F > RT_Code59E84000-59F4BFFF 00C8 > 800F > RT_Data59F4C000-5B164FFF 1219 > 800F > Reserved 5B165000-5B566FFF 0402 > 000F > ACPI_NVS 5B567000-5B599FFF 0033 > 000F > ACPI_Recl 5B59A000-5B5FEFFF 0065 > 000F > BS_Data5B5FF000-5B5F 0001 > 000F > Available 0001-00029E7F 0019E800 > 000F > Reserved 000A-000F 0060 > > Reserved 5B60-5F7F 4200 > > MMIO F000-F7FF 8000 > 8001 > MMIO FE01-FE010FFF 0001 > 8001 > > Reserved : 18,039 Pages (73,887,744 Bytes) > LoaderCode:222 Pages (909,312 Bytes) > LoaderData: 0 Pages (0 Bytes) > BS_Code : 3,582 Pages (14,671,872 Bytes) > B
[edk2] Question about memory map entries
Hi everyone I have a question related to the memory map entries. Doing some tests, we noticed that if I have an application that has a lot of allocatepool() and freepool() calls, when this app is closed the amount of entries returned by the memmap shell commands increases a lot. Just for reference. This is the mapping before executing the application: Type StartEnd # Pages Attributes BS_Code-0FFF 0001 000F BS_Data1000-1FFF 0001 000F BS_Code2000-BFFF 000A 000F Available C000-00057FFF 004C 000F Reserved 00058000-00058FFF 0001 000F Available 00059000-00069FFF 0011 000F BS_Data0006A000-0006AFFF 0001 000F BS_Code0006B000-0008BFFF 0021 000F Reserved 0008C000-0009 0014 000F BS_Code0010-0010 0010 000F Available 0011-4D684FFF 0004D575 000F BS_Data4D685000-4D6A4FFF 0020 000F Available 4D6A5000-4E34EFFF 0CAA 000F LoaderCode 4E34F000-4E42CFFF 00DE 000F BS_Data4E42D000-50510FFF 20E4 000F ACPI_NVS 50511000-50511FFF 0001 000F RT_Data50512000-50512FFF 0001 800F BS_Data50513000-50673FFF 0161 000F BS_Code50674000-50674FFF 0001 000F Available 50675000-52B6EFFF 24FA 000F BS_Data52B6F000-53572FFF 0A04 000F Available 53573000-53834FFF 02C2 000F BS_Data53835000-53A0DFFF 01D9 000F Available 53A0E000-53A64FFF 0057 000F BS_Data53A65000-54778FFF 0D14 000F Available 54779000-54785FFF 000D 000F BS_Data54786000-547CAFFF 0045 000F Available 547CB000-547D3FFF 0009 000F BS_Data547D4000-5481DFFF 004A 000F Available 5481E000-5481 0002 000F BS_Data5482-56683FFF 1E64 000F Available 56684000-590C2FFF 2A3F 000F BS_Code590C3000-59E83FFF 0DC1 000F RT_Code59E84000-59F4BFFF 00C8 800F RT_Data59F4C000-5B164FFF 1219 800F Reserved 5B165000-5B566FFF 0402 000F ACPI_NVS 5B567000-5B599FFF 0033 000F ACPI_Recl 5B59A000-5B5FEFFF 0065 000F BS_Data5B5FF000-5B5F 0001 000F Available 0001-00029E7F 0019E800 000F Reserved 000A-000F 0060 Reserved 5B60-5F7F 4200 MMIO F000-F7FF 8000 8001 MMIO FE01-FE010FFF 0001 8001 Reserved : 18,039 Pages (73,887,744 Bytes) LoaderCode:222 Pages (909,312 Bytes) LoaderData: 0 Pages (0 Bytes) BS_Code : 3,582 Pages (14,671,872 Bytes) BS_Data : 23,116 Pages (94,683,136 Bytes) RT_Code :200 Pages (819,200 Bytes) RT_Data : 4,634 Pages (18,980,864 Bytes) ACPI_Recl :101 Pages (413,696 Bytes) ACPI_NVS : 52 Pages (212,992 Bytes) MMIO : 32,769 Pages (134,221,824 Bytes) MMIO_Port : 0 Pages (0 Bytes) PalCode : 0 Pages (0 Bytes) Available : 2,039,014 Pages (8,351,801,344 Bytes) -- Total Memory: 8,089 MB (8,482,492,416 Bytes) And this is the mapping after executing the application. Type StartEnd # Pages Attributes BS_Code-0FFF 0001 000F BS_Data1000-1FFF 0001 000F BS_Code2000-BFFF
