New syscons bugs: shutdown -r doesn't execute rc.d sequence and others
Ngie Cooper
yaneurabeya at gmail.com
Wed Mar 29 06:24:08 UTC 2017
> 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
More information about the freebsd-current
mailing list