> On Mar 28, 2017, at 21:40, Bruce Evans <b...@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 _______________________________________________ firstname.lastname@example.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"