(unknown charset) Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others

On Wed, 29 Mar 2017, Andrey Chernov wrote:

> On 29.03.2017 0:46, Ngie Cooper (yaneurabeya) wrote:
>>
>>> On Mar 28, 2017, at 14:27, Andrey Chernov <ache_at_freebsd.org> wrote:
>>
>> …
>>
>>>> Using rc_debug=yes I see that it is the kernel problem, not rc problem.
>>>> Sometimes rc backward sequence executed even fully, sometimes only
>>>> partly, but in unpredictable moment inside rc sequence the kernel decide
>>>> to reboot quickly (or even deadly hang in rare cases). Always without
>>>> any "Syncing buffers..." leaving FS dirty. No zfs etc. just normal UFS,
>>>> no EFI, no GPT.
>>>> I change GELI swap to normal one, but it does not help. The same
>>>> untouched config works for years, I see this bug for the first time in
>>>> FreeBSD.
>>>
>>> I forget to mention that typescript and dmesg does not survive after
>>> this reboot (or rare hang).
>>
>> Good to note.
>> The simple explanation to the problem might be r307755, depending on when you last synced/built ^/head.
>>
>> I have a few more questions (if reverting that doesn't pan out):
>
> 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.

> I also find some lines of the kernel messages strange colored instead of
> white in the syscons only mode. Even in vt mode vidcontrol errors have
> invisible escapes prepended (although visible through /var/log/messages).

Kernel messages in syscons are now supposed to be colorized by CPU.  The
boot messages should show all the colors.  Shutdown and ddb are normally
done by a single random CPU, so are shown in a single random color.  The
colors are bright (light) 8-15 foreground, except bright black (8) is not
so bright.  Configure with a non-default KERNEL_SC_CONS_ATTR (maybe
yellow on black instead of lightwhite on black) to turn of the colorization.
I haven't tested this recently.  There is also a sysctl for setting all
the colors.

> 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.
>
> All it means that syscons becomes very broken now by itself and even
> damages the kernel operations.

Try backing out r315984 only.  This is supposed to fix parsing of output.
It switches to a state indexed by the CPU for every character, and switches
back.  Screen switching does a different switch and would fix any bug in
switching back.

But I suspect it is a usb keyboard problem.  Syscons now does almost
correct locking for the screen, but not for the keyboard, and the usb
keyboard is especially fragile, especially in ddb mode.  Console input
is not used in normal operation except for checking for characters on
reboot.

Try using vt with syscons unconfigured.  Syscons shouldn't be used when
vt is selected, but unconfigure it to be sure.  vt has different bugs
using the usb keyboard.  I haven't tested usb keyboards recently.

Bruce