From nobody Sat May 18 19:00:32 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VhY7g716Lz5LJXW for ; Sat, 18 May 2024 19:00:47 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VhY7g27Jwz4d4K for ; Sat, 18 May 2024 19:00:47 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 44IJ0XMg056276; Sat, 18 May 2024 12:00:39 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1716058839; x=1716059439; r=y; bh=QpjKhpCLh6Y7t6w3O+yWVu42Zf0KndAGFEq0J8GctKE=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=CDFnjGjlHXT3yDdZEr7VD8NVPtwMhneJDOLsM02DumfVi/08WTlZn5MIWMVxomHcI 5WYYFBSEI58zKnID6kowwv0FZRniyyyx85d3+bvOwQR4dEV7Ui8Q4X/FVRSb8yaL5Z aKm2Lj+65hSmPX49KTRaP8txWq75iJvGVhG4qH0GNv1SD2JpZdhXyQJJgES92RraRD 6oX32ikmJvXCcEUCql5zBucaFNLkym7K817hrdBJuwdNXKkk6fNkdJELjKfX/z3L9v 6t+MIcIBmhaXxoiuaaaKjhb2xfIHThBBhfhlgCHyYEvQF1oU8Uupqa+ZfKXVHwOS4s KBFoyW8ZSOmnw== List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Sat, 18 May 2024 12:00:32 -0700 From: Chris To: Warner Losh Cc: Oleksandr Kryvulia , FreeBSD Current Subject: Re: usb mouse not work on boot In-Reply-To: References: <20240518092649.6430ad53@ernst.home> <86ttivwikf.fsf@ltc.des.dev> <34a397ef-ca2d-4e04-9066-3cf8a0c48616@shurik.kiev.ua> User-Agent: UDNSMS/17.0 Message-ID: <8d02b4a30515f213c6d8f2dd25230525@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4VhY7g27Jwz4d4K On 2024-05-18 08:33, Warner Losh wrote: > On Sat, May 18, 2024, 9:22 AM Oleksandr Kryvulia > wrote: > >> 18.05.24 16:06, Warner Losh: >> >> >> >> On Sat, May 18, 2024, 6:51 AM Oleksandr Kryvulia >> wrote: >> >>> 18.05.24 12:59, Oleksandr Kryvulia: >>> >>> 18.05.24 12:55, Dag-Erling Smørgrav: >>> >>> Oleksandr Kryvulia >>> writes: >>> >>> Gary Jennejohn writes: >>> >>> Try adding uhid_load="YES" to your /boot/loader.conf. With that >>> added the module should be automatically loaded during the kernel >>> boot. >>> >>> As workaround I already have kld_list+="uhid" in /etc/rc.conf. >>> >>> I hope you don't mean that literally, because /etc/rc.conf is a shell >>> script and += is not valid shell syntax. On the other hand, something >>> like >>> >>> kld_list="${kld_list} uhid" >>> >>> Yes, you are right. I mean >>> sysrc kld_list+="uhid" >>> >>> >>> One more correction. Via kld_list I need load ums(4), loading only >>> uhid(4) does not solve a problem. >>> >> >> >> You don't need to change kld_list. In fact, you should undo any changes >> you've made there. Undo everything in loader.conf you've done. >> >> This is a bug in the boot optimization stuff. Or rather, this exposes a >> long standing bug in the USB code where there's an asymmetry between the >> nomatch events and the bus tree it presents to devctl causing devmatch to >> fail when the nomatch events aren't present on boot. >> >> Just set hw.bus.devctl_nomatch_enabled=1 in /boot/loader.conf and reboot. >> Or update to the change I'm about to make. >> >> >> Thanks for the detailed explanation, Warner. Interesting that on my system >> hw.bus.devctl_nomatch_enabled=1 is set by /etc/rc.d/devmatch but only >> explicit set it in /boot/loader.conf did the trick. That is why I think >> this sysctl don't work in my case. >> > > Yea. That's the optimization. We don't start generating events until it is > one. Setting it in the bootloader causes all events to coke through. > Setting it in devmatch turns them on after we run devmatch the first time, > omitting all of the ones generated on boot. Why is sysctl.conf(5) not the best location for this? > > Warner > >> --Chris