Re: Devd / devmatch(8) -- netif race 12-RC1
Warner Losh writes: > 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. The coretemp device is not really a device, it's just a couple of MSRs. As such, it is not attached to an enumerable bus, or any bus at all that devd's aware of. The only way to find out if it's supported is to call the driver's identify method, which checks the cpuid and creates a device instance for each reported sensor. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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"
Re: Devd / devmatch(8) -- netif race 12-RC1
On Wed, Nov 21, 2018, 11:43 PM Dan Partelly 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 > initialization 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 > > @Warner > > Could you tell me please if devmatcher supports taking over a PCI device > which is attached by a generic driver already ? vga attaching modern GPUs > comes to mind . > No. Newbus doesn't currently support reprobing, though some preliminary support. I have it on my list. Warner Dan > > > > On Nov 20, 2018, at 15:26, Bjoern A. Zeeb < > bzeeb-li...@lists.zabbadoz.net> wrote: > > > > On 20 Nov 2018, at 8:17, dan_parte...@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 > 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 ? > > > > lagg might be a problem. > > > > > > While we are on the topic: I also noticed on a fixed 10G card that the > network startup it went through strangely wasn’t the same as it was when > the driver was loaded and service netif start was called again. I have not > had time to debug that any further. > > > > > >> Also, can you please tell me what happens that devmatch tries to load > uhidd multiple times ? > > > > That’s probably similar to > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232782 ? > > ___ 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"
Re: Devd / devmatch(8) -- netif race 12-RC1
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-add4f9b74...@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 @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 FreeBSD UNIX: 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 wrote: > > On 20 Nov 2018, at 8:17, dan_parte...@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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ 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"
Re: Devd / devmatch(8) -- netif race 12-RC1
In message <798c848d-5f32-4bf9-87e0-add4f9b74...@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 > > @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 FreeBSD UNIX: 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 > wrote: > > > > On 20 Nov 2018, at 8:17, dan_parte...@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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ 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"
Re: Devd / devmatch(8) -- netif race 12-RC1
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 initialization 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 @Warner Could you tell me please if devmatcher supports taking over a PCI device which is attached by a generic driver already ? vga attaching modern GPUs comes to mind . Dan > On Nov 20, 2018, at 15:26, Bjoern A. Zeeb > wrote: > > On 20 Nov 2018, at 8:17, dan_parte...@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 >> 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 ? > > lagg might be a problem. > > > While we are on the topic: I also noticed on a fixed 10G card that the > network startup it went through strangely wasn’t the same as it was when the > driver was loaded and service netif start was called again. I have not had > time to debug that any further. > > >> Also, can you please tell me what happens that devmatch tries to load uhidd >> multiple times ? > > That’s probably similar to > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232782 ? ___ 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"
Re: Devd / devmatch(8) -- netif race 12-RC1
On 20 Nov 2018, at 8:17, dan_parte...@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 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 ? lagg might be a problem. While we are on the topic: I also noticed on a fixed 10G card that the network startup it went through strangely wasn’t the same as it was when the driver was loaded and service netif start was called again. I have not had time to debug that any further. Also, can you please tell me what happens that devmatch tries to load uhidd multiple times ? That’s probably similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232782 ? ___ 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"
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 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"
Re: Devd / devmatch(8) -- netif race 12-RC1
On Mon, Nov 19, 2018 at 7:48 PM Dan Partelly 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"
Devd / devmatch(8) -- netif race 12-RC1
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. 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: 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 ? 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. 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. ___ 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"
