* grub EFI "too little memory"
[not found] <200806170307.m5H37DjU073382@shoebox.dholloway.com>
@ 2008-06-17 7:01 ` David Holloway
2008-06-17 8:52 ` Bean
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: David Holloway @ 2008-06-17 7:01 UTC (permalink / raw)
To: grub-devel
Intended for Robert Millan, et. al.
I have an Intel 1U server board that fails with the current version of
grub with the message "too little memory", as in line 312 of CVS version
1.4 of grub2/kern/efi/mm.c
The board is described here:
http://www.intel.com/design/telecom/products/cbp/ipserver/9979/overview.htm
I added some debug and I think "required_pages" at line 312 has a value
of 1MB (256 pages), consistent with MIN_HEAP.
mmap from the EFI shell reports just 38 pages of LoaderData and just 196
pages of LoaderCode.
It's my intention to bone up on EFI, but I'm not there yet.
The question: does just 38 pages of LoaderData make sense in this
implemetation? is MIN_HEAP too large or does this EFI implementation
provide too little memory to be practical?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: grub EFI "too little memory"
2008-06-17 7:01 ` grub EFI "too little memory" David Holloway
@ 2008-06-17 8:52 ` Bean
2008-06-17 8:58 ` David Holloway
2008-06-17 12:35 ` Robert Millan
2 siblings, 0 replies; 7+ messages in thread
From: Bean @ 2008-06-17 8:52 UTC (permalink / raw)
To: The development of GRUB 2
On Tue, Jun 17, 2008 at 3:01 PM, David Holloway <daveh@dholloway.com> wrote:
> Intended for Robert Millan, et. al.
>
> I have an Intel 1U server board that fails with the current version of grub
> with the message "too little memory", as in line 312 of CVS version 1.4 of
> grub2/kern/efi/mm.c
> The board is described here:
> http://www.intel.com/design/telecom/products/cbp/ipserver/9979/overview.htm
>
> I added some debug and I think "required_pages" at line 312 has a value of
> 1MB (256 pages), consistent with MIN_HEAP.
> mmap from the EFI shell reports just 38 pages of LoaderData and just 196
> pages of LoaderCode.
>
> It's my intention to bone up on EFI, but I'm not there yet.
>
> The question: does just 38 pages of LoaderData make sense in this
> implemetation? is MIN_HEAP too large or does this EFI implementation provide
> too little memory to be practical?
Hi,
I think this problem is caused by memory map. In new machine, the
memory map is quite large, the default value in mm.c is too low for
the whole map. You can change the value of
#define MEMORY_MAP_SIZE 0x1000
and retry again. For example, with my macbook, I need to set this
value to 0x4000.
--
Bean
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: grub EFI "too little memory"
2008-06-17 7:01 ` grub EFI "too little memory" David Holloway
2008-06-17 8:52 ` Bean
@ 2008-06-17 8:58 ` David Holloway
2008-06-17 13:26 ` Andrei E. Warkentin
2008-06-17 17:22 ` David Holloway
2008-06-17 12:35 ` Robert Millan
2 siblings, 2 replies; 7+ messages in thread
From: David Holloway @ 2008-06-17 8:58 UTC (permalink / raw)
To: daveh; +Cc: grub-devel
David Holloway wrote:
> Intended for Robert Millan, et. al.
>
> I have an Intel 1U server board that fails with the current version of
> grub with the message "too little memory", as in line 312 of CVS
> version 1.4 of grub2/kern/efi/mm.c
> The board is described here:
> http://www.intel.com/design/telecom/products/cbp/ipserver/9979/overview.htm
>
>
> I added some debug and I think "required_pages" at line 312 has a
> value of 1MB (256 pages), consistent with MIN_HEAP.
> mmap from the EFI shell reports just 38 pages of LoaderData and just
> 196 pages of LoaderCode.
>
> It's my intention to bone up on EFI, but I'm not there yet.
>
> The question: does just 38 pages of LoaderData make sense in this
> implemetation? is MIN_HEAP too large or does this EFI implementation
> provide too little memory to be practical?
I diagnosed the root problem.
The NSW1U board requires 7872 bytes for its memory map during the EFI
GetMemoryMap call, but only 4096 are supplied.
Obviously my short term solution is to increase MEMORY_MAP_SIZE from
0x1000 to 0x2000, but one wonders what the robust solution should be
instead. In fact, I now have the NSW1U server board working after this
change.
I'm now filing a bug report on the matter.
https://savannah.gnu.org/bugs/index.php?23615
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: grub EFI "too little memory"
2008-06-17 7:01 ` grub EFI "too little memory" David Holloway
2008-06-17 8:52 ` Bean
2008-06-17 8:58 ` David Holloway
@ 2008-06-17 12:35 ` Robert Millan
2 siblings, 0 replies; 7+ messages in thread
From: Robert Millan @ 2008-06-17 12:35 UTC (permalink / raw)
To: The development of GRUB 2
On Tue, Jun 17, 2008 at 12:01:57AM -0700, David Holloway wrote:
> Intended for Robert Millan, et. al.
Me? But I barely know anything about EFI :-)
--
Robert Millan
<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: grub EFI "too little memory"
2008-06-17 8:58 ` David Holloway
@ 2008-06-17 13:26 ` Andrei E. Warkentin
2008-06-17 17:22 ` David Holloway
1 sibling, 0 replies; 7+ messages in thread
From: Andrei E. Warkentin @ 2008-06-17 13:26 UTC (permalink / raw)
To: The development of GRUB 2
[-- Attachment #1: Type: text/plain, Size: 2145 bytes --]
Straight from the public UEFI docs:
If the MemoryMap buffer is too small, the EFI_BUFFER_TOO_SMALL error
code is returned and
the MemoryMapSize value contains the size of the buffer needed to
contain the current
memory map. The actual size of the buffer allocated for the consequent
call to GetMemoryMap()
should be bigger then the value returned in MemoryMapSize, since
allocation of the new buffer
may potentially increase memory map size.
...and of course you can use BootServices->AllocatePool to grab the
desired amount...
17.06.2008, в 3:58, David Holloway написал(а):
> David Holloway wrote:
>> Intended for Robert Millan, et. al.
>>
>> I have an Intel 1U server board that fails with the current version
>> of grub with the message "too little memory", as in line 312 of CVS
>> version 1.4 of grub2/kern/efi/mm.c
>> The board is described here:
>> http://www.intel.com/design/telecom/products/cbp/ipserver/9979/overview.htm
>>
>> I added some debug and I think "required_pages" at line 312 has a
>> value of 1MB (256 pages), consistent with MIN_HEAP.
>> mmap from the EFI shell reports just 38 pages of LoaderData and
>> just 196 pages of LoaderCode.
>>
>> It's my intention to bone up on EFI, but I'm not there yet.
>>
>> The question: does just 38 pages of LoaderData make sense in this
>> implemetation? is MIN_HEAP too large or does this EFI
>> implementation provide too little memory to be practical?
>
> I diagnosed the root problem.
> The NSW1U board requires 7872 bytes for its memory map during the
> EFI GetMemoryMap call, but only 4096 are supplied.
>
> Obviously my short term solution is to increase MEMORY_MAP_SIZE from
> 0x1000 to 0x2000, but one wonders what the robust solution should be
> instead. In fact, I now have the NSW1U server board working after
> this change.
>
> I'm now filing a bug report on the matter.
>
> https://savannah.gnu.org/bugs/index.php?23615
>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
[-- Attachment #2: Type: text/html, Size: 4830 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: grub EFI "too little memory"
2008-06-17 8:58 ` David Holloway
2008-06-17 13:26 ` Andrei E. Warkentin
@ 2008-06-17 17:22 ` David Holloway
2008-06-17 19:09 ` Andrei E. Warkentin
1 sibling, 1 reply; 7+ messages in thread
From: David Holloway @ 2008-06-17 17:22 UTC (permalink / raw)
To: daveh; +Cc: grub-devel
>
> On Tue, Jun 17, 2008 at 3:01 PM, David Holloway <address@hidden> wrote:
> >/ Intended for Robert Millan, et. al./
> >
> >/ I have an Intel 1U server board that fails with the current version of grub/
> >/ with the message "too little memory", as in line 312 of CVS version 1.4 of/
> >/ grub2/kern/efi/mm.c/
> >/ The board is described here:/
> >/ http://www.intel.com/design/telecom/products/cbp/ipserver/9979/overview.htm/
> >
> >/ I added some debug and I think "required_pages" at line 312 has a value of/
> >/ 1MB (256 pages), consistent with MIN_HEAP./
> >/ mmap from the EFI shell reports just 38 pages of LoaderData and just 196/
> >/ pages of LoaderCode./
> >
> >/ It's my intention to bone up on EFI, but I'm not there yet./
> >
> >/ The question: does just 38 pages of LoaderData make sense in this/
> >/ implemetation? is MIN_HEAP too large or does this EFI implementation provide/
> >/ too little memory to be practical?/
>
> Hi,
>
> I think this problem is caused by memory map. In new machine, the
> memory map is quite large, the default value in mm.c is too low for
> the whole map. You can change the value of
>
> #define MEMORY_MAP_SIZE 0x1000
>
> and retry again. For example, with my macbook, I need to set this
> value to 0x4000.
>
Exactly on target. Then we need a more robust and permanent solution I
think right?
How about asking with 0 sized buffer first knowing it will fail then
asking with a rounded-up buffer the 2nd time.
I can coded it, but I can't check it in of course.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: grub EFI "too little memory"
2008-06-17 17:22 ` David Holloway
@ 2008-06-17 19:09 ` Andrei E. Warkentin
0 siblings, 0 replies; 7+ messages in thread
From: Andrei E. Warkentin @ 2008-06-17 19:09 UTC (permalink / raw)
To: The development of GRUB 2
[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]
>
> Exactly on target. Then we need a more robust and permanent
> solution I think right?
>
> How about asking with 0 sized buffer first knowing it will fail then
> asking with a rounded-up buffer the 2nd time.
> I can coded it, but I can't check it in of course.
>
>
http://www.uefi.org/specs/
You shouldn't assume memory map size (in fact, it can change during
the runtime if you use AllocatePool/FreePool/AllocatePages/FreePages),
and should be something like...
UINTN currentMemoryMapSize = 0;
UINTN expectedMemoryMapSize = 0;
EFI_MEMORY_DESCRIPTOR *memoryMap = NULL;
UINTN mapKey;
UINTN descriptorSize;
UINT32 descriptorVersion;
EFI_STATUS status = EFI_BUFFER_TOO_SMALL;
while(status == EFI_BUFFER_TOO_SMALL)
{
status = gBS->GetMemoryMap(&expectedMemoryMapSize, &memoryMap,
&mapKey, &descriptorSize, &descriptorVersion);
if(status != EFI_BUFFER_TOO_SMALL)
{
break;
}
// May have allocated already...
if(currentMemorySize)
{
status = gBS->FreePool(memoryMap);
if(EFI_ERROR(status))
{
break;
}
}
// As per spec, allocate more than requested to handle growth of
memory map due to allocation).
expectedMemorySize = expectedMemorySize * 2;
status = gBS->AllocatePool(EfiLoaderData, expectedMemoryMapSize,
(VOID**) &memoryMap);
currentMemoryMapSize = expectedMemoryMapSize;
if(EFI_ERROR(status))
{
break;
}
// Make sure we retry to get the memory map.
status = EFI_BUFFER_TOO_SMALL;
}
if(EFI_ERROR(status) || currentMemoryMapSize == 0)
{
// No memory map, assorted errors....
}
// Loop over the memoryMapSize array using descriptorSize (_NOT_
sizeof(EFI_MEMORY_DESCRIPTOR)), as that could break for future EFI
versions where the descriptor size might increase with expansion).
// Free pool.
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
[-- Attachment #2: Type: text/html, Size: 5218 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2008-06-17 19:09 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <200806170307.m5H37DjU073382@shoebox.dholloway.com>
2008-06-17 7:01 ` grub EFI "too little memory" David Holloway
2008-06-17 8:52 ` Bean
2008-06-17 8:58 ` David Holloway
2008-06-17 13:26 ` Andrei E. Warkentin
2008-06-17 17:22 ` David Holloway
2008-06-17 19:09 ` Andrei E. Warkentin
2008-06-17 12:35 ` Robert Millan
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.