em driver, 82574L chip, and possibly ASPM

[Sean Bruno]

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