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 <a...@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

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@ 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

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.

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to