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

On Tue, 28 Mar 2017, Ngie Cooper wrote:

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

I found a bug in screen resizing (the console context doesn't get resized).
This doesn't cause any keyboard problems.

>>> ...
>>> 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:
>> ...
>>
>> 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.

Is that for user mode or earlier?  ukb has some other fixes for ddb now, but
of course it can't work before it finds the device.

I recently found that usb boot drives sometimes don't have enough time to
probe/attach before they are used in mountroot, and the mount -a prompt
does locking that doesn't allow them enough time if they are not ready
before it.  The usb maintainers already know about this.

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

Bruce