Hello Deb,
It sounds like you narrowed the problem quite a bit already. Clearly the fail
is sensitive to the value of third argument. So either that value either has
bad alignment or is in an area of the map not suitable for writing. It seems
likely that an unhandled exception is causing the actual hang. Allocation
results in the 0xF0000000 would be suspicious for an x86 system. Maybe that is
OK for IPF.
Why not print the value of the third argument for the passing (local pointer)
and failing (structure member) case. I can think of only two reasons it would
work with the local variable for the third argument and not the structure
member. The first reason would be that the structure has a packing option that
is causing bad alignment for p->ptr. The second reason would be that while the
local variable is writable, yet the one in the allocated structure is not.
If printing the third argument value is not easy, you could temporarily move
ptr to the top of the structure definition so that structure packing options do
not affect its alignment. Another experiment would be test the handling of
forced bad values for the third argument. You could modify the working local
pointer experiment to use bad alignment by adding 1 to the value of the local
pointer address. This would test the effect of an unaligned third argument:
{
void *ptrs [2] = {(void *)1ull, (void *)2ull};
void *goodPtr = &ptrs [0];
void *badPtr = ((char *) goodPtr + 1);
gBS->AllocatePool (EfiBootServicesData, 1, &goodPtr);
gBS->AllocatePool (EfiBootServicesData, 1, &badPtr);
}
Thanks,
Scott
From: Debabrata Chattopadhyay [mailto:debabrata.chattopadh...@pmcs.com]
Sent: Friday, November 28, 2014 05:53 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EFI_BOOT_SERVICES AllocatePool() hang
Hi Andrew,
Thanks for your answer.
Actually the same code is working very well for x64 platforms. But this problem
is occurring only for IPF platform.
Also in case I use &ptr , where ptr is a local pointer , instead of ((void
**)&p->ptr) then the BS->AllocatePool does not hang.
Also since you suggested that there may be a memory corruption early in the
driver hence we do the following too, for debug purposes :
This AllocatePool which is hanging , is in Start() call back , which (to the
best of my knowledge) is preceded by the DriverEntry and the Supported()
callbacks. I cleanup my DriverEntry and Supported() , for debugging purposes ,
so that the driver entry has the InstallMultipleProtocolInterfaces call and
after that a successful return. And supported has just a successful return .
This is to ensure that we are not doing any nasty memory / read / write related
stuffs early in the driver uptil the first AllocatePool () .
So the DriverEntry and Supported are just skeleton now. And the first line of
code in Start() is the (first call to) AllocatePool().The hang still exists.
Regards
Deb
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
