em driver, 82574L chip, and possibly ASPM

[Jack Vogel]

To those who are going to test, here is the if_em.c, based on head, with my
changes, I have to leave for the afternoon, and have not had a chance to
build
this, but it should work. I will check back in the later evening.

Any blatant problems Sean, feel free to fix them :)

Jack


On Tue, Feb 1, 2011 at 12:37 PM, Jack Vogel <jfvogel at gmail.com> wrote:

> 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
>>
>>
>