K 10
svn:author
V 6
eadler
K 8
svn:date
V 27
2018-03-14T07:30:58.105307Z
K 7
svn:log
V 3668
MFC r314641,r314646,r314997,r315390:

Colorize syscons kernel console output according to a table indexed
by the CPU number.

This was originally for debugging near-deadlock conditions where
multiple CPUs either deadlock or scramble each other's output trying
to report the problem, but I found it interesting and sometimes
useful for ordinary kernel messages.  Ordinary kernel messages
shouldn't be interleaved, but if they are then the colorization
makes them readable even if the interleaving is for every character
(provided the CPU printing each message doesn't change).

The default colors are 8-15 starting at 15 (bright white on black)
for CPU 0 and repeating every 8 CPUs.  This works best with 8 CPUs.
Non-bright colors and nonzero background colors need special
configuration to avoid unreadable and ugly combinations so are not
configured by default.  The next bright color after 15 is 8 (bright
black = dark gray) is not very readable but is the only other color
used with 2 CPUs.  After that the next bright color is 9 (bright
blue) which is not much brighter than bright black, but is used with
3+ CPUs.  Other bright colors are brighter.

Colorization is configured by default so that it gets tested.  It can
only be turned off by configuring SC_KERNEL_CONS_ATTR to anything other
than FG_WHITE.  After booting, all colors can be changed using the
syscons.kattr sysctl.  This is a SYSCTL_OPAQUE, and no utility is
provided to change it (sysctl only displays it).

The default colors work in all VGA modes that I could test.  In 2-color
graphics modes, all 8 bright colors are displayed as bright white, so
the colorization has no effect, but anything with a nonzero background
gives white on white unless the foreground is zero.  I don't have an
mono or VGA grayscale hardware to test on.  Support for mono mode seems
to have never worked right in syscons (I think bright white gives white
underline with either bold or bright), but VGA grayscale should work
better than 2-color graphics.

Implement ec_putc() (emergency kernel [syscons] console putc()) and use
it in emergency in sc_cnputc().

Locking fixes in sc_cnputc() previously turned off normal output in
near-deadlock conditions and added deferred output which might never
be completed.  Emergency output goes to the frame buffer using
sufficiently atomic non-blocking writes if the console is in text
mode (in graphics mode, nothing is done, modulo races setting the
graphics mode bit).  Screen updates overwrite the emergency output
if the emergency condition clears enough to reach them.

ec_putc() also works for "early" console output in normal x86 text
mode as soon as this mode is initialized (if ever).  This uses a
hard-coded x86 frame buffer address before cninit() and a hopefully
MI address after cninit().  But non-x86 is more likely to not support
text mode, when ec_putc() will be null.  ec_putc() has no dependencies
of syscons before cninit(), and only has them later to track syscons'
mode changes.  This commit doesn't attach ec_putc() for early use.

To test emergency use, put a breakpoint in central syscons output code
like sc_puts() and do some user output.  The system used to race or
deadlock in ddb output soon after entry to ddb.  The locking fixes
deferred the output until after leaving ddb, so ddb was unusable and
you had to try typing c[ontinue] blindly until it exited, or better use
a serial console in parallel.  Now the output goes to a window in the
middle 2/3 of the screen.  Scrolling is circular and there is no cursor,
but otherwise ec_putc() provides full dumb terminal functionality and
very fast output that hides artificates from dumb overwrites.

END