New syscons bugs: shutdown -r doesn't execute rc.d sequence and others

[Bruce Evans]

On Wed, 29 Mar 2017, Bruce Evans wrote:

> On Wed, 29 Mar 2017, Andrey Chernov wrote:
> ...
>> 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.
>
> ...
> 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.

I tested usb keyboards again.  They sometimes work, much the same as
a few months ago after some fixes:
- after booting with -d, they never work (give no input) at the ddb
   prompt with either sc or vt.  usb is not initialized then, and no usb
   keyboard is attached to sc or vt
- after booting without loader with -a, sc rarely or never works (gives
   no input) at the mountroot prompt
- after booting with loader with -a, vt works at the mountroot prompt.
   I don't normally use loader but need to use it to change the configuration.
   This might be better than before.  There used to be a screen refresh bug.
- after booting with loader with -a, sc works at the mountroot prompt too.
   I previously debugged that vt worked better because it attaches the keyboard
   before this point, while sc attaches it after.  Booting with loader
   apparently fixes the order.
- after any booting, sc works for user input (except sometimes after a
   too-soft hard reset, the keyboard doesn't even work in the BIOS, and it
   takes unplugging the keyboard to fix this)
- after almost any booting, vt doesn't work for user input (gives no input).
   However, if ddb is entered using a serial console, vt does work!  A few
   months ago, normal input was fixed by configuring kbdmux (the default in
   GENERIC).  It is not fixed by unplugging the keyboard.  kbdmux has a known
   bug of not doing nested switching for the keyboard state.  Perhaps this
   "fixes" ddb mode.  But I would have expected it to break ddb mode.
- I didn't test sc after entering ddb, except early when it doesn't work.

The above testing is with a usb keyboard, no ps/2 keyboard, and no kbdmux.
Other combinations and dynamic switching move the bugs around, and a
serial console is needed to recover in cases where the bugs prevent any
keyboard input.

Bruce