network interface monitoring?

[Pyun YongHyeon]

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