em driver, 82574L chip, and possibly ASPM

Mike Tancsa mike at sentex.net
Tue Feb 1 20:15:22 UTC 2011


On 2/1/2011 3:05 PM, 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 ?

Sure, I am feeling lucky ;-)  If someone generates the appropriate em
diffs for me, I will apply on the box that sees this issue the most.

	---Mike

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


-- 
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mike at sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/


More information about the freebsd-hardware mailing list