Fix vm86 initialization, part 3 of 2 and a half. (Actually, just fix
authorbde <bde@FreeBSD.org>
Sun, 25 Sep 2016 14:56:24 +0000 (14:56 +0000)
committerbde <bde@FreeBSD.org>
Sun, 25 Sep 2016 14:56:24 +0000 (14:56 +0000)
commit94a237c17c06741e0ffbf8367ea1e974c4571178
treeabdad329dfa4de991651ed56990a355c495c260a
parentd7e13d9f257eb0c54ab4b49bcc87b8c57a1b06de
Fix vm86 initialization, part 3 of 2 and a half.  (Actually, just fix
early printfs and debugging of vm86 initialization and some other early
initialization in some cases.)  Add an option debug.late_console (with
default 1=off) to move console and kdb initialization back where it was.
Do the same for amd64 although there is no vm86 there.

On my test system, debug.late_console=0 works for the syscons, sio and
uart console drivers on amd64 and i386, and for vt on i386 but not on
amd64.

The early printfs fixed by debug.late_console=0 are:
- on i386, the message about lost memory above 4G
- with -v in otherwise normal use, about 20 printfs for SMAP
- other debugging messages for memory sizing.  Mostly under -v and
  not printed in normal use.

Document in a comment how much earlier the initialization and early
printf()s can be.  That is very early for the console.  Not much more
than curthread is needed.  kdb use obviously needs to be not so early,
since it needs IDT initialization and that is done relatively late
for convenience and historical reasons.
sys/amd64/amd64/machdep.c
sys/i386/i386/machdep.c