FWIW I have been experiencing a similar issue on a number of systems using the em(4) driver under 9.1-RELEASE. This is after upgrading from a snapshot of 8.3-STABLE. My systems use PF+ALTQ as well. The symptoms are: interface stops passing traffic until the system is rebooted. I have not yet been able to gain access to the systems to dig around (after they have crashed), however my kernel/network settings are properly tuned (high mbuf limit, hw.em.rxd/txd=4096, etc). It seems to happen about once a day on systems with around a sustained 50Mb/s of traffic.
I realize this is not much to go on but perhaps it helps. I am debating trying the e1000 driver in the latest CURRENT on top of 9.1-RELEASE. I noticed the Intel shared code was updated about a week ago. Would this change or perhaps another change to e1000 since 9.1-RELEASE possibly affect stability in a positive way? Thanks. On Mon, Feb 25, 2013 at 10:45 AM, Jack Vogel <jfvo...@gmail.com> wrote: > Have you done any poking around, looking at stats to determine why the > hangs? For instance, > might your mbuf pool be depleted? Some other network resource perhaps? > > Jack > > > On Mon, Feb 25, 2013 at 10:38 AM, Christopher D. Harrison < > harri...@biostat.wisc.edu> wrote: > >> Sure, >> The problem appears on both systems running with ALTQ and vanilla. >> -C >> >> On 02/25/13 12:29, Jack Vogel wrote: >> >> I've not heard of this problem, but I think most users do not use ALTQ, >> and we (Intel) do not >> test using it. Can it be eliminated from the equation? >> >> Jack >> >> >> On Mon, Feb 25, 2013 at 10:16 AM, Christopher D. Harrison < >> harri...@biostat.wisc.edu> wrote: >> >>> I recently have been experiencing network "freezes" and network "lockups" >>> on our Freebsd 9.1 systems which are running zfs and nfs file servers. >>> I upgraded from 9.0 to 9.1 about 2 months ago and we have been having >>> issues with almost bi-monthly. The issue manifests in the system becomes >>> unresponsive to any/all nfs clients. The system is not resource bound as >>> our I/O is low to disk and our network is usually in the 20mbit/40mbit >>> range. We do notice a correlation between temporary i/o spikes and >>> network freezes but not enough to send our system in to "lockup" mode for >>> the next 5min. Currently we have 4 igb nics in 2 aggr's with 8 queue's >>> per nic and our dev.igb reports: >>> >>> dev.igb.3.%desc: Intel(R) PRO/1000 Network Connection version - 2.3.4 >>> >>> I am almost certain the problem is with the ibg driver as a friend is >>> also experiencing the same problem with the same intel igb nic. He has >>> addressed the issue by restarting the network using netif on his systems. >>> According to my friend, once the network interfaces get cleared, everything >>> comes back and starts working as expected. >>> >>> I have noticed an issue with the igb driver and I was looking for >>> thoughts on how to help address this problem. >>> >>> http://freebsd.1045724.n5.nabble.com/em-igb-if-transmit-drbr-and-ALTQ-td5760338.html >>> >>> Thoughts/Ideas are greatly appreciated!!! >>> >>> -C >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >>> >> >> >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
