em driver, 82574L chip, and possibly ASPM

[Jack Vogel]

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
>