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_parte...@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
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
