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".


[1] https://github.com/openbsd/src/commit/453010f2034

Reply via email to