> On Mar 29, 2017, at 01:26, Bruce Evans <b...@optusnet.com.au> wrote:
> On Tue, 28 Mar 2017, Ngie Cooper wrote:
>>> 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.
> 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).

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to