Date: Mon, 20 Aug 2018 21:37:20 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: freebsd-bugs@freebsd.org Cc: koro@kzxiv.net Subject: Re: [Bug 230757] [syscons] random wrong color for kernel messages Message-ID: <20180820194127.C1023@besplex.bde.org> In-Reply-To: <bug-230757-39-iatwKu5zxt@https.bugs.freebsd.org/bugzilla/> References: <bug-230757-39@https.bugs.freebsd.org/bugzilla/> <bug-230757-39-iatwKu5zxt@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 19 Aug 2018 a bug that doesn't want replies@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230757 > > --- Comment #2 from koro@kzxiv.net --- > I confirm, it stops happening when I set the VM to only have one CPU, and > inversely, I get more colors if I add more CPUs. > > Seems like it's not a bug then. Colorized kernel messages are intentional, but they weren't quite ready to merge into FreeBSD-11 when they were merged there, so they are missing documentation and don't have such good control or defaults as in -current. > How do I turn it off though? In FreeBSD-11: - for boot messages, configure SC_KERNEL_CONS_ATTR to anything except its default of FG_WHITE (0xf). - after booting, use the hw.syscons.kattr sysctl to change the array of MAXCPU kernel attributes to whatever you want (all FG_WHITE to get the old behaviour). sysctl(8) doesn't handle arrays very well, so it takes rarely-used options to even print the values in the array. But don't turn it off. Try using better colors (don't use dark gray). Even I like colorized kernel messages, and I stopped using colorized ls 25 years ago. In -current: the following and more is in the man page: - SC_KERNEL_CONS_ATTRS gives an array of kernel attributes which is replicated as needed to initialize the array of MAXCPU kernel attributes - if SC_KERNEL_CONS_ATTRS is not configured, then configuring SC_KERNEL_CONS_ATTR to any non-default turns off colorization as in FreeBSD-11 The following is not in the man page: - the hard-to-use sysctl is not supported. - in FreeBSD-11 and later, kernel attributes can be changed at runtime by editing the array using ddb or /dev[k]mem. - in FreeBSD[1-7], the current kernel attribute can be changed by writing an ANSI color escape sequence using printf(9). Normal kernel messages don't do this, but you can do this using a kernel module. This is broken in FreeBSD[8-10] and old FreeBSD-11 and all versions of vt. (All console escape sequences are similarly working or broken.) - in FreeBSD-11 and later, the escape sequences work again for syscons, but are now per-CPU so that they work right in more cases under the heavier contention that is more likely with more CPUs. The following uncomitted feature might be excessive: - control of kernel attributes using vidcontrol -c. vidcontrol -c already has complications (in -current only) to control the cursor and mouse colors. The complicatations are remarkably large. They involve things like several layers of defaults with all except the boot time defaults settable using vidcontrol -c, and various terminal resets restoring to a lower layer but not too low. The following unimplemented feature might be excessive: - per-thread attributes instead of per-CPU. Choosing good attributes would then be even more difficult and hard to control. (E.g., you might use attribute = 8 + (tid % 8), but then the most interesting threads would surely have the worst attribute 8 (dark gray on black). This attribute should be avoided, but is used in FreeBSD-11 since it is a convenient way to avoid black on black.) Colorized kernel messages are most useful for identifying the source of the message, especially when there are interleaved messages from several sources. Sources are more associated with threads than with CPUs, but the CPU colorization works almost as well except under heavy interleaving because CPU affinity usually prevents the CPU changing often. Even per-thread attributes are not enough for avoiding kernel terminal contexts clobbering each other if kernel output has escape sequences (including UTF-8), since fast interrupt handlers, NMI handlers and trap handlers borrow the preempted thread's context. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180820194127.C1023>