em driver, 82574L chip, and possibly ASPM
Jack Vogel
jfvogel at gmail.com
Tue Feb 1 20:37:38 UTC 2011
Looks good, except I don't like code #if 0'd out, I'll make an if_em.c to
try and
send it shortly.
Jack
On Tue, Feb 1, 2011 at 12:19 PM, Sean Bruno <seanbru at yahoo-inc.com> wrote:
> 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 <seanbru at 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
>
>
More information about the freebsd-hardware
mailing list