The bootloader is very slow. It appears that updating the screen is taking several times longer than it did in 12.2, so much so that getting to the Beastie menu now takes ~45 seconds rather than the ~5 it used to take. The slowness is evident after a power cycle, a hard reset, or just a reboot. The system was scratch installed with 13.0-RC1 (FreeBSD-13.0-RC1-amd64-memstick.img.xz) and immediately showed this issue. When upgraded to RC2 using freebsd-update there was no change in boot speed. uname -a reports: FreeBSD penguin.home.galassi.us 13.0-RC2 FreeBSD 13.0-RC2 #0 releng/13.0-n244684-13c22f74953: Fri Mar 12 04:05:19 UTC 2021 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
(In reply to Michael Galassi from comment #0) Is it UEFI boot or BIOS boot? Please post output from kenv command.
Created attachment 223391 [details] output of kenv command
(In reply to Michael Galassi from comment #3) OK, you have 8x16 font on 4k display and apparently the UEFI Blt() is not the fastest one either... While we still have few options how to optimize the screen draw (but it will take some time), there are few things... Of course the slowness itself is coming from drawing the screen (12 was using uefi text output method). It is good idea to check for firmware update, if there is one, it may improve things. Second option is to reduce resolution - we are currently drawing a bit too much, and 4k is large amount of data to be teransferred...
(In reply to Toomas Soome from comment #4) So possibly adding: efi_max_resolution="480p" to /boot/loader.conf would mitigate this in my case? I'll try this and report back.
(In reply to Toomas Soome from comment #4) So possibly adding: efi_max_resolution="480p" to /boot/loader.conf would mitigate this in my case? I just tried this, there is some output being done before loader.conf gets read and acted upon and that output is still very slow. Things do get better however when the Beastie menu comes up. I'll see if I can get bios updates for this system and report back if that helps this or not in case other folk encounter the same issue.
(In reply to Michael Galassi from comment #6) One optimization I have in mind is about the fact that even with clear screen, we do not really need to clear entire surface, esp with 4k, we have a lot of surface without any data... But this will take some time still.
(In reply to Toomas Soome from comment #7) I just updated the system's bios and that made no difference. It seems like the sweet spot is setting the efi_max_resolution to 720p at which time my boot time goes to about 30 seconds 'til Beastie is drawn. Given the nature of everything that is displayed up until after the Beastie menu, is there any reason not to force the resolution to 720p as the very first thing? Where in our source tree does the boot-loader live?
(In reply to Michael Galassi from comment #8) yes/no/maybe. One thing is, we are currently drawing a bit too much and this can be reduced. But other thing is, we can not assume we can set specific resolution - the display may not support it etc. The loader source is in /usr/src/stand.
Everyone who encountered this in 13.0 please retest in 13.1, it has improved at least on some Mac models.
I have a similar problem. My guess is the frame buffer does not set memory attribute properly. Note we do not have this problem as soon as kernel is loaded because we unconditionally set it as write-combining: https://cgit.freebsd.org/src/commit/sys/dev/vt/hw/efifb/efifb.c?id=7ef5e8bc80065821d8f277a41f8184e7990d27bc Later, we added "hw.efifb.cache_attr" tunable to allow uncacheable type. https://cgit.freebsd.org/src/commit/sys/dev/vt/hw/efifb/efifb.c?id=8dff0b6761407357c5bb42ee799c5c9f465557a3 We may be able to set it from loader via SetVirtualAddressMap(), I guess?
(In reply to Jung-uk Kim from comment #11) Sorry, wrong commit. The first commit was this: https://cgit.freebsd.org/src/commit/sys/dev/vt/hw/efifb/efifb.c?id=b85beee188c07a8bb9a91f081cd988ec4d8abbf6
(In reply to Jung-uk Kim from comment #11) Also, note we use GOP Blt function in loader and there is a possibility that GOP itself is not optimized and slow.
(In reply to Jung-uk Kim from comment #11) We can not use SetVirtualAddressMap() at this point: "The function can only be called at runtime, and is called by the owner of the system’s memory map: i.e., the component which called EFI_BOOT_SERVICES.ExitBootServices()." That is, we only can use it after we did ExitBootServices() and we can only call it just before trampoline to kernel (otherwise we can not access disks etc). For experiment, we have two options. First one is already existing - use 'gop off' command to switch console to use SimpleTextOutput() method. If the console was performing ok with earlier versions, then this will help. Second option is to add option to tell gfxfb_bl() in stand/common/gfx_fb.c to not use gop->Blt(), so it would use memory mapped framebuffer directly. If there is a bug with gop Blt() but memory attributes are set correctly, then this would work, because its the same as our kernel is doing. Unfortunately I do not have misbehaving system to test with.
https://reviews.freebsd.org/D49073
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=21b5b8b38b1c606fb8f6b1b0e3549072b3c1d44d commit 21b5b8b38b1c606fb8f6b1b0e3549072b3c1d44d Author: Toomas Soome <tsoome@FreeBSD.org> AuthorDate: 2025-02-20 19:50:20 +0000 Commit: Toomas Soome <tsoome@FreeBSD.org> CommitDate: 2025-02-20 19:50:20 +0000 loader.efi: add "gop blt <on|off>" command Some systems have very slow console output and it may be about either wrong memory attributes are set or gop->Blt() implementation is bad. We do not have good way to set memory attributes, but we can choose which Blt() to use (or we can set "gop off" to fall back on use of SimpleTextOutput protocol). This update adds argument for "gop" command to switch gop->Blt() use. Note, this update does not fix the problem, but allows us to try to understand the possible cause. PR: 254381 Reported by: Michael Galassi Reviewed by: manu, imp Differential Revision: https://reviews.freebsd.org/D49073 stand/common/gfx_fb.c | 10 +++++++++- stand/efi/loader/framebuffer.c | 26 +++++++++++++++++++++++--- 2 files changed, 32 insertions(+), 4 deletions(-)