From owner-freebsd-current@freebsd.org Tue Nov 20 08:18:02 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E08A1110472D for ; Tue, 20 Nov 2018 08:18:01 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from smtp.rdsor.ro (smtp.rdsor.ro [193.231.238.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB4707F822 for ; Tue, 20 Nov 2018 08:18:00 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from localhost (localhost [127.0.0.1]) by smtp.rdsor.ro (Postfix) with ESMTP id 3CD6A56D81; Tue, 20 Nov 2018 10:17:51 +0200 (EET) X-Virus-Scanned: amavisd-new at oradea.rdsnet.ro Received: from smtp.rdsor.ro ([127.0.0.1]) by localhost (smtp.rdsor.ro [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18bcvYoaQE-O; Tue, 20 Nov 2018 10:17:50 +0200 (EET) Received: from email.rdsor.ro (webmail.rdsor.ro [193.231.238.6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dan_partelly@rdsor.ro) by smtp.rdsor.ro (Postfix) with ESMTPSA id AD4DE56B3B; Tue, 20 Nov 2018 10:17:50 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 20 Nov 2018 10:17:50 +0200 From: dan_partelly@rdsor.ro To: Warner Losh Cc: FreeBSD Current Subject: Re: Devd / devmatch(8) -- netif race 12-RC1 In-Reply-To: References: Message-ID: <873d8841484925a35cf8c751790659c1@rdsor.ro> X-Sender: dan_partelly@rdsor.ro User-Agent: Roundcube Webmail/1.2.3 X-Rspamd-Queue-Id: AB4707F822 X-Spamd-Result: default: False [-2.10 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.82)[-0.821,0]; IP_SCORE(0.01)[country: RO(0.05)]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.84)[-0.836,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[rdsor.ro]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: smtp.rdsor.ro]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[25.238.231.193.list.dnswl.org : 127.0.10.0]; FROM_NO_DN(0.00)[]; NEURAL_HAM_SHORT(-0.15)[-0.146,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8708, ipnet:193.231.224.0/20, country:RO]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 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: Tue, 20 Nov 2018 08:18:02 -0000 >> No, that's not what's happening. wlan0 isn't racing anything, because >> it's no longer listed in ifconfig But when is created lagg0 ? Acording rc output on screen , creation of cloned interface lagg0 takes place before wlan0 is created. Then this means SIOCLAGPORT will fail with Invalid argument. Also lagg0 is started at netif time as far as I know. Firmware for the wireless card is loaded later, and only even later wlan0 is created. So the way I see it, lagg0 cannot have a wlan0 port until firmware for the card is loaded and wlan0 is created, which takes place way after the system attempts to configure lagg0 ? Am I missing something ? Also, can you please tell me what happens that devmatch tries to load uhidd multiple times ? Dan În 2018-11-20 06:38, Warner Losh a scris: > On Mon, Nov 19, 2018 at 7:48 PM Dan Partelly > wrote: > >> Hello, >> >> Today I tried a simple wireless failover on a machine running >> free-bsd. After reboot the system cannot complete the initialization >> sequence OK with devmatcher. >> The devd/devmatch(8) combo correctly identified the wireless card >> and loaded required drivers and firmware. rcorder(8) reports that >> devd(8) runs after netif. As far as I gather, devd (8) runs >> devmatch(8) on nomatch class events. This results in the situation >> in which the interfaces are created before “plug and play” >> initialization of the wireless device is complete (no driver no >> firmware yet ) , wlan0 creation is impossible and so on and so >> forth. > > No, that's not what's happening. wlan0 isn't racing anything, because > it's no longer listed in ifconfig. > >> More so, I believe the runs of devmatch(8) are async in this >> scenario, so even if you moved devd(8) before netif service, this >> would not solve the issue, there will be race conditions. I know >> this can be solved by loading the drivers manually, but still rising >> some issue is in order: > > Network configuration happens asynchronously. devmatch gets run in > response to NOMATCH events which then causes the driver to load which > then causes the pccard_ether script to run which causes the device to > be configured. At least that's how it's supposed to work. > >> 1) Why does devd(8) service runs after netif ? I believe it should >> run before netif service, probably after kld service. Is there >> anything which prevents changing this order ? > > Because it doesn't matter? And because if devd is run too eary, too > few services are available. Getting the ordering right was... a > somewhat tricky and frustrating experience when I first committed > devd. > >> 2.) In the scenario in which devd(8) is started before netif, what >> can be done to ensure that a barier exists such that an arbitrary >> devmatch(8) run is guaranteed to finish loading required drivers >> before netif ? Ignore this if Im wrong about asyc nature of >> devmatch(8) run. > > Nothing. No such barrier is necessary. It should all happen > asynchronously. Maybe there's a config problem? > >> 3 In what state is devmatcher now ? A lot of modules seems to be >> loaded ok, but some do not yet. coretemp(4) hwpmc(4) , intel serie 9 >> smbus driver seems not. > > All of USB is done, part of PCI is done, all of the really old PC Card > (since it was easy), parts of FDT for embedded and parts of ACPI are > done. > > The drivers you've called out I think are PCI drivers that haven't > been updated. They should all be in GENERIC, but none are in MINIMAL > or perhaps a custom kernel. > > coretemp is a CPU device, and so I'm not sure we have the right PNP > information for the CPU bus for it to even load. > > Warner