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

> On Mar 28, 2017, at 21:40, Bruce Evans <brde_at_optusnet.com.au> wrote:
> 
>> 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.

I filed a bug a few years ago about USB keyboards and usability in ddb. If you increase the timeout so the USB hubs have enough time to probe/attach, they will work.

I haven't taken the time to follow up on that and fix the issue, or at least propose a bit more functional workaround.

HTH,
-Ngie