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

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