On Thu, 30 Mar 2017, Andrey Chernov wrote:
On 29.03.2017 6:29, Bruce Evans wrote:
I just found the cause, it is new syscons bug (bde@ cc'ed). I never
compile vt driver into kernel, i.e. I don't have this lines in the
When I add them, the bug described is gone. It seems syscons goes off to
early, provoking reboot.
Bah, I only have vt and vt_vga to check that I didn't break them.
Unfortunately, syscons still works right when I remove these lines.
Maybe two will be enough too, I don't check. I just don't need _any_ of
vt lines. What is matter it is that syscons only mode (without any vt)
was recently broken, causing shutdown problems and file system damage
each time. Syscons only mode works for years until you break it recently.
Actually, I fixed it not so recently (over the last few months), partly
with much older local fixes.
Kernel messages in syscons are now supposed to be colorized by CPU. The
It looks really crazy on 8-core CPU and should not be default. And I
don't see colors in vt mode (which should be parallel at that point, at
least), but what about invisible escapes on vidcontrol errors (f.e.
invalid argument) in vt mode?
It is tuned for an 8-core CPU :-). 16 CPUs don't get unique colors
by default, but could get 16 unique foreground ones and 1 reverse video
(reverse video indeed looks crazier for short messages). 2 CPUs don't
get the best choice of colors by default. More than 16 CPUs woold
need to use lots of reverse video, except in graphics mode I'm
considering expanding to 256 or 64K colors.
vt doesn't support colorized kernel messages since I don't want to touch
it more than necessary. See subr_terminal.c:termcn_putc(). This is almost
exactly the same as scteken_puts() where the color change and some bugs
were. It has to switch to the kernel color, and does this by abusing the
user state. User escape sequences get corrupted by kernel output, and
kernel escape sequence to change the color change the user's color but
not the kernel's if they are atomic and not part of a user escape sequence.
The escape sequences in dmesg are very interesting. You should debug those.
They might be caused by misparsing of kernel escape sequences, or more
likely by corruption of user escape sequences. This might happen when:
- user prints <ESC>foo" and ther terminal parses <ESC>
- kernel interrupts this and prints "bar"; <ESC>"foo" is a supported
sequence but <ESC>"bar" isn't
- the error handling is to print the entire escape sequence (that would
be the interleaved message <ESC>"bar" up to the point where the error
is detected. Kernel console drivers seem to discard the entire mess.
Userland xterm seems to print the entire message.
Usually there aren't enough kernel messages interleaved with user ones
to make the problem obvious. My changes should fix the problem for
syscons, not cause it. But if they are slightly wrong, then they might
Moreover, I can't enter KDB via Ctrl-Alt-ESC in the syscons only mode
anymore - nothing happens. In the vt mode I can, but can't exit via "c"
properly, all chars typed after "c" produce beep unless I switch to
another screen and back.
Try backing out r315984 only. This is supposed to fix parsing of output.
I'll try. thanx. But most dangerous new syscons bug is the first one,
damaging file system on each reboot. I try to go to KDB to debug it, but
seeing that I can't even enter KDB I understand that all that bugs,
including nasty one, are introduced by your syscons changes, it was a
hint to add completely unneeded and unused vt to my kernel config file.
It's normal to have a slightly damaged file system after a panic.
You might have entered ddb in a context which used to race or deadlock.
It might have seemed to work if it only raced. After the fix, when in
this mode the following happens:
- in graphics mode, no output is done. The races and deadlocks are not
all fixed in the keyboard driver, and it might work in this mode.
- in text mode, output is done specially, direct to the frame buffer,
in a horizontal window 2/3 of the screen size. This doesn't use a
full terminal driver so is hard to use at first. Even the reduced
window causes problems. The colorization was originally to make this
mode more usable.
This mode is rarely active, except for debugging the console driver
itself, or for low-level trap handlers. Put a breakpoint almost anywhere
in the console driver to see it. sc_puts() is a good choice.
vt is real downgrade. Its default console font is plain ugly, it is
impossible to work with it. I can't find proper TERM for it to make
function keys and pseudographics works in ncurses apps (not with xterm,
a little better with xterm-sco), lynx can't display all things properly,
I agree, but started testing vt a few years ago, and have workarounds
for some of its deficiencies. After committing only half of my fixes
for low-level console drivers, I got sidetracked into fixing higher
level syscons bugs (mainly for for attributes) that are caused by it
using the same methods as vt.
To work around the above:
Default console font:
- in text mode, it looks the same as sc, but doesn't have as many non-
default fonts in already /usr/share to choose from
- in graphics mode, the bold font used for bright characters looks OK,
but the font for normal characters is too thin as well as ugly.
Graphics mode also defaults to 8-bit wide fonts. Text mode uses
9-bit wide fonts with a hidden bit and the hidden bit extended for
characters in the graphics range. The 9th bit allows nicer fonts.
vt also breaks use of the 9th bit for graphics characters in text
mode. It benefits from the hidden bit, but always zero-extends it.
I don't understand the details. From an application:
# XXX user must load font with block char where we expect it.
case $VTY in
# XXX broken in text mode (no extension from 8th bit to 9th).
BL="\342\226\210";; # Block char 0x2588 in UTF8 for unicode font.
BL="\333";; # Block char 0xDB in ASCII for cp437 font.
I didn't load cp437 for vt, but found the unicode character for the
block glyph. This still doesn't work right. The hidden bit is not
extended. I guess the details are:
- vt looks up the unicode character and finds a glyph for it
- this glyph is not at its usual index '\333' in the font, but is outside
of the graphics range, so its 8th bit is zero-extended.
- unicode doesn't have normal characters in the range 0x80-0xff, but the
hardware font should. I think VGA also supports extended fonts. I
don't know if vt uses extended fonts or misplaces the block glyph in
the 0x80-0xff. It could also do fancy stuff like creating glyphs on
the fly. Then it would be difficult to find a place to map it if
the map is nearly full with in-use glyphs.
- graphics modes gives a much larger choice of fonts than sc or vt-text.
You can have much larger ones, as needed for 1920x1080. Since I don't
use vt, I never got around to setting this up. It seems to be far from
automatic, but I'm not sure of the details since I use a FreeBSD-~5.2
userland with current kernels.
Strings for function keys:
- these are just broken in both sc and vt
TERM and simple use of function keys:
- using vt in syscons mode mostly works, almost automatically. I just
use TEKEN_CONS25 and a hard-coded TERM=cons25 and
This termcap entry is needed for syscons too. It works around the
broken ESC...x sequences by changing attributes to use colors (the
ESC...x sequences should give sticky default colors and I program
them in .profile but that no longer works. xterm the program uses
resources and command-line options to allow the user to change the
bad defaults for ANSI attributes and user colors instead, much like
the ESC...x sequences used to. xterm escape sequences don't seem
to support this, so xterm TERMCAP entries should set colors like
the above or better, but I couldn't find any that do.
The above actually gives better colors than my ESC...x sequences.
ESC...x only supports adjusting normal and reverse video. xterm
resources support adjusting everything.
- I don't use it enough to see problems in it. Even finding the unicode
glyph for the block character took me some time.
- the above termcap hack works well for old lynx and man.
All we need is KMS integration alone and not vt.
KMS is unusable for me since it is only in a module.
Syscons has a remarkably large amount of support for VGA. The only
problems are that features that VGAs had in 1990 are still not used
in upper layers), and SVGA is not quite enough now. Syscons on
Intel graphics (SVGA compatible) is still much better than vt without
KMS. It supports switching from text mode to 1920x1080 graphics mode
at runtime. I don't actually use graphics mode except for X and other
OSes. It is too hard to make graphics mode work correctly for ddb
and low-level console messages. KMS would make it harder, since it
is too hard to even read large code to see where it has races and
deadlocks when it is reentered.
I also don't need teken features. syscons features that I need like
ESC...x support are easy to restore by restoring scterm-sc.c (takes
10-20 lines of updates). This loses mainly UTF8 support. UTF8 can't
really work for syscons either, since it has only 8-bit characters in
history, so all that can be done is map UTF8 encodings for 256 preferred
or active characters into 8-bit encodings.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"