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_at_ cc'ed). I never >>> compile vt driver into kernel, i.e. I don't have this lines in the >>> kernel config: >>> >>> device vt >>> device vt_vga >>> device vt_efifb >>> >>> 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 cause it. >>> 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, > etc. 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 vt) # 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. esac %%% 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 TERMCAP="cons25:md=\E[1;37m:so=\E[37;44m:se=\E[39;49m:us=\E[1;33;44m:ue=\E[22;39;49m:tc=cons25:". 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. Pseudographics: - I don't use it enough to see problems in it. Even finding the unicode glyph for the block character took me some time. Lynx: - 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. BruceReceived on Thu Mar 30 2017 - 03:53:21 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:11 UTC