> On Mar 29, 2017, at 01:26, Bruce Evans <brde_at_optusnet.com.au> wrote: > > 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. Ah, I misremembered my filing the bug — someone else did it: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=133989 (it happens at mountroot, for example, because of probing order being what it is). -Ngie
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:11 UTC