Date: Tue, 28 Mar 2017 23:24:05 -0700 From: Ngie Cooper <yaneurabeya@gmail.com> To: Bruce Evans <brde@optusnet.com.au> Cc: Andrey Chernov <ache@freebsd.org>, bde@freebsd.org, current@freebsd.org Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others Message-ID: <8078CD32-2DFB-4296-BD92-29627A1B4559@gmail.com> In-Reply-To: <20170329150903.T1156@besplex.bde.org> References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <D9EAB41D-CE19-4225-8868-F4AFE461F903@gmail.com> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> <20170329150903.T1156@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mar 28, 2017, at 21:40, Bruce Evans <brde@optusnet.com.au> wrote: >=20 >> On Wed, 29 Mar 2017, Bruce Evans wrote: >>=20 >>> 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. >>=20 >> ... >> 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. >>=20 >> 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. >=20 > 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 configuratio= n. > 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 keybo= ard > 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 know= n > 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. >=20 > 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 y= ou increase the timeout so the USB hubs have enough time to probe/attach, th= ey 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8078CD32-2DFB-4296-BD92-29627A1B4559>