On Tue, 2011-02-01 at 12:05 -0800, Jack Vogel wrote: > At this point I'm open to any ideas, this sounds like a good one Sean, > thanks. > Mike, you want to test this ? > > Jack > > > On Tue, Feb 1, 2011 at 11:56 AM, Sean Bruno <sean...@yahoo-inc.com> > wrote: > > On Fri, 2011-01-28 at 08:10 -0800, Mike Tancsa wrote: > > On 1/23/2011 10:21 AM, Mike Tancsa wrote: > > > On 1/21/2011 4:21 AM, Jan Koum wrote: > > > One other thing I noticed is that when the nic is in its > hung state, the > > > WOL option is gone ? > > > > > > e.g > > > > > > em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> > metric 0 mtu 1500 > > > > options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4> > > > ether 00:15:17:ed:68:a4 > > > > > > vs > > > > > > > > > em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> > metric 0 mtu 1500 > > > > > > > > options=219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC> > > > ether 00:15:17:ed:68:a4 > > > > > > Another hang last night :( > > > > Whats really strange is that the WOL_MAGIC and TSO4 got > turned back on > > somehow ? I had explicitly turned it off, but when the NIC > was in its > > bad state > > > > em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> > metric 0 mtu 1500 > > > options=2198<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC> > > > > ... its back on along with TSO? Not sure if its coincidence > or a side > > effect or what. For now, I have had to re-purpose this nic > to something > > else. > > > > debug info shows > > > > Jan 28 00:25:10 backup3 kernel: Interface is RUNNING and > INACTIVE > > Jan 28 00:25:10 backup3 kernel: em1: hw tdh = 625, hw tdt = > 625 > > Jan 28 00:25:10 backup3 kernel: em1: hw rdh = 903, hw rdt = > 903 > > Jan 28 00:25:10 backup3 kernel: em1: Tx Queue Status = 0 > > Jan 28 00:25:10 backup3 kernel: em1: TX descriptors avail = > 1024 > > Jan 28 00:25:10 backup3 kernel: em1: Tx Descriptors avail > failure = 0 > > Jan 28 00:25:10 backup3 kernel: em1: RX discarded packets = > 0 > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Check = 903 > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Refresh = > 904 > > Jan 28 00:25:27 backup3 kernel: em1: link state changed to > DOWN > > Jan 28 00:25:30 backup3 kernel: em1: link state changed to > UP > > > > > > ---Mike > > > > I'm trying to get some more testing done regarding my > suggestions around > the OACTIVE assertions in the driver. More or less, it looks > like > intense periods of activity can push the driver into the > OACTIVE hold > off state and the logic isn't quite right in igb(4) or em(4) > to handle > it. > > I suspect that something like this modification to igb(4) may > be > required for em(4). > > Comments? > > Sean >
Does the logic I've implemented look sane? Sean _______________________________________________ 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"