Date: Mon, 19 Nov 2018 21:38:26 -0700 From: Warner Losh <imp@bsdimp.com> To: dan_partelly <dan_partelly@rdsor.ro> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Devd / devmatch(8) -- netif race 12-RC1 Message-ID: <CANCZdfqWq%2B2Lc1UrTdb8Fc9XkyL8cpaqAmS-Sh-vev_ZOQesDQ@mail.gmail.com> In-Reply-To: <A4074445-D442-4244-8E73-7F34DAA5E3FD@rdsor.ro> References: <A4074445-D442-4244-8E73-7F34DAA5E3FD@rdsor.ro>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 19, 2018 at 7:48 PM Dan Partelly <dan_partelly@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 wi= th > devmatcher. > The devd/devmatch(8) combo correctly identified the wireless card and > loaded required drivers and firmware. rcorder(8) reports that devd(8) ru= ns > after netif. As far as I gather, devd (8) runs devmatch(8) on nomatch cla= ss > events. This results in the situation in which the interfaces are created > before =E2=80=9Cplug and play=E2=80=9D initialization of the wireless dev= ice 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 loadi= ng > 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) ru= n > is guaranteed to finish loading required drivers before netif ? Ignore th= is > 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 drive= r > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqWq%2B2Lc1UrTdb8Fc9XkyL8cpaqAmS-Sh-vev_ZOQesDQ>