https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746
--- Comment #4 from Dexuan Cui <[email protected]> --- (In reply to Marcel Moolenaar from comment #3) Hi Marcel, Thank you for the quick help! Yes, I checked all the AllocatePages() calls and they all succeeded, i.e. returning 0. I found the crash happened in elf64_exec() -> trampoline() -> efi_copy_finish -> *dst++ = *src++; In efi_copy_finish(), I added some printf's to dump the values of the varilables: /boot/kernel/kernel text=0xfe3048 data=0x128b68+0x207fa0 syms=[0x8+0x146f88+0x8+ Booting... Start @ 0xffffffff802e2640 ... EFI framebuffer information: addr, size 0xf8000000, 0x800000 dimensions 1024 x 768 stride 1024 masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 efi_copy_finish : staging=0xf37cb000 efi_copy_finish : staging_end=0xf67cb000 efi_copy_finish : staging_offset=0xf35cb000 efi_copy_finish : src=0xf37cb000, dst=0x200000, last=0xf67cb000 If I change the line last = (uint64_t *)staging_end; to last = (uint64_t *)staging + (1024*1024*45); The crash won't happen and the kernel can boot fine. I'm using the releng/10.3 branch, where EFI_STAGING_SIZE is 48MB. This is to say, the kernel can boot fine if I use EFI_STAGING_SIZE=45MB. Any idea? Why do you think is it a Hyper-V firmware bug in AllocatePages()? I'm not familar with UEFI Boot Services. :-) I'll check the memory map before/after the call to AllocatePages(). I'm going to use sys/boot/efi/loader/main.c: command_memmap() as an example to call GetMemoryMap. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "[email protected]"
