Messages in this thread | | | Date | Wed, 7 Aug 2013 17:19:35 +0200 | From | Borislav Petkov <> | Subject | Re: [edk2] Corrupted EFI region |
| |
On Tue, Aug 06, 2013 at 05:31:29PM +0200, Laszlo Ersek wrote: > Can you capture the OVMF debug output? Do you see > > ConvertPages: Incompatible memory types > > there? > > Can you set the following bits too in the debug mask? > > #define DEBUG_POOL 0x00000010 // Alloc & Free's > #define DEBUG_PAGE 0x00000020 // Alloc & Free's
Ok, I got debug output; I have to be careful now of not missing anything. Ok, so here we go:
First of all, I changed debugging mask to:
gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x8010007F
(I just set all three bits you requested).
Using the new OVMF.id changed the addresses, of course, so we're looking at 0x7dc59XXX ones now.
[ 0.000000] memblock_reserve: [0x0000007dc59018-0x0000007dc59618] efi_memblock_x86_reserve_range+0x70/0x75
So, I've attached an archive of the debug logs. The initial observations I could do is that the region still gets "squashed" to:
[ 0.014041] efi: mem11: type=4, attr=0xf, range=[0x000000007dc59000-0x000000007dc59000) (0MB)
from
[ 0.000000] efi: mem11: type=4, attr=0xf, range=[0x000000007dc59000-0x000000007e146000) (4MB)
And the interesting stuff in the OVMF output is right at the end:
ConvertRange: 7DC59000-7DC5AFFF to 4 AddRange: 7DC59000-7DC5AFFF to 4 AllocatePoolI: Type 4, Addr 7DC59018 (len 16F0) 26,735,072 Jumping to kernel
We get that same output no matter if I boot it with "-enable-kvm" or not.
If the order of the debug messages is the same as the calls actually happen, we AllocatePoolI to address 7DC59018 which we already have added as a range. But I'm not going to pretend I even know the code so I'll let you comment instead :).
Thanks.
-- Regards/Gruss, Boris.
Sent from a fat crate under my desk. Formatting is fine. -- [unhandled content-type:application/octet-stream] | |