> We're missing a fair bit of information to come to any conclusion yet. Cy, did you used it when loading the wifi drivers automatically with devmatcher ? Cause if you run GENERIC, chances are that you will not see any weird behavior. Most wifi drivers are compiled in kernel in this case. Meaning you will have no issues. The exception are bwi/bwn Broadcom drivers, those are not compiled in kernel. if you compile your kernel without the wifi drivers you use, and if said drivers already changed to support to be loaded automatically by devmatcher, you can research the behavior. And yes, I used too it for years too with wifi drivers compiled in kernel or statically loaded before netif runs. And it works, save for some PCI wired cards whose drivers where not able to sense correctly media presence net.wlan.devices contains the expected value for the hardware configuration, and correct drivers and firmware loaded , bwi0. This is a stock installation with GENERIC and no modifications What happens is that lagg0 is created and it’s initialization takes place way before devmatcher loads the driver for wifi card and it’s firmware and wlan0 is created. Meaning, slave laggport interface (wlan0 ) does not exist at the time the initialization is run. Meaning that it will fail. Dan În 2018-11-22 17:25, Cy Schubert a scris: > In message <798C848D-5F32-4BF9-87E0-ADD4F9B743AD_at_rdsor.ro>, Dan > Partelly writes > : >> wireless lagg initialization is broken in this scenario, all-right. >> The init/ >> rc system as it is now can’t cope easily with a modern asynchronous >> initial >> ization sequence. Sure you could probably find an order which works, >> only to >> find yourself in trouble next time you want add some modern >> functionality . >> It shows it’s age >> >> _at_Warner >> >> Could you tell me please if devmatcher supports taking over a PCI >> device whic >> h is attached by a generic driver already ? vga attaching modern GPUs >> comes t >> o mind . >> >> Dan > > We're missing a fair bit of information to come to any conclusion yet. > I've been using lagg with ath + rl and iwn + bge since FreeBSD 8, > currently on 13, with zero issues or problems on either of them over > the many years I've used this configuration. > > Can you provide output of sysctl net.wlan.devices, please? Also the > relevant bits of rc.conf (with PI redacted of course), and any > modifications to devfs.conf. dmesg output and anything relevant in > messages might also be helpful. > > > -- > Cheers, > Cy Schubert <Cy.Schubert_at_cschubert.com> > FreeBSD UNIX: <cy_at_FreeBSD.org> Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > >> >> >> > On Nov 20, 2018, at 15:26, Bjoern A. Zeeb <bzeeb-lists_at_lists.zabbadoz.net> >> wrote: >> > >> > On 20 Nov 2018, at 8:17, dan_partelly_at_rdsor.ro wrote: >> > >> >>>> 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 clo >> ned interface lagg0 takes place before wlan0 is created. Then this >> means SIO >> CLAGPORT will fail with Invalid argument. Also lagg0 is started at >> netif tim >> e 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 >> firmwar >> e for the card is loaded and wlan0 is created, which takes place way >> after th >> e system attempts to configure lagg0 ? Am I missing something ? >> > >> > lagg might be a problem. >> > >> > >> > While we are on the topic: I also noticed on a fixed 10G card that the netw >> ork startup it went through strangely wasn’t the same as it was when >> the dr >> iver was loaded and service netif start was called again. I have not >> had tim >> e to debug that any further. >> > >> > >> >> Also, can you please tell me what happens that devmatch tries to load uhi >> dd multiple times ? >> > >> > That’s probably similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi >> ?id=232782 ? >> >> _______________________________________________ >> freebsd-current_at_freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe_at_freebsd.org" >>Received on Thu Nov 22 2018 - 15:21:41 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:19 UTC