Re: Devd / devmatch(8) -- netif race 12-RC1

>> 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 <dan_partelly_at_rdsor.ro>
> 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