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