From owner-freebsd-current@freebsd.org Sun Mar 14 14:11:01 2021 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 978055A81CE for ; Sun, 14 Mar 2021 14:11:01 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dz1g822sSz3pFc for ; Sun, 14 Mar 2021 14:10:59 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (115-38-180-10.area1c.commufa.jp [115.38.180.10]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 12EEAnpW007439 for ; Sun, 14 Mar 2021 23:10:49 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 14 Mar 2021 23:10:49 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: console: no USB keyboard! Message-Id: <20210314231049.7f5588bf4268dc3c77ce187a@dec.sakura.ne.jp> In-Reply-To: <20210314131653.1ac46909@hermann.fritz.box> References: <20210313200117.46db6706@hermann.fritz.box> <7719f608-f277-5ba9-903d-9da463b4c921@FreeBSD.org> <20210314131653.1ac46909@hermann.fritz.box> Reply-To: junchoon@dec.sakura.ne.jp Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Dz1g822sSz3pFc X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [-1.57 / 15.00]; HAS_REPLYTO(0.00)[junchoon@dec.sakura.ne.jp]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.975]; SUBJECT_ENDS_EXCLAIM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[153.125.133.21:from]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[115.38.180.10:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[153.125.133.21:from:127.0.2.255]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2021 14:11:01 -0000 On Sun, 14 Mar 2021 13:16:53 +0100 "Hartmann, O." wrote: > On Sun, 14 Mar 2021 11:42:13 +0200 > Andriy Gapon wrote: > > > On 13/03/2021 21:01, Hartmann, O. wrote: > > > Running 14-CURRENT on several boxes (i.e. FreeBSD 14.0-CURRENT #49 > > > main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 2021 amd64) with custom and/or > > > GENERIC kernel and USB-only equipment (mouse if available, keyboard). > > > In multiuser mode, there is no problem using the USB keyboard. On single user console > > > (for maintenance purposes), no USB keyboard is available. The same is true while > > > booting and the rc scripts are worked on. Usually, one can hit the enter key and > > > inserts a newline, this doesn't work anymore until the box is completely up! > > > > > > I do not know when this problem as been introduced, the very same config is used since > > > 13-CURRENT in its earlier time and has been modified accordingly, but I can't see > > > obvios changes which would explain the wrecked behaviour now. > > > > > > I got aware of this problem, when a small mistake in /etc/fstab rendered a box > > > unbootable, I had to head for the datacenter and wasn't even capable of interrupting > > > the stuck system. Checking on other boxes running recent 14-CURRENT revealed the same > > > problem. > > > > > > The interesting part is, that as long as those boxes are with the loader present (all > > > boxes are UEFI booting!), the USB keyboard works as expected and I'm able to select > > > kernel/kernel.old and so on. > > > > > > How to fix this? > > > > Can't help with fixing the problem, but here's some info. > > When you are at the loader prompt, BIOS provides emulation of a standard / > > legacy keyboard for the USB keyboard. That's why loader can work even though it > > doesn't know much about USB. > > When a FreeBSD driver for the USB controller takes over then the BIOS emulation > > stops. Until a FreeBSD peripheral driver like ukbd attaches, it's not possible > > to use the keyboad, unfortunately. You can check your dmesg to see when that > > happens. > > > > Personally, I try to avoid "legacy free" solutions and always have a PS/2 > > keyboard (even if it's a really a USB one using PS/2 <-> USB adapter). > > > > Of course, it would be great to reduce the dead window for USB keyboards and I > > think that it is doable. > > > > > > Hello, > > thank you very much for the explanation. For usual, I compile all necessary module > staticlly into the kernel, the USB mouse, massstorage, keyboard. There was a message > about some changes with uhid/hid, I tried all variants coming to my mind, starting from > GENERIC up to add-ons statically compiled in. The systems in question I observed this > the first time are quite old (Z77/IvyBridge era) and do have PS/2 sockets, but others > (KabyLake) doesn't. Most KVM we use today in the datacenters are VGA/USB based, so there > is no chance to attach PS/2 equipment :-( > > Kind regards, > > oh I usually try these kind of things though /boot/loader.conf whenever possible. If you prefer usbhid drivers, add BOTH hw.usb.usbhid.enable=1 usbhid_load="YES" lines to loader.conf. IIUC, these should not specified in /etc/sysctl.conf and /etc/rc.conf respectively (it's too late to work properly). It would automatically pull hidbus.ko in as a dependency. IIRC, at least for some trackpads are forcibly handled by i2c and don't work with legacy usb driver (ums). OTOH, if USB devices are accidentally (non-intended) handled by usbhid and causing problems, you shoud intentionally add hw.usb.usbhid.enable=0 in /boot/loader.conf. This is default, IIRC. HTH. -- Tomoaki AOKI