Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 1 Feb 2011 12:37:36 -0800
From:      Jack Vogel <jfvogel@gmail.com>
To:        Sean Bruno <seanbru@yahoo-inc.com>
Cc:        "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, "freebsd-hardware@freebsd.org" <freebsd-hardware@freebsd.org>, Ivan Voras <ivoras@freebsd.org>, Jan Koum <jan@whatsapp.com>, Mike Tancsa <mike@sentex.net>
Subject:   Re: em driver, 82574L chip, and possibly ASPM
Message-ID:  <AANLkTinD0q3r85fAj0Kju9Vc6fT-MVrR1LRczu_XaRW0@mail.gmail.com>
In-Reply-To: <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com>
References:  <icgd44$89l$1@dough.gmane.org> <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <AANLkTim82pWyf_X%2Bu72uj8RkWeRUb_4KSQ8B_HpNYsP9@mail.gmail.com> <AANLkTinO1yfN--_K63-yD1LY3wusOF7wB2wwG8DUd5Z4@mail.gmail.com> <4D2C636B.5040003@sentex.net> <AANLkTimFzYZOkwdExm5JPRB7BaN8Am8pPcgrMT0wVZqy@mail.gmail.com> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <AANLkTimdJNV4Hxm6%2Bi3uVa7es9Vu=TDAFBzfUycuM=sZ@mail.gmail.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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
>
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinD0q3r85fAj0Kju9Vc6fT-MVrR1LRczu_XaRW0>