New syscons bugs: shutdown -r doesn't execute rc.d sequence and others
Bruce Evans
brde at optusnet.com.au
Wed Mar 29 08:26:27 UTC 2017
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
More information about the freebsd-current
mailing list