* Question about memory map entries
@ 2018-06-29 19:05 Rafael Machado
2018-06-29 19:27 ` Yao, Jiewen
0 siblings, 1 reply; 19+ messages in thread
From: Rafael Machado @ 2018-06-29 19:05 UTC (permalink / raw)
To: edk2-devel@lists.01.org
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 Start End # Pages Attributes
BS_Code 0000000000000000-0000000000000FFF 0000000000000001
000000000000000F
BS_Data 0000000000001000-0000000000001FFF 0000000000000001
000000000000000F
BS_Code 0000000000002000-000000000000BFFF 000000000000000A
000000000000000F
Available 000000000000C000-0000000000057FFF 000000000000004C
000000000000000F
Reserved 0000000000058000-0000000000058FFF 0000000000000001
000000000000000F
Available 0000000000059000-0000000000069FFF 0000000000000011
000000000000000F
BS_Data 000000000006A000-000000000006AFFF 0000000000000001
000000000000000F
BS_Code 000000000006B000-000000000008BFFF 0000000000000021
000000000000000F
Reserved 000000000008C000-000000000009FFFF 0000000000000014
000000000000000F
BS_Code 0000000000100000-000000000010FFFF 0000000000000010
000000000000000F
Available 0000000000110000-000000004D684FFF 000000000004D575
000000000000000F
BS_Data 000000004D685000-000000004D6A4FFF 0000000000000020
000000000000000F
Available 000000004D6A5000-000000004E34EFFF 0000000000000CAA
000000000000000F
LoaderCode 000000004E34F000-000000004E42CFFF 00000000000000DE
000000000000000F
BS_Data 000000004E42D000-0000000050510FFF 00000000000020E4
000000000000000F
ACPI_NVS 0000000050511000-0000000050511FFF 0000000000000001
000000000000000F
RT_Data 0000000050512000-0000000050512FFF 0000000000000001
800000000000000F
BS_Data 0000000050513000-0000000050673FFF 0000000000000161
000000000000000F
BS_Code 0000000050674000-0000000050674FFF 0000000000000001
000000000000000F
Available 0000000050675000-0000000052B6EFFF 00000000000024FA
000000000000000F
BS_Data 0000000052B6F000-0000000053572FFF 0000000000000A04
000000000000000F
Available 0000000053573000-0000000053834FFF 00000000000002C2
000000000000000F
BS_Data 0000000053835000-0000000053A0DFFF 00000000000001D9
000000000000000F
Available 0000000053A0E000-0000000053A64FFF 0000000000000057
000000000000000F
BS_Data 0000000053A65000-0000000054778FFF 0000000000000D14
000000000000000F
Available 0000000054779000-0000000054785FFF 000000000000000D
000000000000000F
BS_Data 0000000054786000-00000000547CAFFF 0000000000000045
000000000000000F
Available 00000000547CB000-00000000547D3FFF 0000000000000009
000000000000000F
BS_Data 00000000547D4000-000000005481DFFF 000000000000004A
000000000000000F
Available 000000005481E000-000000005481FFFF 0000000000000002
000000000000000F
BS_Data 0000000054820000-0000000056683FFF 0000000000001E64
000000000000000F
Available 0000000056684000-00000000590C2FFF 0000000000002A3F
000000000000000F
BS_Code 00000000590C3000-0000000059E83FFF 0000000000000DC1
000000000000000F
RT_Code 0000000059E84000-0000000059F4BFFF 00000000000000C8
800000000000000F
RT_Data 0000000059F4C000-000000005B164FFF 0000000000001219
800000000000000F
Reserved 000000005B165000-000000005B566FFF 0000000000000402
000000000000000F
ACPI_NVS 000000005B567000-000000005B599FFF 0000000000000033
000000000000000F
ACPI_Recl 000000005B59A000-000000005B5FEFFF 0000000000000065
000000000000000F
BS_Data 000000005B5FF000-000000005B5FFFFF 0000000000000001
000000000000000F
Available 0000000100000000-000000029E7FFFFF 000000000019E800
000000000000000F
Reserved 00000000000A0000-00000000000FFFFF 0000000000000060
0000000000000000
Reserved 000000005B600000-000000005F7FFFFF 0000000000004200
0000000000000000
MMIO 00000000F0000000-00000000F7FFFFFF 0000000000008000
8000000000000001
MMIO 00000000FE010000-00000000FE010FFF 0000000000000001
8000000000000001
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 Start End # Pages Attributes
BS_Code 0000000000000000-0000000000000FFF 0000000000000001
000000000000000F
BS_Data 0000000000001000-0000000000001FFF 0000000000000001
000000000000000F
BS_Code 0000000000002000-000000000000BFFF 000000000000000A
000000000000000F
Available 000000000000C000-0000000000057FFF 000000000000004C
000000000000000F
Reserved 0000000000058000-0000000000058FFF 0000000000000001
000000000000000F
Available 0000000000059000-0000000000069FFF 0000000000000011
000000000000000F
BS_Data 000000000006A000-000000000006AFFF 0000000000000001
000000000000000F
BS_Code 000000000006B000-000000000008BFFF 0000000000000021
000000000000000F
Reserved 000000000008C000-000000000009FFFF 0000000000000014
000000000000000F
BS_Code 0000000000100000-000000000010FFFF 0000000000000010
000000000000000F
Available 0000000000110000-000000004D684FFF 000000000004D575
000000000000000F
BS_Data 000000004D685000-000000004D6A4FFF 0000000000000020
000000000000000F
Available 000000004D6A5000-000000004E34EFFF 0000000000000CAA
000000000000000F
LoaderCode 000000004E34F000-000000004E42CFFF 00000000000000DE
000000000000000F
BS_Data 000000004E42D000-0000000050510FFF 00000000000020E4
000000000000000F
ACPI_NVS 0000000050511000-0000000050511FFF 0000000000000001
000000000000000F
RT_Data 0000000050512000-0000000050512FFF 0000000000000001
800000000000000F
BS_Data 0000000050513000-0000000050673FFF 0000000000000161
000000000000000F
BS_Code 0000000050674000-0000000050674FFF 0000000000000001
000000000000000F
Available 0000000050675000-0000000052384FFF 0000000000001D10
000000000000000F
BS_Data 0000000052385000-0000000053572FFF 00000000000011EE
000000000000000F
Available 0000000053573000-00000000535D7FFF 0000000000000065
000000000000000F
BS_Data 00000000535D8000-000000005363EFFF 0000000000000067
000000000000000F
Available 000000005363F000-0000000053834FFF 00000000000001F6
000000000000000F
BS_Data 0000000053835000-0000000053A0DFFF 00000000000001D9
000000000000000F
Available 0000000053A0E000-0000000053A64FFF 0000000000000057
000000000000000F
BS_Data 0000000053A65000-0000000053F8EFFF 000000000000052A
000000000000000F
Available 0000000053F8F000-0000000053F9AFFF 000000000000000C
000000000000000F
BS_Data 0000000053F9B000-0000000053F9CFFF 0000000000000002
000000000000000F
Available 0000000053F9D000-0000000053FA5FFF 0000000000000009
000000000000000F
BS_Data 0000000053FA6000-0000000053FAAFFF 0000000000000005
000000000000000F
Available 0000000053FAB000-000000005438CFFF 00000000000003E2
000000000000000F
BS_Data 000000005438D000-00000000543A5FFF 0000000000000019
000000000000000F
Available 00000000543A6000-0000000054416FFF 0000000000000071
000000000000000F
BS_Data 0000000054417000-0000000054417FFF 0000000000000001
000000000000000F
Available 0000000054418000-0000000054425FFF 000000000000000E
000000000000000F
BS_Data 0000000054426000-0000000054427FFF 0000000000000002
000000000000000F
Available 0000000054428000-0000000054439FFF 0000000000000012
000000000000000F
BS_Data 000000005443A000-000000005443FFFF 0000000000000006
000000000000000F
Available 0000000054440000-000000005444FFFF 0000000000000010
000000000000000F
BS_Data 0000000054450000-0000000054454FFF 0000000000000005
000000000000000F
Available 0000000054455000-0000000054458FFF 0000000000000004
000000000000000F
BS_Data 0000000054459000-000000005445BFFF 0000000000000003
000000000000000F
Available 000000005445C000-0000000054467FFF 000000000000000C
000000000000000F
BS_Data 0000000054468000-000000005446BFFF 0000000000000004
000000000000000F
Available 000000005446C000-000000005446FFFF 0000000000000004
000000000000000F
BS_Data 0000000054470000-0000000054470FFF 0000000000000001
000000000000000F
Available 0000000054471000-0000000054471FFF 0000000000000001
000000000000000F
BS_Data 0000000054472000-0000000054474FFF 0000000000000003
000000000000000F
Available 0000000054475000-0000000054490FFF 000000000000001C
000000000000000F
BS_Data 0000000054491000-0000000054494FFF 0000000000000004
000000000000000F
Available 0000000054495000-00000000544ABFFF 0000000000000017
000000000000000F
BS_Data 00000000544AC000-00000000544ACFFF 0000000000000001
000000000000000F
Available 00000000544AD000-00000000544CCFFF 0000000000000020
000000000000000F
BS_Data 00000000544CD000-00000000544CFFFF 0000000000000003
000000000000000F
Available 00000000544D0000-00000000544E1FFF 0000000000000012
000000000000000F
BS_Data 00000000544E2000-000000005450CFFF 000000000000002B
000000000000000F
Available 000000005450D000-000000005451DFFF 0000000000000011
000000000000000F
BS_Data 000000005451E000-000000005451EFFF 0000000000000001
000000000000000F
Available 000000005451F000-0000000054535FFF 0000000000000017
000000000000000F
BS_Data 0000000054536000-0000000054536FFF 0000000000000001
000000000000000F
Available 0000000054537000-000000005453EFFF 0000000000000008
000000000000000F
BS_Data 000000005453F000-0000000054543FFF 0000000000000005
000000000000000F
Available 0000000054544000-0000000054579FFF 0000000000000036
000000000000000F
BS_Data 000000005457A000-0000000054585FFF 000000000000000C
000000000000000F
Available 0000000054586000-0000000054589FFF 0000000000000004
000000000000000F
BS_Data 000000005458A000-000000005458CFFF 0000000000000003
000000000000000F
Available 000000005458D000-000000005459DFFF 0000000000000011
000000000000000F
BS_Data 000000005459E000-000000005459EFFF 0000000000000001
000000000000000F
Available 000000005459F000-00000000545A1FFF 0000000000000003
000000000000000F
BS_Data 00000000545A2000-00000000545A2FFF 0000000000000001
000000000000000F
Available 00000000545A3000-00000000545A7FFF 0000000000000005
000000000000000F
BS_Data 00000000545A8000-00000000545A9FFF 0000000000000002
000000000000000F
Available 00000000545AA000-0000000054756FFF 00000000000001AD
000000000000000F
BS_Data 0000000054757000-000000005477EFFF 0000000000000028
000000000000000F
Available 000000005477F000-0000000054780FFF 0000000000000002
000000000000000F
BS_Data 0000000054781000-0000000054785FFF 0000000000000005
000000000000000F
Available 0000000054786000-0000000054789FFF 0000000000000004
000000000000000F
BS_Data 000000005478A000-00000000547CBFFF 0000000000000042
000000000000000F
Available 00000000547CC000-00000000547CEFFF 0000000000000003
000000000000000F
BS_Data 00000000547CF000-00000000547D3FFF 0000000000000005
000000000000000F
Available 00000000547D4000-00000000547E7FFF 0000000000000014
000000000000000F
BS_Data 00000000547E8000-00000000547F4FFF 000000000000000D
000000000000000F
Available 00000000547F5000-00000000547FBFFF 0000000000000007
000000000000000F
BS_Data 00000000547FC000-000000005481EFFF 0000000000000023
000000000000000F
Available 000000005481F000-000000005481FFFF 0000000000000001
000000000000000F
BS_Data 0000000054820000-0000000054828FFF 0000000000000009
000000000000000F
Available 0000000054829000-0000000054829FFF 0000000000000001
000000000000000F
BS_Data 000000005482A000-0000000054CFAFFF 00000000000004D1
000000000000000F
Available 0000000054CFB000-0000000054CFCFFF 0000000000000002
000000000000000F
BS_Data 0000000054CFD000-0000000055269FFF 000000000000056D
000000000000000F
Available 000000005526A000-000000005526EFFF 0000000000000005
000000000000000F
BS_Data 000000005526F000-0000000056683FFF 0000000000001415
000000000000000F
Available 0000000056684000-00000000590C2FFF 0000000000002A3F
000000000000000F
BS_Code 00000000590C3000-0000000059E83FFF 0000000000000DC1
000000000000000F
RT_Code 0000000059E84000-0000000059F4BFFF 00000000000000C8
800000000000000F
RT_Data 0000000059F4C000-000000005B164FFF 0000000000001219
800000000000000F
Reserved 000000005B165000-000000005B566FFF 0000000000000402
000000000000000F
ACPI_NVS 000000005B567000-000000005B599FFF 0000000000000033
000000000000000F
ACPI_Recl 000000005B59A000-000000005B5FEFFF 0000000000000065
000000000000000F
BS_Data 000000005B5FF000-000000005B5FFFFF 0000000000000001
000000000000000F
Available 0000000100000000-000000029E7FFFFF 000000000019E800
000000000000000F
Reserved 00000000000A0000-00000000000FFFFF 0000000000000060
0000000000000000
Reserved 000000005B600000-000000005F7FFFFF 0000000000004200
0000000000000000
MMIO 00000000F0000000-00000000F7FFFFFF 0000000000008000
8000000000000001
MMIO 00000000FE010000-00000000FE010FFF 0000000000000001
8000000000000001
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,366 Pages (95,707,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,038,764 Pages (8,350,777,344 Bytes)
--------------
Total Memory: 8,089 MB (8,482,492,416 Bytes)
I would like to understand better what causes these entries to be created.
We already checked and there is no memory leak at the code.
What causes these entries to be created?
Can this increase on the memory map entries represent a risk of hanging the
system at the subsequent boot?
Thanks and Regards
Rafael R. Machado
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Question about memory map entries
2018-06-29 19:05 Question about memory map entries Rafael Machado
@ 2018-06-29 19:27 ` Yao, Jiewen
2018-06-30 1:31 ` Ni, Ruiyu
0 siblings, 1 reply; 19+ messages in thread
From: Yao, Jiewen @ 2018-06-29 19:27 UTC (permalink / raw)
To: Rafael Machado, edk2-devel@lists.01.org
Shell itself may allocate internal buffer to save something, such as history.
Thank you
Yao Jiewen
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@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 Start End # Pages
> Attributes
> BS_Code 0000000000000000-0000000000000FFF 0000000000000001
> 000000000000000F
> BS_Data 0000000000001000-0000000000001FFF 0000000000000001
> 000000000000000F
> BS_Code 0000000000002000-000000000000BFFF 000000000000000A
> 000000000000000F
> Available 000000000000C000-0000000000057FFF 000000000000004C
> 000000000000000F
> Reserved 0000000000058000-0000000000058FFF 0000000000000001
> 000000000000000F
> Available 0000000000059000-0000000000069FFF 0000000000000011
> 000000000000000F
> BS_Data 000000000006A000-000000000006AFFF 0000000000000001
> 000000000000000F
> BS_Code 000000000006B000-000000000008BFFF 0000000000000021
> 000000000000000F
> Reserved 000000000008C000-000000000009FFFF 0000000000000014
> 000000000000000F
> BS_Code 0000000000100000-000000000010FFFF 0000000000000010
> 000000000000000F
> Available 0000000000110000-000000004D684FFF 000000000004D575
> 000000000000000F
> BS_Data 000000004D685000-000000004D6A4FFF 0000000000000020
> 000000000000000F
> Available 000000004D6A5000-000000004E34EFFF 0000000000000CAA
> 000000000000000F
> LoaderCode 000000004E34F000-000000004E42CFFF 00000000000000DE
> 000000000000000F
> BS_Data 000000004E42D000-0000000050510FFF 00000000000020E4
> 000000000000000F
> ACPI_NVS 0000000050511000-0000000050511FFF 0000000000000001
> 000000000000000F
> RT_Data 0000000050512000-0000000050512FFF 0000000000000001
> 800000000000000F
> BS_Data 0000000050513000-0000000050673FFF 0000000000000161
> 000000000000000F
> BS_Code 0000000050674000-0000000050674FFF 0000000000000001
> 000000000000000F
> Available 0000000050675000-0000000052B6EFFF 00000000000024FA
> 000000000000000F
> BS_Data 0000000052B6F000-0000000053572FFF 0000000000000A04
> 000000000000000F
> Available 0000000053573000-0000000053834FFF 00000000000002C2
> 000000000000000F
> BS_Data 0000000053835000-0000000053A0DFFF 00000000000001D9
> 000000000000000F
> Available 0000000053A0E000-0000000053A64FFF 0000000000000057
> 000000000000000F
> BS_Data 0000000053A65000-0000000054778FFF 0000000000000D14
> 000000000000000F
> Available 0000000054779000-0000000054785FFF 000000000000000D
> 000000000000000F
> BS_Data 0000000054786000-00000000547CAFFF 0000000000000045
> 000000000000000F
> Available 00000000547CB000-00000000547D3FFF 0000000000000009
> 000000000000000F
> BS_Data 00000000547D4000-000000005481DFFF 000000000000004A
> 000000000000000F
> Available 000000005481E000-000000005481FFFF 0000000000000002
> 000000000000000F
> BS_Data 0000000054820000-0000000056683FFF 0000000000001E64
> 000000000000000F
> Available 0000000056684000-00000000590C2FFF 0000000000002A3F
> 000000000000000F
> BS_Code 00000000590C3000-0000000059E83FFF 0000000000000DC1
> 000000000000000F
> RT_Code 0000000059E84000-0000000059F4BFFF 00000000000000C8
> 800000000000000F
> RT_Data 0000000059F4C000-000000005B164FFF 0000000000001219
> 800000000000000F
> Reserved 000000005B165000-000000005B566FFF 0000000000000402
> 000000000000000F
> ACPI_NVS 000000005B567000-000000005B599FFF 0000000000000033
> 000000000000000F
> ACPI_Recl 000000005B59A000-000000005B5FEFFF 0000000000000065
> 000000000000000F
> BS_Data 000000005B5FF000-000000005B5FFFFF 0000000000000001
> 000000000000000F
> Available 0000000100000000-000000029E7FFFFF 000000000019E800
> 000000000000000F
> Reserved 00000000000A0000-00000000000FFFFF 0000000000000060
> 0000000000000000
> Reserved 000000005B600000-000000005F7FFFFF 0000000000004200
> 0000000000000000
> MMIO 00000000F0000000-00000000F7FFFFFF 0000000000008000
> 8000000000000001
> MMIO 00000000FE010000-00000000FE010FFF 0000000000000001
> 8000000000000001
>
> 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 Start End # Pages
> Attributes
> BS_Code 0000000000000000-0000000000000FFF 0000000000000001
> 000000000000000F
> BS_Data 0000000000001000-0000000000001FFF 0000000000000001
> 000000000000000F
> BS_Code 0000000000002000-000000000000BFFF 000000000000000A
> 000000000000000F
> Available 000000000000C000-0000000000057FFF 000000000000004C
> 000000000000000F
> Reserved 0000000000058000-0000000000058FFF 0000000000000001
> 000000000000000F
> Available 0000000000059000-0000000000069FFF 0000000000000011
> 000000000000000F
> BS_Data 000000000006A000-000000000006AFFF 0000000000000001
> 000000000000000F
> BS_Code 000000000006B000-000000000008BFFF 0000000000000021
> 000000000000000F
> Reserved 000000000008C000-000000000009FFFF 0000000000000014
> 000000000000000F
> BS_Code 0000000000100000-000000000010FFFF 0000000000000010
> 000000000000000F
> Available 0000000000110000-000000004D684FFF 000000000004D575
> 000000000000000F
> BS_Data 000000004D685000-000000004D6A4FFF 0000000000000020
> 000000000000000F
> Available 000000004D6A5000-000000004E34EFFF 0000000000000CAA
> 000000000000000F
> LoaderCode 000000004E34F000-000000004E42CFFF 00000000000000DE
> 000000000000000F
> BS_Data 000000004E42D000-0000000050510FFF 00000000000020E4
> 000000000000000F
> ACPI_NVS 0000000050511000-0000000050511FFF 0000000000000001
> 000000000000000F
> RT_Data 0000000050512000-0000000050512FFF 0000000000000001
> 800000000000000F
> BS_Data 0000000050513000-0000000050673FFF 0000000000000161
> 000000000000000F
> BS_Code 0000000050674000-0000000050674FFF 0000000000000001
> 000000000000000F
> Available 0000000050675000-0000000052384FFF 0000000000001D10
> 000000000000000F
> BS_Data 0000000052385000-0000000053572FFF 00000000000011EE
> 000000000000000F
> Available 0000000053573000-00000000535D7FFF 0000000000000065
> 000000000000000F
> BS_Data 00000000535D8000-000000005363EFFF 0000000000000067
> 000000000000000F
> Available 000000005363F000-0000000053834FFF 00000000000001F6
> 000000000000000F
> BS_Data 0000000053835000-0000000053A0DFFF 00000000000001D9
> 000000000000000F
> Available 0000000053A0E000-0000000053A64FFF 0000000000000057
> 000000000000000F
> BS_Data 0000000053A65000-0000000053F8EFFF 000000000000052A
> 000000000000000F
> Available 0000000053F8F000-0000000053F9AFFF 000000000000000C
> 000000000000000F
> BS_Data 0000000053F9B000-0000000053F9CFFF 0000000000000002
> 000000000000000F
> Available 0000000053F9D000-0000000053FA5FFF 0000000000000009
> 000000000000000F
> BS_Data 0000000053FA6000-0000000053FAAFFF 0000000000000005
> 000000000000000F
> Available 0000000053FAB000-000000005438CFFF 00000000000003E2
> 000000000000000F
> BS_Data 000000005438D000-00000000543A5FFF 0000000000000019
> 000000000000000F
> Available 00000000543A6000-0000000054416FFF 0000000000000071
> 000000000000000F
> BS_Data 0000000054417000-0000000054417FFF 0000000000000001
> 000000000000000F
> Available 0000000054418000-0000000054425FFF 000000000000000E
> 000000000000000F
> BS_Data 0000000054426000-0000000054427FFF 0000000000000002
> 000000000000000F
> Available 0000000054428000-0000000054439FFF 0000000000000012
> 000000000000000F
> BS_Data 000000005443A000-000000005443FFFF 0000000000000006
> 000000000000000F
> Available 0000000054440000-000000005444FFFF 0000000000000010
> 000000000000000F
> BS_Data 0000000054450000-0000000054454FFF 0000000000000005
> 000000000000000F
> Available 0000000054455000-0000000054458FFF 0000000000000004
> 000000000000000F
> BS_Data 0000000054459000-000000005445BFFF 0000000000000003
> 000000000000000F
> Available 000000005445C000-0000000054467FFF 000000000000000C
> 000000000000000F
> BS_Data 0000000054468000-000000005446BFFF 0000000000000004
> 000000000000000F
> Available 000000005446C000-000000005446FFFF 0000000000000004
> 000000000000000F
> BS_Data 0000000054470000-0000000054470FFF 0000000000000001
> 000000000000000F
> Available 0000000054471000-0000000054471FFF 0000000000000001
> 000000000000000F
> BS_Data 0000000054472000-0000000054474FFF 0000000000000003
> 000000000000000F
> Available 0000000054475000-0000000054490FFF 000000000000001C
> 000000000000000F
> BS_Data 0000000054491000-0000000054494FFF 0000000000000004
> 000000000000000F
> Available 0000000054495000-00000000544ABFFF 0000000000000017
> 000000000000000F
> BS_Data 00000000544AC000-00000000544ACFFF 0000000000000001
> 000000000000000F
> Available 00000000544AD000-00000000544CCFFF 0000000000000020
> 000000000000000F
> BS_Data 00000000544CD000-00000000544CFFFF 0000000000000003
> 000000000000000F
> Available 00000000544D0000-00000000544E1FFF 0000000000000012
> 000000000000000F
> BS_Data 00000000544E2000-000000005450CFFF 000000000000002B
> 000000000000000F
> Available 000000005450D000-000000005451DFFF 0000000000000011
> 000000000000000F
> BS_Data 000000005451E000-000000005451EFFF 0000000000000001
> 000000000000000F
> Available 000000005451F000-0000000054535FFF 0000000000000017
> 000000000000000F
> BS_Data 0000000054536000-0000000054536FFF 0000000000000001
> 000000000000000F
> Available 0000000054537000-000000005453EFFF 0000000000000008
> 000000000000000F
> BS_Data 000000005453F000-0000000054543FFF 0000000000000005
> 000000000000000F
> Available 0000000054544000-0000000054579FFF 0000000000000036
> 000000000000000F
> BS_Data 000000005457A000-0000000054585FFF 000000000000000C
> 000000000000000F
> Available 0000000054586000-0000000054589FFF 0000000000000004
> 000000000000000F
> BS_Data 000000005458A000-000000005458CFFF 0000000000000003
> 000000000000000F
> Available 000000005458D000-000000005459DFFF 0000000000000011
> 000000000000000F
> BS_Data 000000005459E000-000000005459EFFF 0000000000000001
> 000000000000000F
> Available 000000005459F000-00000000545A1FFF 0000000000000003
> 000000000000000F
> BS_Data 00000000545A2000-00000000545A2FFF 0000000000000001
> 000000000000000F
> Available 00000000545A3000-00000000545A7FFF 0000000000000005
> 000000000000000F
> BS_Data 00000000545A8000-00000000545A9FFF 0000000000000002
> 000000000000000F
> Available 00000000545AA000-0000000054756FFF 00000000000001AD
> 000000000000000F
> BS_Data 0000000054757000-000000005477EFFF 0000000000000028
> 000000000000000F
> Available 000000005477F000-0000000054780FFF 0000000000000002
> 000000000000000F
> BS_Data 0000000054781000-0000000054785FFF 0000000000000005
> 000000000000000F
> Available 0000000054786000-0000000054789FFF 0000000000000004
> 000000000000000F
> BS_Data 000000005478A000-00000000547CBFFF 0000000000000042
> 000000000000000F
> Available 00000000547CC000-00000000547CEFFF 0000000000000003
> 000000000000000F
> BS_Data 00000000547CF000-00000000547D3FFF 0000000000000005
> 000000000000000F
> Available 00000000547D4000-00000000547E7FFF 0000000000000014
> 000000000000000F
> BS_Data 00000000547E8000-00000000547F4FFF 000000000000000D
> 000000000000000F
> Available 00000000547F5000-00000000547FBFFF 0000000000000007
> 000000000000000F
> BS_Data 00000000547FC000-000000005481EFFF 0000000000000023
> 000000000000000F
> Available 000000005481F000-000000005481FFFF 0000000000000001
> 000000000000000F
> BS_Data 0000000054820000-0000000054828FFF 0000000000000009
> 000000000000000F
> Available 0000000054829000-0000000054829FFF 0000000000000001
> 000000000000000F
> BS_Data 000000005482A000-0000000054CFAFFF 00000000000004D1
> 000000000000000F
> Available 0000000054CFB000-0000000054CFCFFF 0000000000000002
> 000000000000000F
> BS_Data 0000000054CFD000-0000000055269FFF 000000000000056D
> 000000000000000F
> Available 000000005526A000-000000005526EFFF 0000000000000005
> 000000000000000F
> BS_Data 000000005526F000-0000000056683FFF 0000000000001415
> 000000000000000F
> Available 0000000056684000-00000000590C2FFF 0000000000002A3F
> 000000000000000F
> BS_Code 00000000590C3000-0000000059E83FFF 0000000000000DC1
> 000000000000000F
> RT_Code 0000000059E84000-0000000059F4BFFF 00000000000000C8
> 800000000000000F
> RT_Data 0000000059F4C000-000000005B164FFF 0000000000001219
> 800000000000000F
> Reserved 000000005B165000-000000005B566FFF 0000000000000402
> 000000000000000F
> ACPI_NVS 000000005B567000-000000005B599FFF 0000000000000033
> 000000000000000F
> ACPI_Recl 000000005B59A000-000000005B5FEFFF 0000000000000065
> 000000000000000F
> BS_Data 000000005B5FF000-000000005B5FFFFF 0000000000000001
> 000000000000000F
> Available 0000000100000000-000000029E7FFFFF 000000000019E800
> 000000000000000F
> Reserved 00000000000A0000-00000000000FFFFF 0000000000000060
> 0000000000000000
> Reserved 000000005B600000-000000005F7FFFFF 0000000000004200
> 0000000000000000
> MMIO 00000000F0000000-00000000F7FFFFFF 0000000000008000
> 8000000000000001
> MMIO 00000000FE010000-00000000FE010FFF 0000000000000001
> 8000000000000001
>
> 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,366 Pages (95,707,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,038,764 Pages (8,350,777,344 Bytes)
> --------------
> Total Memory: 8,089 MB (8,482,492,416 Bytes)
>
>
> I would like to understand better what causes these entries to be created.
> We already checked and there is no memory leak at the code.
> What causes these entries to be created?
> Can this increase on the memory map entries represent a risk of hanging the
> system at the subsequent boot?
>
> Thanks and Regards
> Rafael R. Machado
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Question about memory map entries
2018-06-29 19:27 ` Yao, Jiewen
@ 2018-06-30 1:31 ` Ni, Ruiyu
2018-06-30 12:02 ` Rafael Machado
0 siblings, 1 reply; 19+ messages in thread
From: Ni, Ruiyu @ 2018-06-30 1:31 UTC (permalink / raw)
To: Yao, Jiewen, Rafael Machado, edk2-devel@lists.01.org
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-bounces@lists.01.org] On Behalf Of Yao,
> Jiewen
> Sent: Saturday, June 30, 2018 3:28 AM
> To: Rafael Machado <rafaelrodrigues.machado@gmail.com>; edk2-
> devel@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-bounces@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 Start End # Pages
> > Attributes
> > BS_Code 0000000000000000-0000000000000FFF 0000000000000001
> > 000000000000000F
> > BS_Data 0000000000001000-0000000000001FFF 0000000000000001
> > 000000000000000F
> > BS_Code 0000000000002000-000000000000BFFF 000000000000000A
> > 000000000000000F
> > Available 000000000000C000-0000000000057FFF 000000000000004C
> > 000000000000000F
> > Reserved 0000000000058000-0000000000058FFF 0000000000000001
> > 000000000000000F
> > Available 0000000000059000-0000000000069FFF 0000000000000011
> > 000000000000000F
> > BS_Data 000000000006A000-000000000006AFFF 0000000000000001
> > 000000000000000F
> > BS_Code 000000000006B000-000000000008BFFF 0000000000000021
> > 000000000000000F
> > Reserved 000000000008C000-000000000009FFFF 0000000000000014
> > 000000000000000F
> > BS_Code 0000000000100000-000000000010FFFF 0000000000000010
> > 000000000000000F
> > Available 0000000000110000-000000004D684FFF 000000000004D575
> > 000000000000000F
> > BS_Data 000000004D685000-000000004D6A4FFF 0000000000000020
> > 000000000000000F
> > Available 000000004D6A5000-000000004E34EFFF 0000000000000CAA
> > 000000000000000F LoaderCode 000000004E34F000-000000004E42CFFF
> > 00000000000000DE 000000000000000F
> > BS_Data 000000004E42D000-0000000050510FFF 00000000000020E4
> > 000000000000000F
> > ACPI_NVS 0000000050511000-0000000050511FFF 0000000000000001
> > 000000000000000F
> > RT_Data 0000000050512000-0000000050512FFF 0000000000000001
> > 800000000000000F
> > BS_Data 0000000050513000-0000000050673FFF 0000000000000161
> > 000000000000000F
> > BS_Code 0000000050674000-0000000050674FFF 0000000000000001
> > 000000000000000F
> > Available 0000000050675000-0000000052B6EFFF 00000000000024FA
> > 000000000000000F
> > BS_Data 0000000052B6F000-0000000053572FFF 0000000000000A04
> > 000000000000000F
> > Available 0000000053573000-0000000053834FFF 00000000000002C2
> > 000000000000000F
> > BS_Data 0000000053835000-0000000053A0DFFF 00000000000001D9
> > 000000000000000F
> > Available 0000000053A0E000-0000000053A64FFF 0000000000000057
> > 000000000000000F
> > BS_Data 0000000053A65000-0000000054778FFF 0000000000000D14
> > 000000000000000F
> > Available 0000000054779000-0000000054785FFF 000000000000000D
> > 000000000000000F
> > BS_Data 0000000054786000-00000000547CAFFF 0000000000000045
> > 000000000000000F
> > Available 00000000547CB000-00000000547D3FFF 0000000000000009
> > 000000000000000F
> > BS_Data 00000000547D4000-000000005481DFFF 000000000000004A
> > 000000000000000F
> > Available 000000005481E000-000000005481FFFF 0000000000000002
> > 000000000000000F
> > BS_Data 0000000054820000-0000000056683FFF 0000000000001E64
> > 000000000000000F
> > Available 0000000056684000-00000000590C2FFF 0000000000002A3F
> > 000000000000000F
> > BS_Code 00000000590C3000-0000000059E83FFF 0000000000000DC1
> > 000000000000000F
> > RT_Code 0000000059E84000-0000000059F4BFFF 00000000000000C8
> > 800000000000000F
> > RT_Data 0000000059F4C000-000000005B164FFF 0000000000001219
> > 800000000000000F
> > Reserved 000000005B165000-000000005B566FFF 0000000000000402
> > 000000000000000F
> > ACPI_NVS 000000005B567000-000000005B599FFF 0000000000000033
> > 000000000000000F
> > ACPI_Recl 000000005B59A000-000000005B5FEFFF 0000000000000065
> > 000000000000000F
> > BS_Data 000000005B5FF000-000000005B5FFFFF 0000000000000001
> > 000000000000000F
> > Available 0000000100000000-000000029E7FFFFF 000000000019E800
> > 000000000000000F
> > Reserved 00000000000A0000-00000000000FFFFF 0000000000000060
> > 0000000000000000
> > Reserved 000000005B600000-000000005F7FFFFF 0000000000004200
> > 0000000000000000
> > MMIO 00000000F0000000-00000000F7FFFFFF 0000000000008000
> > 8000000000000001
> > MMIO 00000000FE010000-00000000FE010FFF 0000000000000001
> > 8000000000000001
> >
> > 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 Start End # Pages
> > Attributes
> > BS_Code 0000000000000000-0000000000000FFF 0000000000000001
> > 000000000000000F
> > BS_Data 0000000000001000-0000000000001FFF 0000000000000001
> > 000000000000000F
> > BS_Code 0000000000002000-000000000000BFFF 000000000000000A
> > 000000000000000F
> > Available 000000000000C000-0000000000057FFF 000000000000004C
> > 000000000000000F
> > Reserved 0000000000058000-0000000000058FFF 0000000000000001
> > 000000000000000F
> > Available 0000000000059000-0000000000069FFF 0000000000000011
> > 000000000000000F
> > BS_Data 000000000006A000-000000000006AFFF 0000000000000001
> > 000000000000000F
> > BS_Code 000000000006B000-000000000008BFFF 0000000000000021
> > 000000000000000F
> > Reserved 000000000008C000-000000000009FFFF 0000000000000014
> > 000000000000000F
> > BS_Code 0000000000100000-000000000010FFFF 0000000000000010
> > 000000000000000F
> > Available 0000000000110000-000000004D684FFF 000000000004D575
> > 000000000000000F
> > BS_Data 000000004D685000-000000004D6A4FFF 0000000000000020
> > 000000000000000F
> > Available 000000004D6A5000-000000004E34EFFF 0000000000000CAA
> > 000000000000000F LoaderCode 000000004E34F000-000000004E42CFFF
> > 00000000000000DE 000000000000000F
> > BS_Data 000000004E42D000-0000000050510FFF 00000000000020E4
> > 000000000000000F
> > ACPI_NVS 0000000050511000-0000000050511FFF 0000000000000001
> > 000000000000000F
> > RT_Data 0000000050512000-0000000050512FFF 0000000000000001
> > 800000000000000F
> > BS_Data 0000000050513000-0000000050673FFF 0000000000000161
> > 000000000000000F
> > BS_Code 0000000050674000-0000000050674FFF 0000000000000001
> > 000000000000000F
> > Available 0000000050675000-0000000052384FFF 0000000000001D10
> > 000000000000000F
> > BS_Data 0000000052385000-0000000053572FFF 00000000000011EE
> > 000000000000000F
> > Available 0000000053573000-00000000535D7FFF 0000000000000065
> > 000000000000000F
> > BS_Data 00000000535D8000-000000005363EFFF 0000000000000067
> > 000000000000000F
> > Available 000000005363F000-0000000053834FFF 00000000000001F6
> > 000000000000000F
> > BS_Data 0000000053835000-0000000053A0DFFF 00000000000001D9
> > 000000000000000F
> > Available 0000000053A0E000-0000000053A64FFF 0000000000000057
> > 000000000000000F
> > BS_Data 0000000053A65000-0000000053F8EFFF 000000000000052A
> > 000000000000000F
> > Available 0000000053F8F000-0000000053F9AFFF 000000000000000C
> > 000000000000000F
> > BS_Data 0000000053F9B000-0000000053F9CFFF 0000000000000002
> > 000000000000000F
> > Available 0000000053F9D000-0000000053FA5FFF 0000000000000009
> > 000000000000000F
> > BS_Data 0000000053FA6000-0000000053FAAFFF 0000000000000005
> > 000000000000000F
> > Available 0000000053FAB000-000000005438CFFF 00000000000003E2
> > 000000000000000F
> > BS_Data 000000005438D000-00000000543A5FFF 0000000000000019
> > 000000000000000F
> > Available 00000000543A6000-0000000054416FFF 0000000000000071
> > 000000000000000F
> > BS_Data 0000000054417000-0000000054417FFF 0000000000000001
> > 000000000000000F
> > Available 0000000054418000-0000000054425FFF 000000000000000E
> > 000000000000000F
> > BS_Data 0000000054426000-0000000054427FFF 0000000000000002
> > 000000000000000F
> > Available 0000000054428000-0000000054439FFF 0000000000000012
> > 000000000000000F
> > BS_Data 000000005443A000-000000005443FFFF 0000000000000006
> > 000000000000000F
> > Available 0000000054440000-000000005444FFFF 0000000000000010
> > 000000000000000F
> > BS_Data 0000000054450000-0000000054454FFF 0000000000000005
> > 000000000000000F
> > Available 0000000054455000-0000000054458FFF 0000000000000004
> > 000000000000000F
> > BS_Data 0000000054459000-000000005445BFFF 0000000000000003
> > 000000000000000F
> > Available 000000005445C000-0000000054467FFF 000000000000000C
> > 000000000000000F
> > BS_Data 0000000054468000-000000005446BFFF 0000000000000004
> > 000000000000000F
> > Available 000000005446C000-000000005446FFFF 0000000000000004
> > 000000000000000F
> > BS_Data 0000000054470000-0000000054470FFF 0000000000000001
> > 000000000000000F
> > Available 0000000054471000-0000000054471FFF 0000000000000001
> > 000000000000000F
> > BS_Data 0000000054472000-0000000054474FFF 0000000000000003
> > 000000000000000F
> > Available 0000000054475000-0000000054490FFF 000000000000001C
> > 000000000000000F
> > BS_Data 0000000054491000-0000000054494FFF 0000000000000004
> > 000000000000000F
> > Available 0000000054495000-00000000544ABFFF 0000000000000017
> > 000000000000000F
> > BS_Data 00000000544AC000-00000000544ACFFF 0000000000000001
> > 000000000000000F
> > Available 00000000544AD000-00000000544CCFFF 0000000000000020
> > 000000000000000F
> > BS_Data 00000000544CD000-00000000544CFFFF 0000000000000003
> > 000000000000000F
> > Available 00000000544D0000-00000000544E1FFF 0000000000000012
> > 000000000000000F
> > BS_Data 00000000544E2000-000000005450CFFF 000000000000002B
> > 000000000000000F
> > Available 000000005450D000-000000005451DFFF 0000000000000011
> > 000000000000000F
> > BS_Data 000000005451E000-000000005451EFFF 0000000000000001
> > 000000000000000F
> > Available 000000005451F000-0000000054535FFF 0000000000000017
> > 000000000000000F
> > BS_Data 0000000054536000-0000000054536FFF 0000000000000001
> > 000000000000000F
> > Available 0000000054537000-000000005453EFFF 0000000000000008
> > 000000000000000F
> > BS_Data 000000005453F000-0000000054543FFF 0000000000000005
> > 000000000000000F
> > Available 0000000054544000-0000000054579FFF 0000000000000036
> > 000000000000000F
> > BS_Data 000000005457A000-0000000054585FFF 000000000000000C
> > 000000000000000F
> > Available 0000000054586000-0000000054589FFF 0000000000000004
> > 000000000000000F
> > BS_Data 000000005458A000-000000005458CFFF 0000000000000003
> > 000000000000000F
> > Available 000000005458D000-000000005459DFFF 0000000000000011
> > 000000000000000F
> > BS_Data 000000005459E000-000000005459EFFF 0000000000000001
> > 000000000000000F
> > Available 000000005459F000-00000000545A1FFF 0000000000000003
> > 000000000000000F
> > BS_Data 00000000545A2000-00000000545A2FFF 0000000000000001
> > 000000000000000F
> > Available 00000000545A3000-00000000545A7FFF 0000000000000005
> > 000000000000000F
> > BS_Data 00000000545A8000-00000000545A9FFF 0000000000000002
> > 000000000000000F
> > Available 00000000545AA000-0000000054756FFF 00000000000001AD
> > 000000000000000F
> > BS_Data 0000000054757000-000000005477EFFF 0000000000000028
> > 000000000000000F
> > Available 000000005477F000-0000000054780FFF 0000000000000002
> > 000000000000000F
> > BS_Data 0000000054781000-0000000054785FFF 0000000000000005
> > 000000000000000F
> > Available 0000000054786000-0000000054789FFF 0000000000000004
> > 000000000000000F
> > BS_Data 000000005478A000-00000000547CBFFF 0000000000000042
> > 000000000000000F
> > Available 00000000547CC000-00000000547CEFFF 0000000000000003
> > 000000000000000F
> > BS_Data 00000000547CF000-00000000547D3FFF 0000000000000005
> > 000000000000000F
> > Available 00000000547D4000-00000000547E7FFF 0000000000000014
> > 000000000000000F
> > BS_Data 00000000547E8000-00000000547F4FFF 000000000000000D
> > 000000000000000F
> > Available 00000000547F5000-00000000547FBFFF 0000000000000007
> > 000000000000000F
> > BS_Data 00000000547FC000-000000005481EFFF 0000000000000023
> > 000000000000000F
> > Available 000000005481F000-000000005481FFFF 0000000000000001
> > 000000000000000F
> > BS_Data 0000000054820000-0000000054828FFF 0000000000000009
> > 000000000000000F
> > Available 0000000054829000-0000000054829FFF 0000000000000001
> > 000000000000000F
> > BS_Data 000000005482A000-0000000054CFAFFF 00000000000004D1
> > 000000000000000F
> > Available 0000000054CFB000-0000000054CFCFFF 0000000000000002
> > 000000000000000F
> > BS_Data 0000000054CFD000-0000000055269FFF 000000000000056D
> > 000000000000000F
> > Available 000000005526A000-000000005526EFFF 0000000000000005
> > 000000000000000F
> > BS_Data 000000005526F000-0000000056683FFF 0000000000001415
> > 000000000000000F
> > Available 0000000056684000-00000000590C2FFF 0000000000002A3F
> > 000000000000000F
> > BS_Code 00000000590C3000-0000000059E83FFF 0000000000000DC1
> > 000000000000000F
> > RT_Code 0000000059E84000-0000000059F4BFFF 00000000000000C8
> > 800000000000000F
> > RT_Data 0000000059F4C000-000000005B164FFF 0000000000001219
> > 800000000000000F
> > Reserved 000000005B165000-000000005B566FFF 0000000000000402
> > 000000000000000F
> > ACPI_NVS 000000005B567000-000000005B599FFF 0000000000000033
> > 000000000000000F
> > ACPI_Recl 000000005B59A000-000000005B5FEFFF 0000000000000065
> > 000000000000000F
> > BS_Data 000000005B5FF000-000000005B5FFFFF 0000000000000001
> > 000000000000000F
> > Available 0000000100000000-000000029E7FFFFF 000000000019E800
> > 000000000000000F
> > Reserved 00000000000A0000-00000000000FFFFF 0000000000000060
> > 0000000000000000
> > Reserved 000000005B600000-000000005F7FFFFF 0000000000004200
> > 0000000000000000
> > MMIO 00000000F0000000-00000000F7FFFFFF 0000000000008000
> > 8000000000000001
> > MMIO 00000000FE010000-00000000FE010FFF 0000000000000001
> > 8000000000000001
> >
> > 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,366 Pages (95,707,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,038,764 Pages (8,350,777,344 Bytes)
> > --------------
> > Total Memory: 8,089 MB (8,482,492,416 Bytes)
> >
> >
> > I would like to understand better what causes these entries to be created.
> > We already checked and there is no memory leak at the code.
> > What causes these entries to be created?
> > Can this increase on the memory map entries represent a risk of
> > hanging the system at the subsequent boot?
> >
> > Thanks and Regards
> > Rafael R. Machado
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Question about memory map entries
2018-06-30 1:31 ` Ni, Ruiyu
@ 2018-06-30 12:02 ` Rafael Machado
2018-06-30 19:23 ` Andrew Fish
0 siblings, 1 reply; 19+ messages in thread
From: Rafael Machado @ 2018-06-30 12:02 UTC (permalink / raw)
To: Ni, Ruiyu; +Cc: Yao, Jiewen, edk2-devel@lists.01.org
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 <ruiyu.ni@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-bounces@lists.01.org] On Behalf Of
> Yao,
> > Jiewen
> > Sent: Saturday, June 30, 2018 3:28 AM
> > To: Rafael Machado <rafaelrodrigues.machado@gmail.com>; edk2-
> > devel@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-bounces@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 Start End # Pages
> > > Attributes
> > > BS_Code 0000000000000000-0000000000000FFF 0000000000000001
> > > 000000000000000F
> > > BS_Data 0000000000001000-0000000000001FFF 0000000000000001
> > > 000000000000000F
> > > BS_Code 0000000000002000-000000000000BFFF 000000000000000A
> > > 000000000000000F
> > > Available 000000000000C000-0000000000057FFF 000000000000004C
> > > 000000000000000F
> > > Reserved 0000000000058000-0000000000058FFF 0000000000000001
> > > 000000000000000F
> > > Available 0000000000059000-0000000000069FFF 0000000000000011
> > > 000000000000000F
> > > BS_Data 000000000006A000-000000000006AFFF 0000000000000001
> > > 000000000000000F
> > > BS_Code 000000000006B000-000000000008BFFF 0000000000000021
> > > 000000000000000F
> > > Reserved 000000000008C000-000000000009FFFF 0000000000000014
> > > 000000000000000F
> > > BS_Code 0000000000100000-000000000010FFFF 0000000000000010
> > > 000000000000000F
> > > Available 0000000000110000-000000004D684FFF 000000000004D575
> > > 000000000000000F
> > > BS_Data 000000004D685000-000000004D6A4FFF 0000000000000020
> > > 000000000000000F
> > > Available 000000004D6A5000-000000004E34EFFF 0000000000000CAA
> > > 000000000000000F LoaderCode 000000004E34F000-000000004E42CFFF
> > > 00000000000000DE 000000000000000F
> > > BS_Data 000000004E42D000-0000000050510FFF 00000000000020E4
> > > 000000000000000F
> > > ACPI_NVS 0000000050511000-0000000050511FFF 0000000000000001
> > > 000000000000000F
> > > RT_Data 0000000050512000-0000000050512FFF 0000000000000001
> > > 800000000000000F
> > > BS_Data 0000000050513000-0000000050673FFF 0000000000000161
> > > 000000000000000F
> > > BS_Code 0000000050674000-0000000050674FFF 0000000000000001
> > > 000000000000000F
> > > Available 0000000050675000-0000000052B6EFFF 00000000000024FA
> > > 000000000000000F
> > > BS_Data 0000000052B6F000-0000000053572FFF 0000000000000A04
> > > 000000000000000F
> > > Available 0000000053573000-0000000053834FFF 00000000000002C2
> > > 000000000000000F
> > > BS_Data 0000000053835000-0000000053A0DFFF 00000000000001D9
> > > 000000000000000F
> > > Available 0000000053A0E000-0000000053A64FFF 0000000000000057
> > > 000000000000000F
> > > BS_Data 0000000053A65000-0000000054778FFF 0000000000000D14
> > > 000000000000000F
> > > Available 0000000054779000-0000000054785FFF 000000000000000D
> > > 000000000000000F
> > > BS_Data 0000000054786000-00000000547CAFFF 0000000000000045
> > > 000000000000000F
> > > Available 00000000547CB000-00000000547D3FFF 0000000000000009
> > > 000000000000000F
> > > BS_Data 00000000547D4000-000000005481DFFF 000000000000004A
> > > 000000000000000F
> > > Available 000000005481E000-000000005481FFFF 0000000000000002
> > > 000000000000000F
> > > BS_Data 0000000054820000-0000000056683FFF 0000000000001E64
> > > 000000000000000F
> > > Available 0000000056684000-00000000590C2FFF 0000000000002A3F
> > > 000000000000000F
> > > BS_Code 00000000590C3000-0000000059E83FFF 0000000000000DC1
> > > 000000000000000F
> > > RT_Code 0000000059E84000-0000000059F4BFFF 00000000000000C8
> > > 800000000000000F
> > > RT_Data 0000000059F4C000-000000005B164FFF 0000000000001219
> > > 800000000000000F
> > > Reserved 000000005B165000-000000005B566FFF 0000000000000402
> > > 000000000000000F
> > > ACPI_NVS 000000005B567000-000000005B599FFF 0000000000000033
> > > 000000000000000F
> > > ACPI_Recl 000000005B59A000-000000005B5FEFFF 0000000000000065
> > > 000000000000000F
> > > BS_Data 000000005B5FF000-000000005B5FFFFF 0000000000000001
> > > 000000000000000F
> > > Available 0000000100000000-000000029E7FFFFF 000000000019E800
> > > 000000000000000F
> > > Reserved 00000000000A0000-00000000000FFFFF 0000000000000060
> > > 0000000000000000
> > > Reserved 000000005B600000-000000005F7FFFFF 0000000000004200
> > > 0000000000000000
> > > MMIO 00000000F0000000-00000000F7FFFFFF 0000000000008000
> > > 8000000000000001
> > > MMIO 00000000FE010000-00000000FE010FFF 0000000000000001
> > > 8000000000000001
> > >
> > > 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 Start End # Pages
> > > Attributes
> > > BS_Code 0000000000000000-0000000000000FFF 0000000000000001
> > > 000000000000000F
> > > BS_Data 0000000000001000-0000000000001FFF 0000000000000001
> > > 000000000000000F
> > > BS_Code 0000000000002000-000000000000BFFF 000000000000000A
> > > 000000000000000F
> > > Available 000000000000C000-0000000000057FFF 000000000000004C
> > > 000000000000000F
> > > Reserved 0000000000058000-0000000000058FFF 0000000000000001
> > > 000000000000000F
> > > Available 0000000000059000-0000000000069FFF 0000000000000011
> > > 000000000000000F
> > > BS_Data 000000000006A000-000000000006AFFF 0000000000000001
> > > 000000000000000F
> > > BS_Code 000000000006B000-000000000008BFFF 0000000000000021
> > > 000000000000000F
> > > Reserved 000000000008C000-000000000009FFFF 0000000000000014
> > > 000000000000000F
> > > BS_Code 0000000000100000-000000000010FFFF 0000000000000010
> > > 000000000000000F
> > > Available 0000000000110000-000000004D684FFF 000000000004D575
> > > 000000000000000F
> > > BS_Data 000000004D685000-000000004D6A4FFF 0000000000000020
> > > 000000000000000F
> > > Available 000000004D6A5000-000000004E34EFFF 0000000000000CAA
> > > 000000000000000F LoaderCode 000000004E34F000-000000004E42CFFF
> > > 00000000000000DE 000000000000000F
> > > BS_Data 000000004E42D000-0000000050510FFF 00000000000020E4
> > > 000000000000000F
> > > ACPI_NVS 0000000050511000-0000000050511FFF 0000000000000001
> > > 000000000000000F
> > > RT_Data 0000000050512000-0000000050512FFF 0000000000000001
> > > 800000000000000F
> > > BS_Data 0000000050513000-0000000050673FFF 0000000000000161
> > > 000000000000000F
> > > BS_Code 0000000050674000-0000000050674FFF 0000000000000001
> > > 000000000000000F
> > > Available 0000000050675000-0000000052384FFF 0000000000001D10
> > > 000000000000000F
> > > BS_Data 0000000052385000-0000000053572FFF 00000000000011EE
> > > 000000000000000F
> > > Available 0000000053573000-00000000535D7FFF 0000000000000065
> > > 000000000000000F
> > > BS_Data 00000000535D8000-000000005363EFFF 0000000000000067
> > > 000000000000000F
> > > Available 000000005363F000-0000000053834FFF 00000000000001F6
> > > 000000000000000F
> > > BS_Data 0000000053835000-0000000053A0DFFF 00000000000001D9
> > > 000000000000000F
> > > Available 0000000053A0E000-0000000053A64FFF 0000000000000057
> > > 000000000000000F
> > > BS_Data 0000000053A65000-0000000053F8EFFF 000000000000052A
> > > 000000000000000F
> > > Available 0000000053F8F000-0000000053F9AFFF 000000000000000C
> > > 000000000000000F
> > > BS_Data 0000000053F9B000-0000000053F9CFFF 0000000000000002
> > > 000000000000000F
> > > Available 0000000053F9D000-0000000053FA5FFF 0000000000000009
> > > 000000000000000F
> > > BS_Data 0000000053FA6000-0000000053FAAFFF 0000000000000005
> > > 000000000000000F
> > > Available 0000000053FAB000-000000005438CFFF 00000000000003E2
> > > 000000000000000F
> > > BS_Data 000000005438D000-00000000543A5FFF 0000000000000019
> > > 000000000000000F
> > > Available 00000000543A6000-0000000054416FFF 0000000000000071
> > > 000000000000000F
> > > BS_Data 0000000054417000-0000000054417FFF 0000000000000001
> > > 000000000000000F
> > > Available 0000000054418000-0000000054425FFF 000000000000000E
> > > 000000000000000F
> > > BS_Data 0000000054426000-0000000054427FFF 0000000000000002
> > > 000000000000000F
> > > Available 0000000054428000-0000000054439FFF 0000000000000012
> > > 000000000000000F
> > > BS_Data 000000005443A000-000000005443FFFF 0000000000000006
> > > 000000000000000F
> > > Available 0000000054440000-000000005444FFFF 0000000000000010
> > > 000000000000000F
> > > BS_Data 0000000054450000-0000000054454FFF 0000000000000005
> > > 000000000000000F
> > > Available 0000000054455000-0000000054458FFF 0000000000000004
> > > 000000000000000F
> > > BS_Data 0000000054459000-000000005445BFFF 0000000000000003
> > > 000000000000000F
> > > Available 000000005445C000-0000000054467FFF 000000000000000C
> > > 000000000000000F
> > > BS_Data 0000000054468000-000000005446BFFF 0000000000000004
> > > 000000000000000F
> > > Available 000000005446C000-000000005446FFFF 0000000000000004
> > > 000000000000000F
> > > BS_Data 0000000054470000-0000000054470FFF 0000000000000001
> > > 000000000000000F
> > > Available 0000000054471000-0000000054471FFF 0000000000000001
> > > 000000000000000F
> > > BS_Data 0000000054472000-0000000054474FFF 0000000000000003
> > > 000000000000000F
> > > Available 0000000054475000-0000000054490FFF 000000000000001C
> > > 000000000000000F
> > > BS_Data 0000000054491000-0000000054494FFF 0000000000000004
> > > 000000000000000F
> > > Available 0000000054495000-00000000544ABFFF 0000000000000017
> > > 000000000000000F
> > > BS_Data 00000000544AC000-00000000544ACFFF 0000000000000001
> > > 000000000000000F
> > > Available 00000000544AD000-00000000544CCFFF 0000000000000020
> > > 000000000000000F
> > > BS_Data 00000000544CD000-00000000544CFFFF 0000000000000003
> > > 000000000000000F
> > > Available 00000000544D0000-00000000544E1FFF 0000000000000012
> > > 000000000000000F
> > > BS_Data 00000000544E2000-000000005450CFFF 000000000000002B
> > > 000000000000000F
> > > Available 000000005450D000-000000005451DFFF 0000000000000011
> > > 000000000000000F
> > > BS_Data 000000005451E000-000000005451EFFF 0000000000000001
> > > 000000000000000F
> > > Available 000000005451F000-0000000054535FFF 0000000000000017
> > > 000000000000000F
> > > BS_Data 0000000054536000-0000000054536FFF 0000000000000001
> > > 000000000000000F
> > > Available 0000000054537000-000000005453EFFF 0000000000000008
> > > 000000000000000F
> > > BS_Data 000000005453F000-0000000054543FFF 0000000000000005
> > > 000000000000000F
> > > Available 0000000054544000-0000000054579FFF 0000000000000036
> > > 000000000000000F
> > > BS_Data 000000005457A000-0000000054585FFF 000000000000000C
> > > 000000000000000F
> > > Available 0000000054586000-0000000054589FFF 0000000000000004
> > > 000000000000000F
> > > BS_Data 000000005458A000-000000005458CFFF 0000000000000003
> > > 000000000000000F
> > > Available 000000005458D000-000000005459DFFF 0000000000000011
> > > 000000000000000F
> > > BS_Data 000000005459E000-000000005459EFFF 0000000000000001
> > > 000000000000000F
> > > Available 000000005459F000-00000000545A1FFF 0000000000000003
> > > 000000000000000F
> > > BS_Data 00000000545A2000-00000000545A2FFF 0000000000000001
> > > 000000000000000F
> > > Available 00000000545A3000-00000000545A7FFF 0000000000000005
> > > 000000000000000F
> > > BS_Data 00000000545A8000-00000000545A9FFF 0000000000000002
> > > 000000000000000F
> > > Available 00000000545AA000-0000000054756FFF 00000000000001AD
> > > 000000000000000F
> > > BS_Data 0000000054757000-000000005477EFFF 0000000000000028
> > > 000000000000000F
> > > Available 000000005477F000-0000000054780FFF 0000000000000002
> > > 000000000000000F
> > > BS_Data 0000000054781000-0000000054785FFF 0000000000000005
> > > 000000000000000F
> > > Available 0000000054786000-0000000054789FFF 0000000000000004
> > > 000000000000000F
> > > BS_Data 000000005478A000-00000000547CBFFF 0000000000000042
> > > 000000000000000F
> > > Available 00000000547CC000-00000000547CEFFF 0000000000000003
> > > 000000000000000F
> > > BS_Data 00000000547CF000-00000000547D3FFF 0000000000000005
> > > 000000000000000F
> > > Available 00000000547D4000-00000000547E7FFF 0000000000000014
> > > 000000000000000F
> > > BS_Data 00000000547E8000-00000000547F4FFF 000000000000000D
> > > 000000000000000F
> > > Available 00000000547F5000-00000000547FBFFF 0000000000000007
> > > 000000000000000F
> > > BS_Data 00000000547FC000-000000005481EFFF 0000000000000023
> > > 000000000000000F
> > > Available 000000005481F000-000000005481FFFF 0000000000000001
> > > 000000000000000F
> > > BS_Data 0000000054820000-0000000054828FFF 0000000000000009
> > > 000000000000000F
> > > Available 0000000054829000-0000000054829FFF 0000000000000001
> > > 000000000000000F
> > > BS_Data 000000005482A000-0000000054CFAFFF 00000000000004D1
> > > 000000000000000F
> > > Available 0000000054CFB000-0000000054CFCFFF 0000000000000002
> > > 000000000000000F
> > > BS_Data 0000000054CFD000-0000000055269FFF 000000000000056D
> > > 000000000000000F
> > > Available 000000005526A000-000000005526EFFF 0000000000000005
> > > 000000000000000F
> > > BS_Data 000000005526F000-0000000056683FFF 0000000000001415
> > > 000000000000000F
> > > Available 0000000056684000-00000000590C2FFF 0000000000002A3F
> > > 000000000000000F
> > > BS_Code 00000000590C3000-0000000059E83FFF 0000000000000DC1
> > > 000000000000000F
> > > RT_Code 0000000059E84000-0000000059F4BFFF 00000000000000C8
> > > 800000000000000F
> > > RT_Data 0000000059F4C000-000000005B164FFF 0000000000001219
> > > 800000000000000F
> > > Reserved 000000005B165000-000000005B566FFF 0000000000000402
> > > 000000000000000F
> > > ACPI_NVS 000000005B567000-000000005B599FFF 0000000000000033
> > > 000000000000000F
> > > ACPI_Recl 000000005B59A000-000000005B5FEFFF 0000000000000065
> > > 000000000000000F
> > > BS_Data 000000005B5FF000-000000005B5FFFFF 0000000000000001
> > > 000000000000000F
> > > Available 0000000100000000-000000029E7FFFFF 000000000019E800
> > > 000000000000000F
> > > Reserved 00000000000A0000-00000000000FFFFF 0000000000000060
> > > 0000000000000000
> > > Reserved 000000005B600000-000000005F7FFFFF 0000000000004200
> > > 0000000000000000
> > > MMIO 00000000F0000000-00000000F7FFFFFF 0000000000008000
> > > 8000000000000001
> > > MMIO 00000000FE010000-00000000FE010FFF 0000000000000001
> > > 8000000000000001
> > >
> > > 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,366 Pages (95,707,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,038,764 Pages (8,350,777,344 Bytes)
> > > --------------
> > > Total Memory: 8,089 MB (8,482,492,416 Bytes)
> > >
> > >
> > > I would like to understand better what causes these entries to be
> created.
> > > We already checked and there is no memory leak at the code.
> > > What causes these entries to be created?
> > > Can this increase on the memory map entries represent a risk of
> > > hanging the system at the subsequent boot?
> > >
> > > Thanks and Regards
> > > Rafael R. Machado
> > > _______________________________________________
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org
> > > https://lists.01.org/mailman/listinfo/edk2-devel
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Question about memory map entries
2018-06-30 12:02 ` Rafael Machado
@ 2018-06-30 19:23 ` Andrew Fish
2018-08-02 12:39 ` Rafael Machado
0 siblings, 1 reply; 19+ messages in thread
From: Andrew Fish @ 2018-06-30 19:23 UTC (permalink / raw)
To: Rafael Machado; +Cc: Ni, Ruiyu, edk2-devel@lists.01.org, Yao, Jiewen
> On Jun 30, 2018, at 5:02 AM, Rafael Machado <rafaelrodrigues.machado@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
>
> Thanks and Regards
> Rafael R. Machado
>
> Em sex, 29 de jun de 2018 às 22:31, Ni, Ruiyu <ruiyu.ni@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-bounces@lists.01.org] On Behalf Of
>> Yao,
>>> Jiewen
>>> Sent: Saturday, June 30, 2018 3:28 AM
>>> To: Rafael Machado <rafaelrodrigues.machado@gmail.com>; edk2-
>>> devel@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-bounces@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 Start End # Pages
>>>> Attributes
>>>> BS_Code 0000000000000000-0000000000000FFF 0000000000000001
>>>> 000000000000000F
>>>> BS_Data 0000000000001000-0000000000001FFF 0000000000000001
>>>> 000000000000000F
>>>> BS_Code 0000000000002000-000000000000BFFF 000000000000000A
>>>> 000000000000000F
>>>> Available 000000000000C000-0000000000057FFF 000000000000004C
>>>> 000000000000000F
>>>> Reserved 0000000000058000-0000000000058FFF 0000000000000001
>>>> 000000000000000F
>>>> Available 0000000000059000-0000000000069FFF 0000000000000011
>>>> 000000000000000F
>>>> BS_Data 000000000006A000-000000000006AFFF 0000000000000001
>>>> 000000000000000F
>>>> BS_Code 000000000006B000-000000000008BFFF 0000000000000021
>>>> 000000000000000F
>>>> Reserved 000000000008C000-000000000009FFFF 0000000000000014
>>>> 000000000000000F
>>>> BS_Code 0000000000100000-000000000010FFFF 0000000000000010
>>>> 000000000000000F
>>>> Available 0000000000110000-000000004D684FFF 000000000004D575
>>>> 000000000000000F
>>>> BS_Data 000000004D685000-000000004D6A4FFF 0000000000000020
>>>> 000000000000000F
>>>> Available 000000004D6A5000-000000004E34EFFF 0000000000000CAA
>>>> 000000000000000F LoaderCode 000000004E34F000-000000004E42CFFF
>>>> 00000000000000DE 000000000000000F
>>>> BS_Data 000000004E42D000-0000000050510FFF 00000000000020E4
>>>> 000000000000000F
>>>> ACPI_NVS 0000000050511000-0000000050511FFF 0000000000000001
>>>> 000000000000000F
>>>> RT_Data 0000000050512000-0000000050512FFF 0000000000000001
>>>> 800000000000000F
>>>> BS_Data 0000000050513000-0000000050673FFF 0000000000000161
>>>> 000000000000000F
>>>> BS_Code 0000000050674000-0000000050674FFF 0000000000000001
>>>> 000000000000000F
>>>> Available 0000000050675000-0000000052B6EFFF 00000000000024FA
>>>> 000000000000000F
>>>> BS_Data 0000000052B6F000-0000000053572FFF 0000000000000A04
>>>> 000000000000000F
>>>> Available 0000000053573000-0000000053834FFF 00000000000002C2
>>>> 000000000000000F
>>>> BS_Data 0000000053835000-0000000053A0DFFF 00000000000001D9
>>>> 000000000000000F
>>>> Available 0000000053A0E000-0000000053A64FFF 0000000000000057
>>>> 000000000000000F
>>>> BS_Data 0000000053A65000-0000000054778FFF 0000000000000D14
>>>> 000000000000000F
>>>> Available 0000000054779000-0000000054785FFF 000000000000000D
>>>> 000000000000000F
>>>> BS_Data 0000000054786000-00000000547CAFFF 0000000000000045
>>>> 000000000000000F
>>>> Available 00000000547CB000-00000000547D3FFF 0000000000000009
>>>> 000000000000000F
>>>> BS_Data 00000000547D4000-000000005481DFFF 000000000000004A
>>>> 000000000000000F
>>>> Available 000000005481E000-000000005481FFFF 0000000000000002
>>>> 000000000000000F
>>>> BS_Data 0000000054820000-0000000056683FFF 0000000000001E64
>>>> 000000000000000F
>>>> Available 0000000056684000-00000000590C2FFF 0000000000002A3F
>>>> 000000000000000F
>>>> BS_Code 00000000590C3000-0000000059E83FFF 0000000000000DC1
>>>> 000000000000000F
>>>> RT_Code 0000000059E84000-0000000059F4BFFF 00000000000000C8
>>>> 800000000000000F
>>>> RT_Data 0000000059F4C000-000000005B164FFF 0000000000001219
>>>> 800000000000000F
>>>> Reserved 000000005B165000-000000005B566FFF 0000000000000402
>>>> 000000000000000F
>>>> ACPI_NVS 000000005B567000-000000005B599FFF 0000000000000033
>>>> 000000000000000F
>>>> ACPI_Recl 000000005B59A000-000000005B5FEFFF 0000000000000065
>>>> 000000000000000F
>>>> BS_Data 000000005B5FF000-000000005B5FFFFF 0000000000000001
>>>> 000000000000000F
>>>> Available 0000000100000000-000000029E7FFFFF 000000000019E800
>>>> 000000000000000F
>>>> Reserved 00000000000A0000-00000000000FFFFF 0000000000000060
>>>> 0000000000000000
>>>> Reserved 000000005B600000-000000005F7FFFFF 0000000000004200
>>>> 0000000000000000
>>>> MMIO 00000000F0000000-00000000F7FFFFFF 0000000000008000
>>>> 8000000000000001
>>>> MMIO 00000000FE010000-00000000FE010FFF 0000000000000001
>>>> 8000000000000001
>>>>
>>>> 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 Start End # Pages
>>>> Attributes
>>>> BS_Code 0000000000000000-0000000000000FFF 0000000000000001
>>>> 000000000000000F
>>>> BS_Data 0000000000001000-0000000000001FFF 0000000000000001
>>>> 000000000000000F
>>>> BS_Code 0000000000002000-000000000000BFFF 000000000000000A
>>>> 000000000000000F
>>>> Available 000000000000C000-0000000000057FFF 000000000000004C
>>>> 000000000000000F
>>>> Reserved 0000000000058000-0000000000058FFF 0000000000000001
>>>> 000000000000000F
>>>> Available 0000000000059000-0000000000069FFF 0000000000000011
>>>> 000000000000000F
>>>> BS_Data 000000000006A000-000000000006AFFF 0000000000000001
>>>> 000000000000000F
>>>> BS_Code 000000000006B000-000000000008BFFF 0000000000000021
>>>> 000000000000000F
>>>> Reserved 000000000008C000-000000000009FFFF 0000000000000014
>>>> 000000000000000F
>>>> BS_Code 0000000000100000-000000000010FFFF 0000000000000010
>>>> 000000000000000F
>>>> Available 0000000000110000-000000004D684FFF 000000000004D575
>>>> 000000000000000F
>>>> BS_Data 000000004D685000-000000004D6A4FFF 0000000000000020
>>>> 000000000000000F
>>>> Available 000000004D6A5000-000000004E34EFFF 0000000000000CAA
>>>> 000000000000000F LoaderCode 000000004E34F000-000000004E42CFFF
>>>> 00000000000000DE 000000000000000F
>>>> BS_Data 000000004E42D000-0000000050510FFF 00000000000020E4
>>>> 000000000000000F
>>>> ACPI_NVS 0000000050511000-0000000050511FFF 0000000000000001
>>>> 000000000000000F
>>>> RT_Data 0000000050512000-0000000050512FFF 0000000000000001
>>>> 800000000000000F
>>>> BS_Data 0000000050513000-0000000050673FFF 0000000000000161
>>>> 000000000000000F
>>>> BS_Code 0000000050674000-0000000050674FFF 0000000000000001
>>>> 000000000000000F
>>>> Available 0000000050675000-0000000052384FFF 0000000000001D10
>>>> 000000000000000F
>>>> BS_Data 0000000052385000-0000000053572FFF 00000000000011EE
>>>> 000000000000000F
>>>> Available 0000000053573000-00000000535D7FFF 0000000000000065
>>>> 000000000000000F
>>>> BS_Data 00000000535D8000-000000005363EFFF 0000000000000067
>>>> 000000000000000F
>>>> Available 000000005363F000-0000000053834FFF 00000000000001F6
>>>> 000000000000000F
>>>> BS_Data 0000000053835000-0000000053A0DFFF 00000000000001D9
>>>> 000000000000000F
>>>> Available 0000000053A0E000-0000000053A64FFF 0000000000000057
>>>> 000000000000000F
>>>> BS_Data 0000000053A65000-0000000053F8EFFF 000000000000052A
>>>> 000000000000000F
>>>> Available 0000000053F8F000-0000000053F9AFFF 000000000000000C
>>>> 000000000000000F
>>>> BS_Data 0000000053F9B000-0000000053F9CFFF 0000000000000002
>>>> 000000000000000F
>>>> Available 0000000053F9D000-0000000053FA5FFF 0000000000000009
>>>> 000000000000000F
>>>> BS_Data 0000000053FA6000-0000000053FAAFFF 0000000000000005
>>>> 000000000000000F
>>>> Available 0000000053FAB000-000000005438CFFF 00000000000003E2
>>>> 000000000000000F
>>>> BS_Data 000000005438D000-00000000543A5FFF 0000000000000019
>>>> 000000000000000F
>>>> Available 00000000543A6000-0000000054416FFF 0000000000000071
>>>> 000000000000000F
>>>> BS_Data 0000000054417000-0000000054417FFF 0000000000000001
>>>> 000000000000000F
>>>> Available 0000000054418000-0000000054425FFF 000000000000000E
>>>> 000000000000000F
>>>> BS_Data 0000000054426000-0000000054427FFF 0000000000000002
>>>> 000000000000000F
>>>> Available 0000000054428000-0000000054439FFF 0000000000000012
>>>> 000000000000000F
>>>> BS_Data 000000005443A000-000000005443FFFF 0000000000000006
>>>> 000000000000000F
>>>> Available 0000000054440000-000000005444FFFF 0000000000000010
>>>> 000000000000000F
>>>> BS_Data 0000000054450000-0000000054454FFF 0000000000000005
>>>> 000000000000000F
>>>> Available 0000000054455000-0000000054458FFF 0000000000000004
>>>> 000000000000000F
>>>> BS_Data 0000000054459000-000000005445BFFF 0000000000000003
>>>> 000000000000000F
>>>> Available 000000005445C000-0000000054467FFF 000000000000000C
>>>> 000000000000000F
>>>> BS_Data 0000000054468000-000000005446BFFF 0000000000000004
>>>> 000000000000000F
>>>> Available 000000005446C000-000000005446FFFF 0000000000000004
>>>> 000000000000000F
>>>> BS_Data 0000000054470000-0000000054470FFF 0000000000000001
>>>> 000000000000000F
>>>> Available 0000000054471000-0000000054471FFF 0000000000000001
>>>> 000000000000000F
>>>> BS_Data 0000000054472000-0000000054474FFF 0000000000000003
>>>> 000000000000000F
>>>> Available 0000000054475000-0000000054490FFF 000000000000001C
>>>> 000000000000000F
>>>> BS_Data 0000000054491000-0000000054494FFF 0000000000000004
>>>> 000000000000000F
>>>> Available 0000000054495000-00000000544ABFFF 0000000000000017
>>>> 000000000000000F
>>>> BS_Data 00000000544AC000-00000000544ACFFF 0000000000000001
>>>> 000000000000000F
>>>> Available 00000000544AD000-00000000544CCFFF 0000000000000020
>>>> 000000000000000F
>>>> BS_Data 00000000544CD000-00000000544CFFFF 0000000000000003
>>>> 000000000000000F
>>>> Available 00000000544D0000-00000000544E1FFF 0000000000000012
>>>> 000000000000000F
>>>> BS_Data 00000000544E2000-000000005450CFFF 000000000000002B
>>>> 000000000000000F
>>>> Available 000000005450D000-000000005451DFFF 0000000000000011
>>>> 000000000000000F
>>>> BS_Data 000000005451E000-000000005451EFFF 0000000000000001
>>>> 000000000000000F
>>>> Available 000000005451F000-0000000054535FFF 0000000000000017
>>>> 000000000000000F
>>>> BS_Data 0000000054536000-0000000054536FFF 0000000000000001
>>>> 000000000000000F
>>>> Available 0000000054537000-000000005453EFFF 0000000000000008
>>>> 000000000000000F
>>>> BS_Data 000000005453F000-0000000054543FFF 0000000000000005
>>>> 000000000000000F
>>>> Available 0000000054544000-0000000054579FFF 0000000000000036
>>>> 000000000000000F
>>>> BS_Data 000000005457A000-0000000054585FFF 000000000000000C
>>>> 000000000000000F
>>>> Available 0000000054586000-0000000054589FFF 0000000000000004
>>>> 000000000000000F
>>>> BS_Data 000000005458A000-000000005458CFFF 0000000000000003
>>>> 000000000000000F
>>>> Available 000000005458D000-000000005459DFFF 0000000000000011
>>>> 000000000000000F
>>>> BS_Data 000000005459E000-000000005459EFFF 0000000000000001
>>>> 000000000000000F
>>>> Available 000000005459F000-00000000545A1FFF 0000000000000003
>>>> 000000000000000F
>>>> BS_Data 00000000545A2000-00000000545A2FFF 0000000000000001
>>>> 000000000000000F
>>>> Available 00000000545A3000-00000000545A7FFF 0000000000000005
>>>> 000000000000000F
>>>> BS_Data 00000000545A8000-00000000545A9FFF 0000000000000002
>>>> 000000000000000F
>>>> Available 00000000545AA000-0000000054756FFF 00000000000001AD
>>>> 000000000000000F
>>>> BS_Data 0000000054757000-000000005477EFFF 0000000000000028
>>>> 000000000000000F
>>>> Available 000000005477F000-0000000054780FFF 0000000000000002
>>>> 000000000000000F
>>>> BS_Data 0000000054781000-0000000054785FFF 0000000000000005
>>>> 000000000000000F
>>>> Available 0000000054786000-0000000054789FFF 0000000000000004
>>>> 000000000000000F
>>>> BS_Data 000000005478A000-00000000547CBFFF 0000000000000042
>>>> 000000000000000F
>>>> Available 00000000547CC000-00000000547CEFFF 0000000000000003
>>>> 000000000000000F
>>>> BS_Data 00000000547CF000-00000000547D3FFF 0000000000000005
>>>> 000000000000000F
>>>> Available 00000000547D4000-00000000547E7FFF 0000000000000014
>>>> 000000000000000F
>>>> BS_Data 00000000547E8000-00000000547F4FFF 000000000000000D
>>>> 000000000000000F
>>>> Available 00000000547F5000-00000000547FBFFF 0000000000000007
>>>> 000000000000000F
>>>> BS_Data 00000000547FC000-000000005481EFFF 0000000000000023
>>>> 000000000000000F
>>>> Available 000000005481F000-000000005481FFFF 0000000000000001
>>>> 000000000000000F
>>>> BS_Data 0000000054820000-0000000054828FFF 0000000000000009
>>>> 000000000000000F
>>>> Available 0000000054829000-0000000054829FFF 0000000000000001
>>>> 000000000000000F
>>>> BS_Data 000000005482A000-0000000054CFAFFF 00000000000004D1
>>>> 000000000000000F
>>>> Available 0000000054CFB000-0000000054CFCFFF 0000000000000002
>>>> 000000000000000F
>>>> BS_Data 0000000054CFD000-0000000055269FFF 000000000000056D
>>>> 000000000000000F
>>>> Available 000000005526A000-000000005526EFFF 0000000000000005
>>>> 000000000000000F
>>>> BS_Data 000000005526F000-0000000056683FFF 0000000000001415
>>>> 000000000000000F
>>>> Available 0000000056684000-00000000590C2FFF 0000000000002A3F
>>>> 000000000000000F
>>>> BS_Code 00000000590C3000-0000000059E83FFF 0000000000000DC1
>>>> 000000000000000F
>>>> RT_Code 0000000059E84000-0000000059F4BFFF 00000000000000C8
>>>> 800000000000000F
>>>> RT_Data 0000000059F4C000-000000005B164FFF 0000000000001219
>>>> 800000000000000F
>>>> Reserved 000000005B165000-000000005B566FFF 0000000000000402
>>>> 000000000000000F
>>>> ACPI_NVS 000000005B567000-000000005B599FFF 0000000000000033
>>>> 000000000000000F
>>>> ACPI_Recl 000000005B59A000-000000005B5FEFFF 0000000000000065
>>>> 000000000000000F
>>>> BS_Data 000000005B5FF000-000000005B5FFFFF 0000000000000001
>>>> 000000000000000F
>>>> Available 0000000100000000-000000029E7FFFFF 000000000019E800
>>>> 000000000000000F
>>>> Reserved 00000000000A0000-00000000000FFFFF 0000000000000060
>>>> 0000000000000000
>>>> Reserved 000000005B600000-000000005F7FFFFF 0000000000004200
>>>> 0000000000000000
>>>> MMIO 00000000F0000000-00000000F7FFFFFF 0000000000008000
>>>> 8000000000000001
>>>> MMIO 00000000FE010000-00000000FE010FFF 0000000000000001
>>>> 8000000000000001
>>>>
>>>> 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,366 Pages (95,707,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,038,764 Pages (8,350,777,344 Bytes)
>>>> --------------
>>>> Total Memory: 8,089 MB (8,482,492,416 Bytes)
>>>>
>>>>
>>>> I would like to understand better what causes these entries to be
>> created.
>>>> We already checked and there is no memory leak at the code.
>>>> What causes these entries to be created?
>>>> Can this increase on the memory map entries represent a risk of
>>>> hanging the system at the subsequent boot?
>>>>
>>>> Thanks and Regards
>>>> Rafael R. Machado
>>>> _______________________________________________
>>>> edk2-devel mailing list
>>>> edk2-devel@lists.01.org
>>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>> _______________________________________________
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Question about memory map entries
2018-06-30 19:23 ` Andrew Fish
@ 2018-08-02 12:39 ` Rafael Machado
2018-08-02 14:37 ` Andrew Fish
2018-08-02 14:44 ` Laszlo Ersek
0 siblings, 2 replies; 19+ messages in thread
From: Rafael Machado @ 2018-08-02 12:39 UTC (permalink / raw)
To: Andrew Fish; +Cc: Ni, Ruiyu, edk2-devel@lists.01.org, Yao, Jiewen
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
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
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?
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.
Any ideas?
Thanks and Regards
Rafael R. Machado
Em sáb, 30 de jun de 2018 às 16:23, Andrew Fish <afish@apple.com> escreveu:
>
>
> > On Jun 30, 2018, at 5:02 AM, Rafael Machado <
> rafaelrodrigues.machado@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
> >
> > Thanks and Regards
> > Rafael R. Machado
> >
> > Em sex, 29 de jun de 2018 às 22:31, Ni, Ruiyu <ruiyu.ni@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-bounces@lists.01.org] On Behalf Of
> >> Yao,
> >>> Jiewen
> >>> Sent: Saturday, June 30, 2018 3:28 AM
> >>> To: Rafael Machado <rafaelrodrigues.machado@gmail.com>; edk2-
> >>> devel@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-bounces@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 Start End # Pages
> >>>> Attributes
> >>>> BS_Code 0000000000000000-0000000000000FFF 0000000000000001
> >>>> 000000000000000F
> >>>> BS_Data 0000000000001000-0000000000001FFF 0000000000000001
> >>>> 000000000000000F
> >>>> BS_Code 0000000000002000-000000000000BFFF 000000000000000A
> >>>> 000000000000000F
> >>>> Available 000000000000C000-0000000000057FFF 000000000000004C
> >>>> 000000000000000F
> >>>> Reserved 0000000000058000-0000000000058FFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 0000000000059000-0000000000069FFF 0000000000000011
> >>>> 000000000000000F
> >>>> BS_Data 000000000006A000-000000000006AFFF 0000000000000001
> >>>> 000000000000000F
> >>>> BS_Code 000000000006B000-000000000008BFFF 0000000000000021
> >>>> 000000000000000F
> >>>> Reserved 000000000008C000-000000000009FFFF 0000000000000014
> >>>> 000000000000000F
> >>>> BS_Code 0000000000100000-000000000010FFFF 0000000000000010
> >>>> 000000000000000F
> >>>> Available 0000000000110000-000000004D684FFF 000000000004D575
> >>>> 000000000000000F
> >>>> BS_Data 000000004D685000-000000004D6A4FFF 0000000000000020
> >>>> 000000000000000F
> >>>> Available 000000004D6A5000-000000004E34EFFF 0000000000000CAA
> >>>> 000000000000000F LoaderCode 000000004E34F000-000000004E42CFFF
> >>>> 00000000000000DE 000000000000000F
> >>>> BS_Data 000000004E42D000-0000000050510FFF 00000000000020E4
> >>>> 000000000000000F
> >>>> ACPI_NVS 0000000050511000-0000000050511FFF 0000000000000001
> >>>> 000000000000000F
> >>>> RT_Data 0000000050512000-0000000050512FFF 0000000000000001
> >>>> 800000000000000F
> >>>> BS_Data 0000000050513000-0000000050673FFF 0000000000000161
> >>>> 000000000000000F
> >>>> BS_Code 0000000050674000-0000000050674FFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 0000000050675000-0000000052B6EFFF 00000000000024FA
> >>>> 000000000000000F
> >>>> BS_Data 0000000052B6F000-0000000053572FFF 0000000000000A04
> >>>> 000000000000000F
> >>>> Available 0000000053573000-0000000053834FFF 00000000000002C2
> >>>> 000000000000000F
> >>>> BS_Data 0000000053835000-0000000053A0DFFF 00000000000001D9
> >>>> 000000000000000F
> >>>> Available 0000000053A0E000-0000000053A64FFF 0000000000000057
> >>>> 000000000000000F
> >>>> BS_Data 0000000053A65000-0000000054778FFF 0000000000000D14
> >>>> 000000000000000F
> >>>> Available 0000000054779000-0000000054785FFF 000000000000000D
> >>>> 000000000000000F
> >>>> BS_Data 0000000054786000-00000000547CAFFF 0000000000000045
> >>>> 000000000000000F
> >>>> Available 00000000547CB000-00000000547D3FFF 0000000000000009
> >>>> 000000000000000F
> >>>> BS_Data 00000000547D4000-000000005481DFFF 000000000000004A
> >>>> 000000000000000F
> >>>> Available 000000005481E000-000000005481FFFF 0000000000000002
> >>>> 000000000000000F
> >>>> BS_Data 0000000054820000-0000000056683FFF 0000000000001E64
> >>>> 000000000000000F
> >>>> Available 0000000056684000-00000000590C2FFF 0000000000002A3F
> >>>> 000000000000000F
> >>>> BS_Code 00000000590C3000-0000000059E83FFF 0000000000000DC1
> >>>> 000000000000000F
> >>>> RT_Code 0000000059E84000-0000000059F4BFFF 00000000000000C8
> >>>> 800000000000000F
> >>>> RT_Data 0000000059F4C000-000000005B164FFF 0000000000001219
> >>>> 800000000000000F
> >>>> Reserved 000000005B165000-000000005B566FFF 0000000000000402
> >>>> 000000000000000F
> >>>> ACPI_NVS 000000005B567000-000000005B599FFF 0000000000000033
> >>>> 000000000000000F
> >>>> ACPI_Recl 000000005B59A000-000000005B5FEFFF 0000000000000065
> >>>> 000000000000000F
> >>>> BS_Data 000000005B5FF000-000000005B5FFFFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 0000000100000000-000000029E7FFFFF 000000000019E800
> >>>> 000000000000000F
> >>>> Reserved 00000000000A0000-00000000000FFFFF 0000000000000060
> >>>> 0000000000000000
> >>>> Reserved 000000005B600000-000000005F7FFFFF 0000000000004200
> >>>> 0000000000000000
> >>>> MMIO 00000000F0000000-00000000F7FFFFFF 0000000000008000
> >>>> 8000000000000001
> >>>> MMIO 00000000FE010000-00000000FE010FFF 0000000000000001
> >>>> 8000000000000001
> >>>>
> >>>> 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 Start End # Pages
> >>>> Attributes
> >>>> BS_Code 0000000000000000-0000000000000FFF 0000000000000001
> >>>> 000000000000000F
> >>>> BS_Data 0000000000001000-0000000000001FFF 0000000000000001
> >>>> 000000000000000F
> >>>> BS_Code 0000000000002000-000000000000BFFF 000000000000000A
> >>>> 000000000000000F
> >>>> Available 000000000000C000-0000000000057FFF 000000000000004C
> >>>> 000000000000000F
> >>>> Reserved 0000000000058000-0000000000058FFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 0000000000059000-0000000000069FFF 0000000000000011
> >>>> 000000000000000F
> >>>> BS_Data 000000000006A000-000000000006AFFF 0000000000000001
> >>>> 000000000000000F
> >>>> BS_Code 000000000006B000-000000000008BFFF 0000000000000021
> >>>> 000000000000000F
> >>>> Reserved 000000000008C000-000000000009FFFF 0000000000000014
> >>>> 000000000000000F
> >>>> BS_Code 0000000000100000-000000000010FFFF 0000000000000010
> >>>> 000000000000000F
> >>>> Available 0000000000110000-000000004D684FFF 000000000004D575
> >>>> 000000000000000F
> >>>> BS_Data 000000004D685000-000000004D6A4FFF 0000000000000020
> >>>> 000000000000000F
> >>>> Available 000000004D6A5000-000000004E34EFFF 0000000000000CAA
> >>>> 000000000000000F LoaderCode 000000004E34F000-000000004E42CFFF
> >>>> 00000000000000DE 000000000000000F
> >>>> BS_Data 000000004E42D000-0000000050510FFF 00000000000020E4
> >>>> 000000000000000F
> >>>> ACPI_NVS 0000000050511000-0000000050511FFF 0000000000000001
> >>>> 000000000000000F
> >>>> RT_Data 0000000050512000-0000000050512FFF 0000000000000001
> >>>> 800000000000000F
> >>>> BS_Data 0000000050513000-0000000050673FFF 0000000000000161
> >>>> 000000000000000F
> >>>> BS_Code 0000000050674000-0000000050674FFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 0000000050675000-0000000052384FFF 0000000000001D10
> >>>> 000000000000000F
> >>>> BS_Data 0000000052385000-0000000053572FFF 00000000000011EE
> >>>> 000000000000000F
> >>>> Available 0000000053573000-00000000535D7FFF 0000000000000065
> >>>> 000000000000000F
> >>>> BS_Data 00000000535D8000-000000005363EFFF 0000000000000067
> >>>> 000000000000000F
> >>>> Available 000000005363F000-0000000053834FFF 00000000000001F6
> >>>> 000000000000000F
> >>>> BS_Data 0000000053835000-0000000053A0DFFF 00000000000001D9
> >>>> 000000000000000F
> >>>> Available 0000000053A0E000-0000000053A64FFF 0000000000000057
> >>>> 000000000000000F
> >>>> BS_Data 0000000053A65000-0000000053F8EFFF 000000000000052A
> >>>> 000000000000000F
> >>>> Available 0000000053F8F000-0000000053F9AFFF 000000000000000C
> >>>> 000000000000000F
> >>>> BS_Data 0000000053F9B000-0000000053F9CFFF 0000000000000002
> >>>> 000000000000000F
> >>>> Available 0000000053F9D000-0000000053FA5FFF 0000000000000009
> >>>> 000000000000000F
> >>>> BS_Data 0000000053FA6000-0000000053FAAFFF 0000000000000005
> >>>> 000000000000000F
> >>>> Available 0000000053FAB000-000000005438CFFF 00000000000003E2
> >>>> 000000000000000F
> >>>> BS_Data 000000005438D000-00000000543A5FFF 0000000000000019
> >>>> 000000000000000F
> >>>> Available 00000000543A6000-0000000054416FFF 0000000000000071
> >>>> 000000000000000F
> >>>> BS_Data 0000000054417000-0000000054417FFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 0000000054418000-0000000054425FFF 000000000000000E
> >>>> 000000000000000F
> >>>> BS_Data 0000000054426000-0000000054427FFF 0000000000000002
> >>>> 000000000000000F
> >>>> Available 0000000054428000-0000000054439FFF 0000000000000012
> >>>> 000000000000000F
> >>>> BS_Data 000000005443A000-000000005443FFFF 0000000000000006
> >>>> 000000000000000F
> >>>> Available 0000000054440000-000000005444FFFF 0000000000000010
> >>>> 000000000000000F
> >>>> BS_Data 0000000054450000-0000000054454FFF 0000000000000005
> >>>> 000000000000000F
> >>>> Available 0000000054455000-0000000054458FFF 0000000000000004
> >>>> 000000000000000F
> >>>> BS_Data 0000000054459000-000000005445BFFF 0000000000000003
> >>>> 000000000000000F
> >>>> Available 000000005445C000-0000000054467FFF 000000000000000C
> >>>> 000000000000000F
> >>>> BS_Data 0000000054468000-000000005446BFFF 0000000000000004
> >>>> 000000000000000F
> >>>> Available 000000005446C000-000000005446FFFF 0000000000000004
> >>>> 000000000000000F
> >>>> BS_Data 0000000054470000-0000000054470FFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 0000000054471000-0000000054471FFF 0000000000000001
> >>>> 000000000000000F
> >>>> BS_Data 0000000054472000-0000000054474FFF 0000000000000003
> >>>> 000000000000000F
> >>>> Available 0000000054475000-0000000054490FFF 000000000000001C
> >>>> 000000000000000F
> >>>> BS_Data 0000000054491000-0000000054494FFF 0000000000000004
> >>>> 000000000000000F
> >>>> Available 0000000054495000-00000000544ABFFF 0000000000000017
> >>>> 000000000000000F
> >>>> BS_Data 00000000544AC000-00000000544ACFFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 00000000544AD000-00000000544CCFFF 0000000000000020
> >>>> 000000000000000F
> >>>> BS_Data 00000000544CD000-00000000544CFFFF 0000000000000003
> >>>> 000000000000000F
> >>>> Available 00000000544D0000-00000000544E1FFF 0000000000000012
> >>>> 000000000000000F
> >>>> BS_Data 00000000544E2000-000000005450CFFF 000000000000002B
> >>>> 000000000000000F
> >>>> Available 000000005450D000-000000005451DFFF 0000000000000011
> >>>> 000000000000000F
> >>>> BS_Data 000000005451E000-000000005451EFFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 000000005451F000-0000000054535FFF 0000000000000017
> >>>> 000000000000000F
> >>>> BS_Data 0000000054536000-0000000054536FFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 0000000054537000-000000005453EFFF 0000000000000008
> >>>> 000000000000000F
> >>>> BS_Data 000000005453F000-0000000054543FFF 0000000000000005
> >>>> 000000000000000F
> >>>> Available 0000000054544000-0000000054579FFF 0000000000000036
> >>>> 000000000000000F
> >>>> BS_Data 000000005457A000-0000000054585FFF 000000000000000C
> >>>> 000000000000000F
> >>>> Available 0000000054586000-0000000054589FFF 0000000000000004
> >>>> 000000000000000F
> >>>> BS_Data 000000005458A000-000000005458CFFF 0000000000000003
> >>>> 000000000000000F
> >>>> Available 000000005458D000-000000005459DFFF 0000000000000011
> >>>> 000000000000000F
> >>>> BS_Data 000000005459E000-000000005459EFFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 000000005459F000-00000000545A1FFF 0000000000000003
> >>>> 000000000000000F
> >>>> BS_Data 00000000545A2000-00000000545A2FFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 00000000545A3000-00000000545A7FFF 0000000000000005
> >>>> 000000000000000F
> >>>> BS_Data 00000000545A8000-00000000545A9FFF 0000000000000002
> >>>> 000000000000000F
> >>>> Available 00000000545AA000-0000000054756FFF 00000000000001AD
> >>>> 000000000000000F
> >>>> BS_Data 0000000054757000-000000005477EFFF 0000000000000028
> >>>> 000000000000000F
> >>>> Available 000000005477F000-0000000054780FFF 0000000000000002
> >>>> 000000000000000F
> >>>> BS_Data 0000000054781000-0000000054785FFF 0000000000000005
> >>>> 000000000000000F
> >>>> Available 0000000054786000-0000000054789FFF 0000000000000004
> >>>> 000000000000000F
> >>>> BS_Data 000000005478A000-00000000547CBFFF 0000000000000042
> >>>> 000000000000000F
> >>>> Available 00000000547CC000-00000000547CEFFF 0000000000000003
> >>>> 000000000000000F
> >>>> BS_Data 00000000547CF000-00000000547D3FFF 0000000000000005
> >>>> 000000000000000F
> >>>> Available 00000000547D4000-00000000547E7FFF 0000000000000014
> >>>> 000000000000000F
> >>>> BS_Data 00000000547E8000-00000000547F4FFF 000000000000000D
> >>>> 000000000000000F
> >>>> Available 00000000547F5000-00000000547FBFFF 0000000000000007
> >>>> 000000000000000F
> >>>> BS_Data 00000000547FC000-000000005481EFFF 0000000000000023
> >>>> 000000000000000F
> >>>> Available 000000005481F000-000000005481FFFF 0000000000000001
> >>>> 000000000000000F
> >>>> BS_Data 0000000054820000-0000000054828FFF 0000000000000009
> >>>> 000000000000000F
> >>>> Available 0000000054829000-0000000054829FFF 0000000000000001
> >>>> 000000000000000F
> >>>> BS_Data 000000005482A000-0000000054CFAFFF 00000000000004D1
> >>>> 000000000000000F
> >>>> Available 0000000054CFB000-0000000054CFCFFF 0000000000000002
> >>>> 000000000000000F
> >>>> BS_Data 0000000054CFD000-0000000055269FFF 000000000000056D
> >>>> 000000000000000F
> >>>> Available 000000005526A000-000000005526EFFF 0000000000000005
> >>>> 000000000000000F
> >>>> BS_Data 000000005526F000-0000000056683FFF 0000000000001415
> >>>> 000000000000000F
> >>>> Available 0000000056684000-00000000590C2FFF 0000000000002A3F
> >>>> 000000000000000F
> >>>> BS_Code 00000000590C3000-0000000059E83FFF 0000000000000DC1
> >>>> 000000000000000F
> >>>> RT_Code 0000000059E84000-0000000059F4BFFF 00000000000000C8
> >>>> 800000000000000F
> >>>> RT_Data 0000000059F4C000-000000005B164FFF 0000000000001219
> >>>> 800000000000000F
> >>>> Reserved 000000005B165000-000000005B566FFF 0000000000000402
> >>>> 000000000000000F
> >>>> ACPI_NVS 000000005B567000-000000005B599FFF 0000000000000033
> >>>> 000000000000000F
> >>>> ACPI_Recl 000000005B59A000-000000005B5FEFFF 0000000000000065
> >>>> 000000000000000F
> >>>> BS_Data 000000005B5FF000-000000005B5FFFFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 0000000100000000-000000029E7FFFFF 000000000019E800
> >>>> 000000000000000F
> >>>> Reserved 00000000000A0000-00000000000FFFFF 0000000000000060
> >>>> 0000000000000000
> >>>> Reserved 000000005B600000-000000005F7FFFFF 0000000000004200
> >>>> 0000000000000000
> >>>> MMIO 00000000F0000000-00000000F7FFFFFF 0000000000008000
> >>>> 8000000000000001
> >>>> MMIO 00000000FE010000-00000000FE010FFF 0000000000000001
> >>>> 8000000000000001
> >>>>
> >>>> 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,366 Pages (95,707,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,038,764 Pages (8,350,777,344 Bytes)
> >>>> --------------
> >>>> Total Memory: 8,089 MB (8,482,492,416 Bytes)
> >>>>
> >>>>
> >>>> I would like to understand better what causes these entries to be
> >> created.
> >>>> We already checked and there is no memory leak at the code.
> >>>> What causes these entries to be created?
> >>>> Can this increase on the memory map entries represent a risk of
> >>>> hanging the system at the subsequent boot?
> >>>>
> >>>> Thanks and Regards
> >>>> Rafael R. Machado
> >>>> _______________________________________________
> >>>> edk2-devel mailing list
> >>>> edk2-devel@lists.01.org
> >>>> https://lists.01.org/mailman/listinfo/edk2-devel
> >>> _______________________________________________
> >>> edk2-devel mailing list
> >>> edk2-devel@lists.01.org
> >>> https://lists.01.org/mailman/listinfo/edk2-devel
> >>
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Question about memory map entries
2018-08-02 12:39 ` Rafael Machado
@ 2018-08-02 14:37 ` Andrew Fish
2018-08-02 14:44 ` Laszlo Ersek
1 sibling, 0 replies; 19+ messages in thread
From: Andrew Fish @ 2018-08-02 14:37 UTC (permalink / raw)
To: Rafael Machado; +Cc: Ni, Ruiyu, edk2-devel@lists.01.org, Yao, Jiewen
> On Aug 2, 2018, at 5:39 AM, Rafael Machado <rafaelrodrigues.machado@gmail.com> 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#L21 <https://github.com/tianocore/edk2/blob/87acb6e298e718250dd8b741b6888a3a54c7cb5a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L21>h <https://github.com/tianocore/edk2/blob/87acb6e298e718250dd8b741b6888a3a54c7cb5a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L2199>99 <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
>
> 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
>
> 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?
>
> 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.
>
> Any ideas?
>
Rafael,
The gEfiMemoryTypeInformationGuid HOB is optional and used to defragment the EFI Memory Map. While it is copied it is not really in use at the point of your ASSERT.
The PHIT HOB[1] must be the 1st HOB entry and it is the layout of the memory that was in use by the PEI phase. At this point int he boot it is likely the memory registered in PEI via the InstallPeiMemory() PEI Service. The error is the memory in the PHIT hob does not have a corresponding EFI_HOB_TYPE_RESOURCE_DESCRIPTOR of type EFI_RESOURCE_SYSTEM_MEMORY.
Here is an example of code doing the registration. As you can see it calls PeiServicesInstallPeiMemory() and also generates the Resource HOB.
https://github.com/tianocore/edk2/blob/master/QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c#L738
You could try to track down the code in your code base doing the above operation, and if that looks OK maybe add DEBUG prints and dump out the HOBs to see if the got corrupted some how?
[1] PHIT HOB
///
/// Contains general state information used by the HOB producer phase.
/// This HOB must be the first one in the HOB list.
///
typedef struct {
///
/// The HOB generic header. Header.HobType = EFI_HOB_TYPE_HANDOFF.
///
EFI_HOB_GENERIC_HEADER Header;
///
/// The version number pertaining to the PHIT HOB definition.
/// This value is four bytes in length to provide an 8-byte aligned entry
/// when it is combined with the 4-byte BootMode.
///
UINT32 Version;
///
/// The system boot mode as determined during the HOB producer phase.
///
EFI_BOOT_MODE BootMode;
///
/// The highest address location of memory that is allocated for use by the HOB producer
/// phase. This address must be 4-KB aligned to meet page restrictions of UEFI.
///
EFI_PHYSICAL_ADDRESS EfiMemoryTop;
///
/// The lowest address location of memory that is allocated for use by the HOB producer phase.
///
EFI_PHYSICAL_ADDRESS EfiMemoryBottom;
///
/// The highest address location of free memory that is currently available
/// for use by the HOB producer phase.
///
EFI_PHYSICAL_ADDRESS EfiFreeMemoryTop;
///
/// The lowest address location of free memory that is available for use by the HOB producer phase.
///
EFI_PHYSICAL_ADDRESS EfiFreeMemoryBottom;
///
/// The end of the HOB list.
///
EFI_PHYSICAL_ADDRESS EfiEndOfHobList;
} 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 <afish@apple.com <mailto:afish@apple.com>> escreveu:
>
>
> > On Jun 30, 2018, at 5:02 AM, Rafael Machado <rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@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 <ruiyu.ni@intel.com <mailto:ruiyu.ni@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-bounces@lists.01.org <mailto:edk2-devel-bounces@lists.01.org>] On Behalf Of
> >> Yao,
> >>> Jiewen
> >>> Sent: Saturday, June 30, 2018 3:28 AM
> >>> To: Rafael Machado <rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>; edk2-
> >>> devel@lists.01.org <mailto:devel@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-bounces@lists.01.org <mailto:edk2-devel-bounces@lists.01.org>] On Behalf Of
> >>>> Rafael Machado
> >>>> Sent: Friday, June 29, 2018 12:06 PM
> >>>> To: edk2-devel@lists.01.org <mailto: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 Start End # Pages
> >>>> Attributes
> >>>> BS_Code 0000000000000000-0000000000000FFF 0000000000000001
> >>>> 000000000000000F
> >>>> BS_Data 0000000000001000-0000000000001FFF 0000000000000001
> >>>> 000000000000000F
> >>>> BS_Code 0000000000002000-000000000000BFFF 000000000000000A
> >>>> 000000000000000F
> >>>> Available 000000000000C000-0000000000057FFF 000000000000004C
> >>>> 000000000000000F
> >>>> Reserved 0000000000058000-0000000000058FFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 0000000000059000-0000000000069FFF 0000000000000011
> >>>> 000000000000000F
> >>>> BS_Data 000000000006A000-000000000006AFFF 0000000000000001
> >>>> 000000000000000F
> >>>> BS_Code 000000000006B000-000000000008BFFF 0000000000000021
> >>>> 000000000000000F
> >>>> Reserved 000000000008C000-000000000009FFFF 0000000000000014
> >>>> 000000000000000F
> >>>> BS_Code 0000000000100000-000000000010FFFF 0000000000000010
> >>>> 000000000000000F
> >>>> Available 0000000000110000-000000004D684FFF 000000000004D575
> >>>> 000000000000000F
> >>>> BS_Data 000000004D685000-000000004D6A4FFF 0000000000000020
> >>>> 000000000000000F
> >>>> Available 000000004D6A5000-000000004E34EFFF 0000000000000CAA
> >>>> 000000000000000F LoaderCode 000000004E34F000-000000004E42CFFF
> >>>> 00000000000000DE 000000000000000F
> >>>> BS_Data 000000004E42D000-0000000050510FFF 00000000000020E4
> >>>> 000000000000000F
> >>>> ACPI_NVS 0000000050511000-0000000050511FFF 0000000000000001
> >>>> 000000000000000F
> >>>> RT_Data 0000000050512000-0000000050512FFF 0000000000000001
> >>>> 800000000000000F
> >>>> BS_Data 0000000050513000-0000000050673FFF 0000000000000161
> >>>> 000000000000000F
> >>>> BS_Code 0000000050674000-0000000050674FFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 0000000050675000-0000000052B6EFFF 00000000000024FA
> >>>> 000000000000000F
> >>>> BS_Data 0000000052B6F000-0000000053572FFF 0000000000000A04
> >>>> 000000000000000F
> >>>> Available 0000000053573000-0000000053834FFF 00000000000002C2
> >>>> 000000000000000F
> >>>> BS_Data 0000000053835000-0000000053A0DFFF 00000000000001D9
> >>>> 000000000000000F
> >>>> Available 0000000053A0E000-0000000053A64FFF 0000000000000057
> >>>> 000000000000000F
> >>>> BS_Data 0000000053A65000-0000000054778FFF 0000000000000D14
> >>>> 000000000000000F
> >>>> Available 0000000054779000-0000000054785FFF 000000000000000D
> >>>> 000000000000000F
> >>>> BS_Data 0000000054786000-00000000547CAFFF 0000000000000045
> >>>> 000000000000000F
> >>>> Available 00000000547CB000-00000000547D3FFF 0000000000000009
> >>>> 000000000000000F
> >>>> BS_Data 00000000547D4000-000000005481DFFF 000000000000004A
> >>>> 000000000000000F
> >>>> Available 000000005481E000-000000005481FFFF 0000000000000002
> >>>> 000000000000000F
> >>>> BS_Data 0000000054820000-0000000056683FFF 0000000000001E64
> >>>> 000000000000000F
> >>>> Available 0000000056684000-00000000590C2FFF 0000000000002A3F
> >>>> 000000000000000F
> >>>> BS_Code 00000000590C3000-0000000059E83FFF 0000000000000DC1
> >>>> 000000000000000F
> >>>> RT_Code 0000000059E84000-0000000059F4BFFF 00000000000000C8
> >>>> 800000000000000F
> >>>> RT_Data 0000000059F4C000-000000005B164FFF 0000000000001219
> >>>> 800000000000000F
> >>>> Reserved 000000005B165000-000000005B566FFF 0000000000000402
> >>>> 000000000000000F
> >>>> ACPI_NVS 000000005B567000-000000005B599FFF 0000000000000033
> >>>> 000000000000000F
> >>>> ACPI_Recl 000000005B59A000-000000005B5FEFFF 0000000000000065
> >>>> 000000000000000F
> >>>> BS_Data 000000005B5FF000-000000005B5FFFFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 0000000100000000-000000029E7FFFFF 000000000019E800
> >>>> 000000000000000F
> >>>> Reserved 00000000000A0000-00000000000FFFFF 0000000000000060
> >>>> 0000000000000000
> >>>> Reserved 000000005B600000-000000005F7FFFFF 0000000000004200
> >>>> 0000000000000000
> >>>> MMIO 00000000F0000000-00000000F7FFFFFF 0000000000008000
> >>>> 8000000000000001
> >>>> MMIO 00000000FE010000-00000000FE010FFF 0000000000000001
> >>>> 8000000000000001
> >>>>
> >>>> 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 Start End # Pages
> >>>> Attributes
> >>>> BS_Code 0000000000000000-0000000000000FFF 0000000000000001
> >>>> 000000000000000F
> >>>> BS_Data 0000000000001000-0000000000001FFF 0000000000000001
> >>>> 000000000000000F
> >>>> BS_Code 0000000000002000-000000000000BFFF 000000000000000A
> >>>> 000000000000000F
> >>>> Available 000000000000C000-0000000000057FFF 000000000000004C
> >>>> 000000000000000F
> >>>> Reserved 0000000000058000-0000000000058FFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 0000000000059000-0000000000069FFF 0000000000000011
> >>>> 000000000000000F
> >>>> BS_Data 000000000006A000-000000000006AFFF 0000000000000001
> >>>> 000000000000000F
> >>>> BS_Code 000000000006B000-000000000008BFFF 0000000000000021
> >>>> 000000000000000F
> >>>> Reserved 000000000008C000-000000000009FFFF 0000000000000014
> >>>> 000000000000000F
> >>>> BS_Code 0000000000100000-000000000010FFFF 0000000000000010
> >>>> 000000000000000F
> >>>> Available 0000000000110000-000000004D684FFF 000000000004D575
> >>>> 000000000000000F
> >>>> BS_Data 000000004D685000-000000004D6A4FFF 0000000000000020
> >>>> 000000000000000F
> >>>> Available 000000004D6A5000-000000004E34EFFF 0000000000000CAA
> >>>> 000000000000000F LoaderCode 000000004E34F000-000000004E42CFFF
> >>>> 00000000000000DE 000000000000000F
> >>>> BS_Data 000000004E42D000-0000000050510FFF 00000000000020E4
> >>>> 000000000000000F
> >>>> ACPI_NVS 0000000050511000-0000000050511FFF 0000000000000001
> >>>> 000000000000000F
> >>>> RT_Data 0000000050512000-0000000050512FFF 0000000000000001
> >>>> 800000000000000F
> >>>> BS_Data 0000000050513000-0000000050673FFF 0000000000000161
> >>>> 000000000000000F
> >>>> BS_Code 0000000050674000-0000000050674FFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 0000000050675000-0000000052384FFF 0000000000001D10
> >>>> 000000000000000F
> >>>> BS_Data 0000000052385000-0000000053572FFF 00000000000011EE
> >>>> 000000000000000F
> >>>> Available 0000000053573000-00000000535D7FFF 0000000000000065
> >>>> 000000000000000F
> >>>> BS_Data 00000000535D8000-000000005363EFFF 0000000000000067
> >>>> 000000000000000F
> >>>> Available 000000005363F000-0000000053834FFF 00000000000001F6
> >>>> 000000000000000F
> >>>> BS_Data 0000000053835000-0000000053A0DFFF 00000000000001D9
> >>>> 000000000000000F
> >>>> Available 0000000053A0E000-0000000053A64FFF 0000000000000057
> >>>> 000000000000000F
> >>>> BS_Data 0000000053A65000-0000000053F8EFFF 000000000000052A
> >>>> 000000000000000F
> >>>> Available 0000000053F8F000-0000000053F9AFFF 000000000000000C
> >>>> 000000000000000F
> >>>> BS_Data 0000000053F9B000-0000000053F9CFFF 0000000000000002
> >>>> 000000000000000F
> >>>> Available 0000000053F9D000-0000000053FA5FFF 0000000000000009
> >>>> 000000000000000F
> >>>> BS_Data 0000000053FA6000-0000000053FAAFFF 0000000000000005
> >>>> 000000000000000F
> >>>> Available 0000000053FAB000-000000005438CFFF 00000000000003E2
> >>>> 000000000000000F
> >>>> BS_Data 000000005438D000-00000000543A5FFF 0000000000000019
> >>>> 000000000000000F
> >>>> Available 00000000543A6000-0000000054416FFF 0000000000000071
> >>>> 000000000000000F
> >>>> BS_Data 0000000054417000-0000000054417FFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 0000000054418000-0000000054425FFF 000000000000000E
> >>>> 000000000000000F
> >>>> BS_Data 0000000054426000-0000000054427FFF 0000000000000002
> >>>> 000000000000000F
> >>>> Available 0000000054428000-0000000054439FFF 0000000000000012
> >>>> 000000000000000F
> >>>> BS_Data 000000005443A000-000000005443FFFF 0000000000000006
> >>>> 000000000000000F
> >>>> Available 0000000054440000-000000005444FFFF 0000000000000010
> >>>> 000000000000000F
> >>>> BS_Data 0000000054450000-0000000054454FFF 0000000000000005
> >>>> 000000000000000F
> >>>> Available 0000000054455000-0000000054458FFF 0000000000000004
> >>>> 000000000000000F
> >>>> BS_Data 0000000054459000-000000005445BFFF 0000000000000003
> >>>> 000000000000000F
> >>>> Available 000000005445C000-0000000054467FFF 000000000000000C
> >>>> 000000000000000F
> >>>> BS_Data 0000000054468000-000000005446BFFF 0000000000000004
> >>>> 000000000000000F
> >>>> Available 000000005446C000-000000005446FFFF 0000000000000004
> >>>> 000000000000000F
> >>>> BS_Data 0000000054470000-0000000054470FFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 0000000054471000-0000000054471FFF 0000000000000001
> >>>> 000000000000000F
> >>>> BS_Data 0000000054472000-0000000054474FFF 0000000000000003
> >>>> 000000000000000F
> >>>> Available 0000000054475000-0000000054490FFF 000000000000001C
> >>>> 000000000000000F
> >>>> BS_Data 0000000054491000-0000000054494FFF 0000000000000004
> >>>> 000000000000000F
> >>>> Available 0000000054495000-00000000544ABFFF 0000000000000017
> >>>> 000000000000000F
> >>>> BS_Data 00000000544AC000-00000000544ACFFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 00000000544AD000-00000000544CCFFF 0000000000000020
> >>>> 000000000000000F
> >>>> BS_Data 00000000544CD000-00000000544CFFFF 0000000000000003
> >>>> 000000000000000F
> >>>> Available 00000000544D0000-00000000544E1FFF 0000000000000012
> >>>> 000000000000000F
> >>>> BS_Data 00000000544E2000-000000005450CFFF 000000000000002B
> >>>> 000000000000000F
> >>>> Available 000000005450D000-000000005451DFFF 0000000000000011
> >>>> 000000000000000F
> >>>> BS_Data 000000005451E000-000000005451EFFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 000000005451F000-0000000054535FFF 0000000000000017
> >>>> 000000000000000F
> >>>> BS_Data 0000000054536000-0000000054536FFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 0000000054537000-000000005453EFFF 0000000000000008
> >>>> 000000000000000F
> >>>> BS_Data 000000005453F000-0000000054543FFF 0000000000000005
> >>>> 000000000000000F
> >>>> Available 0000000054544000-0000000054579FFF 0000000000000036
> >>>> 000000000000000F
> >>>> BS_Data 000000005457A000-0000000054585FFF 000000000000000C
> >>>> 000000000000000F
> >>>> Available 0000000054586000-0000000054589FFF 0000000000000004
> >>>> 000000000000000F
> >>>> BS_Data 000000005458A000-000000005458CFFF 0000000000000003
> >>>> 000000000000000F
> >>>> Available 000000005458D000-000000005459DFFF 0000000000000011
> >>>> 000000000000000F
> >>>> BS_Data 000000005459E000-000000005459EFFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 000000005459F000-00000000545A1FFF 0000000000000003
> >>>> 000000000000000F
> >>>> BS_Data 00000000545A2000-00000000545A2FFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 00000000545A3000-00000000545A7FFF 0000000000000005
> >>>> 000000000000000F
> >>>> BS_Data 00000000545A8000-00000000545A9FFF 0000000000000002
> >>>> 000000000000000F
> >>>> Available 00000000545AA000-0000000054756FFF 00000000000001AD
> >>>> 000000000000000F
> >>>> BS_Data 0000000054757000-000000005477EFFF 0000000000000028
> >>>> 000000000000000F
> >>>> Available 000000005477F000-0000000054780FFF 0000000000000002
> >>>> 000000000000000F
> >>>> BS_Data 0000000054781000-0000000054785FFF 0000000000000005
> >>>> 000000000000000F
> >>>> Available 0000000054786000-0000000054789FFF 0000000000000004
> >>>> 000000000000000F
> >>>> BS_Data 000000005478A000-00000000547CBFFF 0000000000000042
> >>>> 000000000000000F
> >>>> Available 00000000547CC000-00000000547CEFFF 0000000000000003
> >>>> 000000000000000F
> >>>> BS_Data 00000000547CF000-00000000547D3FFF 0000000000000005
> >>>> 000000000000000F
> >>>> Available 00000000547D4000-00000000547E7FFF 0000000000000014
> >>>> 000000000000000F
> >>>> BS_Data 00000000547E8000-00000000547F4FFF 000000000000000D
> >>>> 000000000000000F
> >>>> Available 00000000547F5000-00000000547FBFFF 0000000000000007
> >>>> 000000000000000F
> >>>> BS_Data 00000000547FC000-000000005481EFFF 0000000000000023
> >>>> 000000000000000F
> >>>> Available 000000005481F000-000000005481FFFF 0000000000000001
> >>>> 000000000000000F
> >>>> BS_Data 0000000054820000-0000000054828FFF 0000000000000009
> >>>> 000000000000000F
> >>>> Available 0000000054829000-0000000054829FFF 0000000000000001
> >>>> 000000000000000F
> >>>> BS_Data 000000005482A000-0000000054CFAFFF 00000000000004D1
> >>>> 000000000000000F
> >>>> Available 0000000054CFB000-0000000054CFCFFF 0000000000000002
> >>>> 000000000000000F
> >>>> BS_Data 0000000054CFD000-0000000055269FFF 000000000000056D
> >>>> 000000000000000F
> >>>> Available 000000005526A000-000000005526EFFF 0000000000000005
> >>>> 000000000000000F
> >>>> BS_Data 000000005526F000-0000000056683FFF 0000000000001415
> >>>> 000000000000000F
> >>>> Available 0000000056684000-00000000590C2FFF 0000000000002A3F
> >>>> 000000000000000F
> >>>> BS_Code 00000000590C3000-0000000059E83FFF 0000000000000DC1
> >>>> 000000000000000F
> >>>> RT_Code 0000000059E84000-0000000059F4BFFF 00000000000000C8
> >>>> 800000000000000F
> >>>> RT_Data 0000000059F4C000-000000005B164FFF 0000000000001219
> >>>> 800000000000000F
> >>>> Reserved 000000005B165000-000000005B566FFF 0000000000000402
> >>>> 000000000000000F
> >>>> ACPI_NVS 000000005B567000-000000005B599FFF 0000000000000033
> >>>> 000000000000000F
> >>>> ACPI_Recl 000000005B59A000-000000005B5FEFFF 0000000000000065
> >>>> 000000000000000F
> >>>> BS_Data 000000005B5FF000-000000005B5FFFFF 0000000000000001
> >>>> 000000000000000F
> >>>> Available 0000000100000000-000000029E7FFFFF 000000000019E800
> >>>> 000000000000000F
> >>>> Reserved 00000000000A0000-00000000000FFFFF 0000000000000060
> >>>> 0000000000000000
> >>>> Reserved 000000005B600000-000000005F7FFFFF 0000000000004200
> >>>> 0000000000000000
> >>>> MMIO 00000000F0000000-00000000F7FFFFFF 0000000000008000
> >>>> 8000000000000001
> >>>> MMIO 00000000FE010000-00000000FE010FFF 0000000000000001
> >>>> 8000000000000001
> >>>>
> >>>> 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,366 Pages (95,707,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,038,764 Pages (8,350,777,344 Bytes)
> >>>> --------------
> >>>> Total Memory: 8,089 MB (8,482,492,416 Bytes)
> >>>>
> >>>>
> >>>> I would like to understand better what causes these entries to be
> >> created.
> >>>> We already checked and there is no memory leak at the code.
> >>>> What causes these entries to be created?
> >>>> Can this increase on the memory map entries represent a risk of
> >>>> hanging the system at the subsequent boot?
> >>>>
> >>>> Thanks and Regards
> >>>> Rafael R. Machado
> >>>> _______________________________________________
> >>>> edk2-devel mailing list
> >>>> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
> >>>> https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel>
> >>> _______________________________________________
> >>> edk2-devel mailing list
> >>> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
> >>> https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel>
> >>
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
> > https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Question about memory map entries
2018-08-02 12:39 ` Rafael Machado
2018-08-02 14:37 ` Andrew Fish
@ 2018-08-02 14:44 ` Laszlo Ersek
2018-08-02 16:42 ` Rafael Machado
1 sibling, 1 reply; 19+ messages in thread
From: Laszlo Ersek @ 2018-08-02 14:44 UTC (permalink / raw)
To: Rafael Machado, Andrew Fish
Cc: Ni, Ruiyu, edk2-devel@lists.01.org, Yao, Jiewen
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Question about memory map entries
2018-08-02 14:44 ` Laszlo Ersek
@ 2018-08-02 16:42 ` Rafael Machado
2018-08-02 17:48 ` Laszlo Ersek
0 siblings, 1 reply; 19+ messages in thread
From: Rafael Machado @ 2018-08-02 16:42 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: Andrew Fish, Ni, Ruiyu, edk2-devel@lists.01.org, Yao, Jiewen
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 <lersek@redhat.com>
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
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Question about memory map entries
2018-08-02 16:42 ` Rafael Machado
@ 2018-08-02 17:48 ` Laszlo Ersek
2018-08-02 19:02 ` Rafael Machado
0 siblings, 1 reply; 19+ messages in thread
From: Laszlo Ersek @ 2018-08-02 17:48 UTC (permalink / raw)
To: Rafael Machado
Cc: Andrew Fish, Ni, Ruiyu, edk2-devel@lists.01.org, Yao, Jiewen
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Question about memory map entries
2018-08-02 17:48 ` Laszlo Ersek
@ 2018-08-02 19:02 ` Rafael Machado
2018-08-02 19:18 ` Rafael Machado
0 siblings, 1 reply; 19+ messages in thread
From: Rafael Machado @ 2018-08-02 19:02 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: Andrew Fish, Ni, Ruiyu, edk2-devel@lists.01.org, Yao, Jiewen
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 <lersek@redhat.com>
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
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Question about memory map entries
2018-08-02 19:02 ` Rafael Machado
@ 2018-08-02 19:18 ` Rafael Machado
2018-08-02 20:38 ` Laszlo Ersek
0 siblings, 1 reply; 19+ messages in thread
From: Rafael Machado @ 2018-08-02 19:18 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: Andrew Fish, Ni, Ruiyu, edk2-devel@lists.01.org, Yao, Jiewen
Just found something interesting.
Based on the logs from the serial port.
This system works fine:
"PeiInstallPeiMemory MemoryBegin 0x93D50000, MemoryLength 0xA2B0000
Temp Stack : BaseAddress=0x400000 Length=0x80000
Temp Heap : BaseAddress=0x480000 Length=0x80000
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=0x93D50000 Length=0x80000
Heap Offset = 0x93950000 Stack Offset = 0x93950000
Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi"
...
"CoreInitializeMemoryServices:
BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded -
0x5AC0000"
This one is bricked:
"PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000
Temp Stack : BaseAddress=0x400000 Length=0x80000
Temp Heap : BaseAddress=0x480000 Length=0x80000
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=0x80000
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.machado@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 <lersek@redhat.com>
> 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
>>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Question about memory map entries
2018-08-02 19:18 ` Rafael Machado
@ 2018-08-02 20:38 ` Laszlo Ersek
2018-08-07 19:12 ` Rafael Machado
0 siblings, 1 reply; 19+ messages in thread
From: Laszlo Ersek @ 2018-08-02 20:38 UTC (permalink / raw)
To: Rafael Machado
Cc: Andrew Fish, Ni, Ruiyu, edk2-devel@lists.01.org, Yao, Jiewen
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 0x93D50000, MemoryLength 0xA2B0000
> Temp Stack : BaseAddress=0x400000 Length=0x80000
> Temp Heap : BaseAddress=0x480000 Length=0x80000
> 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=0x93D50000 Length=0x80000
> Heap Offset = 0x93950000 Stack Offset = 0x93950000
> Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi"
> ...
> "CoreInitializeMemoryServices:
> BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded -
> 0x5AC0000"
>
> This one is bricked:
>
> "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000
> Temp Stack : BaseAddress=0x400000 Length=0x80000
> Temp Heap : BaseAddress=0x480000 Length=0x80000
> 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=0x80000
> 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 0x93D50000, MemoryLength 0xA2B0000
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 MemoryTypeInformation. Because, the
maximums that MemoryTypeInformation represents, no longer reflect
requirements for booting an OS. In that case, the
"MinimalMemorySizeNeeded" assumption (from commit 3a05b13106d1), for
initializing the DXE core, could be invalid too.
Thanks
Laszlo
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Question about memory map entries
2018-08-02 20:38 ` Laszlo Ersek
@ 2018-08-07 19:12 ` Rafael Machado
2018-08-07 22:42 ` Yao, Jiewen
0 siblings, 1 reply; 19+ messages in thread
From: Rafael Machado @ 2018-08-07 19:12 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: Andrew Fish, Ni, Ruiyu, edk2-devel@lists.01.org, Yao, Jiewen
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 <lersek@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 0x93D50000, MemoryLength 0xA2B0000
> > Temp Stack : BaseAddress=0x400000 Length=0x80000
> > Temp Heap : BaseAddress=0x480000 Length=0x80000
> > 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=0x93D50000 Length=0x80000
> > Heap Offset = 0x93950000 Stack Offset = 0x93950000
> > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi"
> > ...
> > "CoreInitializeMemoryServices:
> > BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded -
> > 0x5AC0000"
> >
> > This one is bricked:
> >
> > "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000
> > Temp Stack : BaseAddress=0x400000 Length=0x80000
> > Temp Heap : BaseAddress=0x480000 Length=0x80000
> > 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=0x80000
> > 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 0x93D50000, MemoryLength 0xA2B0000
>
> 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 MemoryTypeInformation. Because, the
> maximums that MemoryTypeInformation represents, no longer reflect
> requirements for booting an OS. In that case, the
> "MinimalMemorySizeNeeded" assumption (from commit 3a05b13106d1), for
> initializing the DXE core, could be invalid too.
>
> Thanks
> Laszlo
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Question about memory map entries
2018-08-07 19:12 ` Rafael Machado
@ 2018-08-07 22:42 ` Yao, Jiewen
2018-08-08 11:55 ` Rafael Machado
0 siblings, 1 reply; 19+ messages in thread
From: Yao, Jiewen @ 2018-08-07 22:42 UTC (permalink / raw)
To: Rafael Machado, Laszlo Ersek
Cc: Andrew Fish, Ni, Ruiyu, edk2-devel@lists.01.org
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.machado@gmail.com]
Sent: Wednesday, August 8, 2018 3:12 AM
To: Laszlo Ersek <lersek@redhat.com>
Cc: Andrew Fish <afish@apple.com>; Ni, Ruiyu <ruiyu.ni@intel.com>; edk2-devel@lists.01.org; Yao, Jiewen <jiewen.yao@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 <lersek@redhat.com<mailto:lersek@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 0x93D50000, MemoryLength 0xA2B0000
> Temp Stack : BaseAddress=0x400000 Length=0x80000
> Temp Heap : BaseAddress=0x480000 Length=0x80000
> 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=0x93D50000 Length=0x80000
> Heap Offset = 0x93950000 Stack Offset = 0x93950000
> Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi"
> ...
> "CoreInitializeMemoryServices:
> BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded -
> 0x5AC0000"
>
> This one is bricked:
>
> "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000
> Temp Stack : BaseAddress=0x400000 Length=0x80000
> Temp Heap : BaseAddress=0x480000 Length=0x80000
> 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=0x80000
> 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 0x93D50000, MemoryLength 0xA2B0000
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 MemoryTypeInformation. Because, the
maximums that MemoryTypeInformation represents, no longer reflect
requirements for booting an OS. In that case, the
"MinimalMemorySizeNeeded" assumption (from commit 3a05b13106d1), for
initializing the DXE core, could be invalid too.
Thanks
Laszlo
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Question about memory map entries
2018-08-07 22:42 ` Yao, Jiewen
@ 2018-08-08 11:55 ` Rafael Machado
2018-08-08 17:31 ` Rafael Machado
0 siblings, 1 reply; 19+ messages in thread
From: Rafael Machado @ 2018-08-08 11:55 UTC (permalink / raw)
To: Yao, Jiewen; +Cc: Laszlo Ersek, Andrew Fish, Ni, Ruiyu, edk2-devel@lists.01.org
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 <jiewen.yao@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.machado@gmail.com]
> *Sent:* Wednesday, August 8, 2018 3:12 AM
> *To:* Laszlo Ersek <lersek@redhat.com>
> *Cc:* Andrew Fish <afish@apple.com>; Ni, Ruiyu <ruiyu.ni@intel.com>;
> edk2-devel@lists.01.org; Yao, Jiewen <jiewen.yao@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 <lersek@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 0x93D50000, MemoryLength 0xA2B0000
> > Temp Stack : BaseAddress=0x400000 Length=0x80000
> > Temp Heap : BaseAddress=0x480000 Length=0x80000
> > 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=0x93D50000 Length=0x80000
> > Heap Offset = 0x93950000 Stack Offset = 0x93950000
> > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi"
> > ...
> > "CoreInitializeMemoryServices:
> > BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded -
> > 0x5AC0000"
> >
> > This one is bricked:
> >
> > "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000
> > Temp Stack : BaseAddress=0x400000 Length=0x80000
> > Temp Heap : BaseAddress=0x480000 Length=0x80000
> > 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=0x80000
> > 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 0x93D50000, MemoryLength 0xA2B0000
>
> 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 MemoryTypeInformation. Because, the
> maximums that MemoryTypeInformation represents, no longer reflect
> requirements for booting an OS. In that case, the
> "MinimalMemorySizeNeeded" assumption (from commit 3a05b13106d1), for
> initializing the DXE core, could be invalid too.
>
> Thanks
> Laszlo
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Question about memory map entries
2018-08-08 11:55 ` Rafael Machado
@ 2018-08-08 17:31 ` Rafael Machado
2018-08-08 19:13 ` Andrew Fish
0 siblings, 1 reply; 19+ messages in thread
From: Rafael Machado @ 2018-08-08 17:31 UTC (permalink / raw)
To: Yao, Jiewen; +Cc: Laszlo Ersek, Andrew Fish, Ni, Ruiyu, edk2-devel@lists.01.org
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.machado@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 <jiewen.yao@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.machado@gmail.com]
>> *Sent:* Wednesday, August 8, 2018 3:12 AM
>> *To:* Laszlo Ersek <lersek@redhat.com>
>> *Cc:* Andrew Fish <afish@apple.com>; Ni, Ruiyu <ruiyu.ni@intel.com>;
>> edk2-devel@lists.01.org; Yao, Jiewen <jiewen.yao@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 <lersek@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 0x93D50000, MemoryLength 0xA2B0000
>> > Temp Stack : BaseAddress=0x400000 Length=0x80000
>> > Temp Heap : BaseAddress=0x480000 Length=0x80000
>> > 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=0x93D50000 Length=0x80000
>> > Heap Offset = 0x93950000 Stack Offset = 0x93950000
>> > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi"
>> > ...
>> > "CoreInitializeMemoryServices:
>> > BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded -
>> > 0x5AC0000"
>> >
>> > This one is bricked:
>> >
>> > "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000
>> > Temp Stack : BaseAddress=0x400000 Length=0x80000
>> > Temp Heap : BaseAddress=0x480000 Length=0x80000
>> > 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=0x80000
>> > 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 0x93D50000, MemoryLength 0xA2B0000
>>
>> 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 MemoryTypeInformation. Because, the
>> maximums that MemoryTypeInformation represents, no longer reflect
>> requirements for booting an OS. In that case, the
>> "MinimalMemorySizeNeeded" assumption (from commit 3a05b13106d1), for
>> initializing the DXE core, could be invalid too.
>>
>> Thanks
>> Laszlo
>>
>>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Question about memory map entries
2018-08-08 17:31 ` Rafael Machado
@ 2018-08-08 19:13 ` Andrew Fish
2018-08-08 19:43 ` Rafael Machado
0 siblings, 1 reply; 19+ messages in thread
From: Andrew Fish @ 2018-08-08 19:13 UTC (permalink / raw)
To: Rafael Machado
Cc: Yao, Jiewen, Laszlo Ersek, Ni, Ruiyu, edk2-devel@lists.01.org
> On Aug 8, 2018, at 10:31 AM, Rafael Machado <rafaelrodrigues.machado@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.machado@gmail.com <mailto:rafaelrodrigues.machado@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 <jiewen.yao@intel.com <mailto:jiewen.yao@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.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>]
> Sent: Wednesday, August 8, 2018 3:12 AM
> To: Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>>
> Cc: Andrew Fish <afish@apple.com <mailto:afish@apple.com>>; Ni, Ruiyu <ruiyu.ni@intel.com <mailto:ruiyu.ni@intel.com>>; edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>; Yao, Jiewen <jiewen.yao@intel.com <mailto:jiewen.yao@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 <lersek@redhat.com <mailto:lersek@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 0x93D50000, MemoryLength 0xA2B0000
> > Temp Stack : BaseAddress=0x400000 Length=0x80000
> > Temp Heap : BaseAddress=0x480000 Length=0x80000
> > 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=0x93D50000 Length=0x80000
> > Heap Offset = 0x93950000 Stack Offset = 0x93950000
> > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi"
> > ...
> > "CoreInitializeMemoryServices:
> > BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded -
> > 0x5AC0000"
> >
> > This one is bricked:
> >
> > "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000
> > Temp Stack : BaseAddress=0x400000 Length=0x80000
> > Temp Heap : BaseAddress=0x480000 Length=0x80000
> > 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=0x80000
> > 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 0x93D50000, MemoryLength 0xA2B0000
>
> 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 MemoryTypeInformation. Because, the
> maximums that MemoryTypeInformation represents, no longer reflect
> requirements for booting an OS. In that case, the
> "MinimalMemorySizeNeeded" assumption (from commit 3a05b13106d1), for
> initializing the DXE core, could be invalid too.
>
> Thanks
> Laszlo
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Question about memory map entries
2018-08-08 19:13 ` Andrew Fish
@ 2018-08-08 19:43 ` Rafael Machado
0 siblings, 0 replies; 19+ messages in thread
From: Rafael Machado @ 2018-08-08 19:43 UTC (permalink / raw)
To: Andrew Fish; +Cc: Yao, Jiewen, Laszlo Ersek, Ni, Ruiyu, edk2-devel@lists.01.org
Hi Andrew.
Thanks for the clarification!
Rafael
Em qua, 8 de ago de 2018 às 16:14, Andrew Fish <afish@apple.com> escreveu:
>
> On Aug 8, 2018, at 10:31 AM, Rafael Machado <
> rafaelrodrigues.machado@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.machado@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 <jiewen.yao@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.machado@gmail.com]
>>> *Sent:* Wednesday, August 8, 2018 3:12 AM
>>> *To:* Laszlo Ersek <lersek@redhat.com>
>>> *Cc:* Andrew Fish <afish@apple.com>; Ni, Ruiyu <ruiyu.ni@intel.com>;
>>> edk2-devel@lists.01.org; Yao, Jiewen <jiewen.yao@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 <lersek@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 0x93D50000, MemoryLength 0xA2B0000
>>> > Temp Stack : BaseAddress=0x400000 Length=0x80000
>>> > Temp Heap : BaseAddress=0x480000 Length=0x80000
>>> > 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=0x93D50000 Length=0x80000
>>> > Heap Offset = 0x93950000 Stack Offset = 0x93950000
>>> > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi"
>>> > ...
>>> > "CoreInitializeMemoryServices:
>>> > BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded -
>>> > 0x5AC0000"
>>> >
>>> > This one is bricked:
>>> >
>>> > "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000
>>> > Temp Stack : BaseAddress=0x400000 Length=0x80000
>>> > Temp Heap : BaseAddress=0x480000 Length=0x80000
>>> > 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=0x80000
>>> > 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 0x93D50000, MemoryLength 0xA2B0000
>>>
>>> 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 MemoryTypeInformation. Because, the
>>> maximums that MemoryTypeInformation represents, no longer reflect
>>> requirements for booting an OS. In that case, the
>>> "MinimalMemorySizeNeeded" assumption (from commit 3a05b13106d1), for
>>> initializing the DXE core, could be invalid too.
>>>
>>> Thanks
>>> Laszlo
>>>
>>>
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2018-08-08 19:43 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-06-29 19:05 Question about memory map entries Rafael Machado
2018-06-29 19:27 ` Yao, Jiewen
2018-06-30 1:31 ` Ni, Ruiyu
2018-06-30 12:02 ` Rafael Machado
2018-06-30 19:23 ` Andrew Fish
2018-08-02 12:39 ` Rafael Machado
2018-08-02 14:37 ` Andrew Fish
2018-08-02 14:44 ` Laszlo Ersek
2018-08-02 16:42 ` Rafael Machado
2018-08-02 17:48 ` Laszlo Ersek
2018-08-02 19:02 ` Rafael Machado
2018-08-02 19:18 ` Rafael Machado
2018-08-02 20:38 ` Laszlo Ersek
2018-08-07 19:12 ` Rafael Machado
2018-08-07 22:42 ` Yao, Jiewen
2018-08-08 11:55 ` Rafael Machado
2018-08-08 17:31 ` Rafael Machado
2018-08-08 19:13 ` Andrew Fish
2018-08-08 19:43 ` Rafael Machado
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox