On Fri, Jan 25, 2008 at 10:41:34AM -0500, Yousif Hassan wrote: > Hi Pyun YongHyeon, > > First, I'd like to say thank you for sending this and trying to resolve > my (and others') problems with bfe driver. > > First the good news - your patch appears to solve nearly all of the > issues I've discovered and/or reported. After installing the kernel > with your patch, under normal circumstances, link up and down events are > detected automatically by the kernel now, and passed to userland. I > tested this with some customd devd scripts to make sure the devd > notification from if_net.c was ok, and it was. This is greatly improved > behavior! > > A couple minor nits - > > First: The first hunk out of the first file in the patch didn't apply > cleanly for me but it could be because I'm on a different file revision? > I'll attach the .rej file. It's no big deal, because it was trivial to > adjust it by hand, then I was able to compile. > > Second: There's one last remaining issue. If I set the bfe0_enable > parameter in rc.conf to "DHCP NOAUTO" (so that it doesn't try to do > anything on boot, because it can slow the process down while it's > negotiating an address), then the link state changes get queued up (as > before) until I manually run ifconfig once. After that one time, > everything from that point on is fine (meaning your changes are > working). For all I know, this might be unrelated to your driver patch, > but it was interesting. Setting the bfe0_enable to "DHCP" meant > everything worked fine from the start. Setting it to "UP" also was fine > in terms of your link state changes working (although in this > case /etc/rc.d/dhclient script won't work because the interface needs to > be configured in rc.conf to use DHCP; I must run "/sbin/dhclient bfe0" > manually in that case). >
I guess that is not related with link state handling of bfe(4). I'll commit the change to HEAD. > In all cases, THANK YOU - this is much much much better than before and > I can live with using bfe0_enable="DHCP" instead of "DHCP NOAUTO". Feel > free to ask me for more testing if you want to try and investigate the > one remaining queue issue. > Thanks for testing and feedback! > --Yousif > > On Fri, 2008-01-25 at 14:10 +0900, Pyun YongHyeon wrote: > > On Thu, Jan 24, 2008 at 01:07:22PM -0500, Yousif Hassan wrote: > > > On Thu, 2008-01-24 at 10:36 -0600, Brooks Davis wrote: > > > > On Thu, Jan 24, 2008 at 10:58:33AM -0500, Yousif Hassan wrote: > > > > > Thank you to all who responded. > > > > > > > > > > The suggestion was made to use devd or ifstated. Both sound like > > > > > excellent tools, but I'm currently being tripped up by a core > > problem - > > > > > both tools rely on the kernel to notify userland of link state > > changes > > > > > (which makes complete sense!). This is all well and good - but the > > > > > current issue I'm seeing is that the link state doesn't get updated > > > > > without running "ifconfig" again - is this by design? A known > > "issue?" > > > > > > > > > > An example: > > > > > 1. Unplug network cable from bfe0 > > > > > 2. I run ifconfig > > > > > 3. I see that interface bfe0's status is "no carrier". Good. > > > > > 4. I plug the cable into bfe0 > > > > > 5. Wait... wait... look in /var/log/messages... wait more.. NO STATE > > > > > CHANGE - the longest I've waited was 2 minutes, which is already too > > > > > long > > > > > 6. run "ifconfig" again > > > > > 7. Link state immediately changes, logs to /var/log/messages, devd > > > > > scripts run > > > > > > > > > > Is this a known behavior? It seems like the link state changes > > should > > > > > happen automatically, without something to "trigger" them. Isn't > > there > > > > > some kind of poll or interrupt sequence? I'm on 6.3 RC2 (will > > upgrade > > > > > to 6.3-RELEASE imminently) but can't imagine this code changed? > > Does > > > > > this work differently/better in 7.0? > > > > > > > > It's known but not well understood and is a driver bug. > > > > > > I was afraid you'd say that. Thanks for the info. > > > > > > I found PR kern/109733: [bge] bge link state issues (regression) > > > which, while referring to a different driver, has some of the same > > > symptoms. > > > > > > In the meantime, I scripted something that calls ifconfig every 30 > > > seconds or so, redirected its output to null, and put it in the > > > background and nice'd it; this seems to do the trick, albeit via a > > > horrid hack. Due to the bug you mentioned, sometimes link state events > > > queue up, too, and get passed to userland at once, which is no kind of > > > fun, but the script still works. > > > > > > > Try attached patch. I don't know whether it works or not but it > > seems that link state was not correctly tracked down by stock bfe(4). > > The attached patch does the following. > > - conversion to callout(9) API. > > - added missing lock in bfe_ifmedia_sts(). > > - implemented miibus_statchg method to track link state. > > - use our callout to drive watchdog timer. > > - restart Tx routine if pending queued packets are present in > > watchdog handler. > > - fixed blindly resetting watchdog timer in bfe_txeof(). > > > > I guess the above is minimal patch to get correct link state. > > If I had the hardware I would have rewritten bfe_encap/bfe_newbuf > > to use bus_dmamap_load_mbuf_sg(9). :( > > -- Regards, Pyun YongHyeon _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
