On Thu Apr 07, 2005 at 09:01:16AM -0400, Christos Zoulas wrote:
> In article <Pine.NEB.4.61.0504071419140.17689@fw.selonen.org>,
> Arto Selonen  <arto+dated+1112874166.37d209edfebf9005@selonen.org> wrote:
> >
> >Could be related to the way some NICs were doing (not doing?) resets
> >on the NIC when starting/stopping tcpdump. At least I think I remember
> >some work being done on several drivers a month a few back (maybe Jan/Feb, 
> >though I can't remember/find if those covered wm).
> >
> >Or, it could be related to something else. I'm seeing wm-related problems
> >with 3.99.3 as well: kern/29903. In any case, wm has been a pain, lately.
> 
> Artsi is probably right. If you are connected on a vlan switch, and you
> don't have fast convergence (what is the cisco term for that?), then when
> NetBSD erroneously brings down and up the interface to set promiscuous
> mode, the switch restarts the vlan negotiation and that can take up to
> a minute. The solution is to fix the drivers to do the minimal work to
> enter/exit promiscuous mode where possible without affecting link state.

portfast is the cisco term I believe you're looking for.  I noticed this 
as well on an alhpa when using the tulip based drivers.  tlp would 
renegotiate with the link partner when put into promiscuous mode while 
the older de driver would not.  Since this machine is used for monitoring, 
I had to fallback on using the de driver.
 

-- 
Courtney R. Spencer