Hi, set kern.msgbufsize=4587520 in loader.conf on an arm64 system with 16G of RAM and after boot -v no kernel ever showed up. This is loader.efi from a few weeks ago I assume. I can dig into anything if needed.
just out of curiosity, does 1MB or 512k have this same issue?
1M does not. That's my normal default :) I was wondering if PAGE_SIZE had anything to do with it but haven't tried something just below that. Should I?
We only allocate a small virtual address range for early kernel use. The msgbuf is allocated from this so when larger is overflowing this allocation. We could probably use the new pmap bootstrap code to handle this, although it's not something I've planned on doing.
@andrew that Review went in and this problem got fixed or is this still all open?
*** Bug 285678 has been marked as a duplicate of this bug. ***
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=ccaf78c962e85630298f068931862a3595e9bbdf commit ccaf78c962e85630298f068931862a3595e9bbdf Author: Andrew Turner <andrew@FreeBSD.org> AuthorDate: 2025-04-22 15:59:25 +0000 Commit: Andrew Turner <andrew@FreeBSD.org> CommitDate: 2025-04-22 16:08:57 +0000 arm64: Move cpu0 dpcpu and msgbuf to the DMAP When these are allocated we already have the DMAP region mapped. Search for the largest region and use this to hold these. Pr: 269726 Reviewed by: markj Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D42734 sys/arm64/arm64/pmap.c | 40 ++++++++++++++++++++++++++++++---------- 1 file changed, 30 insertions(+), 10 deletions(-)
Thank you! I'll start a build once other build breakage is gone.
^Triage: it has been several months. Is there anything further to do here?
(In reply to Mark Linimon from comment #8) I cannot remember; I'll re-check the next week.
(In reply to Bjoern A. Zeeb from comment #9) Seems to work fine and probably has as I found a 4M buffer in another loader.conf for that machine. Thanks Andy!