Hi Stuart et al., Sorry for the delay. Meanwhile, I've been reproducing the issue on 6.3 by adding device rd and increasing MINIROOTSIZE to grow the non-gdb amd64 kernel beyond 16 MB. The kernel simply fails to boot.
> If the kernel should grow to a point where we run past some limit, we'll fix > it. Right now, bsd.gdb kernels are > 50MB and load fine. While it's all true that there are no problems with bsd.gdb, the fact of the matter is also that even if such a bloated kernel as mentioned in the first paragraph is stripped below the 16 MB point it fails to boot. It even fails to boot if it is compressed down to a few MB, which means it has nothing to do with the actual size, but rather how its internal objects are addressed. The kicker is that during a 5.8 -> 5.9 transition i386 stopped behaving as bad as amd64 in this regard so that there is a i386 kernel that performs better than amd64 one is hardly growing as fast as the other. To make a long story short, the answer actually was in the commit mentioned in the original message[1] as NKL2_KIMG_ENTRIES is the limiting factor here killing kernel boot when embedded total object size grows beyond a certain 16 MB point. Changing this to e.g. 32 allows kernels to boot as long as they in turn are not too big to hit the next barrier. > That commit was only to move the kernel phys load address to 16MB. That's not true, Mike, and I assume you already knew it. ;) Feel free to ignore this or take it as a friendly reminder that not everything is "write smaller code" or "[kernels] load fine". Cheers, Franco [1] https://github.com/openbsd/src/commit/453010f2034
