Summary: | Intermittent Boot Failure: bi_load_efi_data: GetMemoryMap error 5 | ||||||
---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Damien <nixuser1980> | ||||
Component: | kern | Assignee: | Rebecca Cran <bcran> | ||||
Status: | Closed FIXED | ||||||
Severity: | Affects Some People | CC: | bcran, dmgk | ||||
Priority: | Normal | ||||||
Version: | CURRENT | ||||||
Hardware: | arm64 | ||||||
OS: | Any | ||||||
Attachments: |
|
I should have added that this is on a Lenovo T480 on Intel Integrated Graphics. See bug #210244 Thanks for the bug report. I just fixed this in r344839 - https://svnweb.freebsd.org/base?view=revision&revision=344839 . (In reply to Rebecca Cran from comment #3) Saw that you added calling GetMemoryMap in a loop. Does this mean that the root cause is in a fault UEFI implementation? Thanks, Damien: no, the UEFI firmware implementation is correct. The problem that calling it in a loop solves is the case where allocating memory for the memory map causes the memory map to become fragmented, which requires more memory to hold it. Hopefully by allocating 10 more descriptors than GetMemoryMap tells us we need we avoid looping, but the loop is there to be sure. Thanks Rebecca, Has your change been pushed to SVN 13-CURRENT? I just synced and rebuilt kernel and world and I still get the error. Yes, it's been pushed to 13-CURRENT but you'll need to update your ESP manually: it isn't currently updated during an installworld. To update the ESP, mount it (e.g. /dev/ada0p1) as msdosfs and copy /boot/loader.efi to either efi/boot/bootx64.efi or efi/freebsd/loader.efi, whichever exists. (In reply to Rebecca Cran from comment #7) I have rebooted 3 times without issue at this point after updating the ESP. |
Created attachment 201983 [details] Boot failure: bi_load_efi_data: GetMemoryMap error 5 After commencing loading of the kernel, system fails to proceed through boot, stopping at bi_load_efi_data: GetMemoryMap error 5. Please see attachment for further details.