Date: Fri, 25 Jan 2008 10:41:34 -0500 From: Yousif Hassan <yousif@alumni.jmu.edu> To: pyunyh@gmail.com Cc: freebsd-net@freebsd.org, Brooks Davis <brooks@freebsd.org>, "Bruce M. Simpson" <bms@freebsd.org> Subject: Re: network interface monitoring? Message-ID: <1201275694.1537.13.camel@localhost> In-Reply-To: <20080125051059.GA22410@cdnetworks.co.kr> References: <1201125022.2106.67.camel@localhost> <20080123222047.GA14264@lor.one-eyed-alien.net> <1201190313.2591.7.camel@localhost> <20080124163634.GA25331@lor.one-eyed-alien.net> <1201198042.19736.5.camel@localhost> <20080125051059.GA22410@cdnetworks.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-LkOgVDBBrQ/VxuS13pmC Content-Type: text/plain Content-Transfer-Encoding: 7bit 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). 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. --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). :( > --=-LkOgVDBBrQ/VxuS13pmC--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1201275694.1537.13.camel>