RELENG_7 em problems (and RELENG_8)
Mike Tancsa
mike at sentex.net
Tue Nov 23 14:06:42 UTC 2010
Again, for the archives, this problem is sadly still here. Although
it appears to happen a little less frequently with the driver from
HEAD. It seems it might be some issue specific to power savings, as
LINUX users seem to have the same issues
<http://sourceforge.net/tracker/index.php?func=detail&aid=2908463&group_id=42302&atid=447449>http://sourceforge.net/tracker/index.php?func=detail&aid=2908463&group_id=42302&atid=447449
Also
<http://lists.freebsd.org/pipermail/freebsd-net/2010-November/027044.html>http://lists.freebsd.org/pipermail/freebsd-net/2010-November/027044.html
has similar reports. Also disabling msix does not seem to make a difference.
---Mike
At 12:22 PM 11/7/2010, Mike Tancsa wrote:
>Just for the archives, the version of
><http://lists.freebsd.org/pipermail/svn-src-head/2010-November/022058.html>http://lists.freebsd.org/pipermail/svn-src-head/2010-November/022058.html
>
>
>fixes this particular problem on this particular version of the em
>nic for me on RELENG_8. The motherboard is an intel server board (S3420GPX)
>
>em1 at pci0:10:0:0: class=0x020000 card=0x34ec8086
>chip=0x10d38086 rev=0x00 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Intel 82574L Gigabit Ethernet Controller (82574L)'
> class = network
> subclass = ethernet
> cap 01[c8] = powerspec 2 supports D0 D3 current D0
> cap 05[d0] = MSI supports 1 message, 64 bit
> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
> cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled
>ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected
>ecap 0003[140] = Serial 1 001517ffffed68a4
>
>em1: <Intel(R) PRO/1000 Network Connection 7.1.7> port 0x2000-0x201f
>mem 0xb4100000-0xb411ffff,0xb4120000-0xb4123fff irq 16 at device 0.0 on pci10
>em1: Using MSIX interrupts with 3 vectors
>
>
>vmstat -i
>interrupt total rate
>irq256: em0 1025859018 993
>irq257: em1:rx 0 512606295 496
>irq258: em1:tx 0 405695908 393
>irq259: em1:link 39853 0
>Total 10422193166 10096
>
>
> ---Mike
>
>
>At 06:43 PM 9/26/2010, Mike Tancsa wrote:
>>At 06:19 PM 9/26/2010, Jack Vogel wrote:
>>>Your em1 is using MSI not MSIX and thus can't have multiple queues. I'm
>>>not sure whats broken from what you show here. I will try to get the new
>>>driver out shortly for you to try.
>>
>>With this particular NIC, it will wedge under high load. I tried 2
>>different motherboards and chipsets the same behaviour.
>>
>> ---Mike
>>
>>
>>>Jack
>>>
>>>
>>>On Sun, Sep 26, 2010 at 2:57 PM, Mike Tancsa
>>><<mailto:mike at sentex.net>mike at sentex.net> wrote:
>>>At 06:36 PM 9/24/2010, Jack Vogel wrote:
>>>There is a new revision of the em driver coming next week, its
>>>going thru some
>>>stress pounding over the weekend, if no issues show up I'll put it
>>>into HEAD.
>>>
>>>Yongari's changes in TX context handling which effects checksum and tso
>>>are added. I've also decided that multiple queues in 82574 just are a source
>>>of problems without a lot of benefit, so it still uses MSIX but
>>>with only 3 vectors,
>>>meaning it seperates TX and RX but has a single queue.
>>>
>>>
>>>Thanks, looking forward to trying it out! With respect to the
>>>multiple queues, I thought the driver already used just the one on
>>>RELENG_8 ? If not, is there a way to force the existing driver to
>>>use just the one queue ?
>>>
>>>On the box that has the NIC locking up, it shows
>>>
>>>em1 at pci0:9:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086
>>>rev=0x00 hdr=0x00
>>>
>>> vendor = 'Intel Corporation'
>>> device = 'Intel 82574L Gigabit Ethernet Controller (82574L)'
>>> class = network
>>> subclass = ethernet
>>> cap 01[c8] = powerspec 2 supports D0 D3 current D0
>>> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
>>> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
>>>
>>>and
>>>
>>>vmstat -i shows
>>>
>>>irq256: em0 5129063 353
>>>irq257: em1 531251 36
>>>
>>>in a wedged state, stats look like
>>>
>>>dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.0.5
>>>dev.em.1.%driver: em
>>>dev.em.1.%location: slot=0 function=0 handle=\_SB_.PCI0.PEX4.HART
>>>dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086
>>>subdevice=0x34ec class=0x020000
>>>dev.em.1.%parent: pci9
>>>dev.em.1.nvm: -1
>>>dev.em.1.rx_int_delay: 0
>>>dev.em.1.tx_int_delay: 66
>>>dev.em.1.rx_abs_int_delay: 66
>>>dev.em.1.tx_abs_int_delay: 66
>>>dev.em.1.rx_processing_limit: 100
>>>dev.em.1.link_irq: 0
>>>dev.em.1.mbuf_alloc_fail: 0
>>>dev.em.1.cluster_alloc_fail: 0
>>>dev.em.1.dropped: 0
>>>dev.em.1.tx_dma_fail: 0
>>>dev.em.1.fc_high_water: 18432
>>>dev.em.1.fc_low_water: 16932
>>>dev.em.1.mac_stats.excess_coll: 0
>>>dev.em.1.mac_stats.symbol_errors: 0
>>>dev.em.1.mac_stats.sequence_errors: 0
>>>dev.em.1.mac_stats.defer_count: 0
>>>dev.em.1.mac_stats.missed_packets: 41522
>>>dev.em.1.mac_stats.recv_no_buff: 19
>>>dev.em.1.mac_stats.recv_errs: 0
>>>dev.em.1.mac_stats.crc_errs: 0
>>>dev.em.1.mac_stats.alignment_errs: 0
>>>dev.em.1.mac_stats.coll_ext_errs: 0
>>>dev.em.1.mac_stats.rx_overruns: 41398
>>>dev.em.1.mac_stats.watchdog_timeouts: 0
>>>dev.em.1.mac_stats.xon_recvd: 0
>>>dev.em.1.mac_stats.xon_txd: 0
>>>dev.em.1.mac_stats.xoff_recvd: 0
>>>dev.em.1.mac_stats.xoff_txd: 0
>>>dev.em.1.mac_stats.total_pkts_recvd: 95229129
>>>dev.em.1.mac_stats.good_pkts_recvd: 95187607
>>>dev.em.1.mac_stats.bcast_pkts_recvd: 79244
>>>dev.em.1.mac_stats.mcast_pkts_recvd: 0
>>>dev.em.1.mac_stats.rx_frames_64: 93680
>>>dev.em.1.mac_stats.rx_frames_65_127: 1516349
>>>dev.em.1.mac_stats.rx_frames_128_255: 4464941
>>>dev.em.1.mac_stats.rx_frames_256_511: 4024
>>>dev.em.1.mac_stats.rx_frames_512_1023: 2096067
>>>dev.em.1.mac_stats.rx_frames_1024_1522: 87012546
>>>dev.em.1.mac_stats.good_octets_recvd: 0
>>>dev.em.1.mac_stats.good_octest_txd: 0
>>>dev.em.1.mac_stats.total_pkts_txd: 66775098
>>>dev.em.1.mac_stats.good_pkts_txd: 66775098
>>>dev.em.1.mac_stats.bcast_pkts_txd: 509
>>>dev.em.1.mac_stats.mcast_pkts_txd: 7
>>>dev.em.1.mac_stats.tx_frames_64: 48038472
>>>dev.em.1.mac_stats.tx_frames_65_127: 13402833
>>>dev.em.1.mac_stats.tx_frames_128_255: 5324413
>>>dev.em.1.mac_stats.tx_frames_256_511: 957
>>>dev.em.1.mac_stats.tx_frames_512_1023: 319
>>>dev.em.1.mac_stats.tx_frames_1024_1522: 8104
>>>dev.em.1.mac_stats.tso_txd: 1069
>>>dev.em.1.mac_stats.tso_ctx_fail: 0
>>>dev.em.1.interrupts.asserts: 0
>>>dev.em.1.interrupts.rx_pkt_timer: 0
>>>dev.em.1.interrupts.rx_abs_timer: 0
>>>dev.em.1.interrupts.tx_pkt_timer: 0
>>>dev.em.1.interrupts.tx_abs_timer: 0
>>>dev.em.1.interrupts.tx_queue_empty: 0
>>>dev.em.1.interrupts.tx_queue_min_thresh: 0
>>>dev.em.1.interrupts.rx_desc_min_thresh: 0
>>>dev.em.1.interrupts.rx_overrun: 0
>>>dev.em.1.host.breaker_tx_pkt: 0
>>>dev.em.1.host.host_tx_pkt_discard: 0
>>>dev.em.1.host.rx_pkt: 0
>>>dev.em.1.host.breaker_rx_pkts: 0
>>>dev.em.1.host.breaker_rx_pkt_drop: 0
>>>dev.em.1.host.tx_good_pkt: 0
>>>dev.em.1.host.breaker_tx_pkt_drop: 0
>>>dev.em.1.host.rx_good_bytes: 0
>>>dev.em.1.host.tx_good_bytes: 0
>>>dev.em.1.host.length_errors: 0
>>>dev.em.1.host.serdes_violation_pkt: 0
>>>dev.em.1.host.header_redir_missed: 0
>>>
>>>ifconfig down/up just panics or locks up the box when its in this
>>>state. I also have IPMI enabled on this nic, but it shows the
>>>same issue with it disabled.
>>>
>>> ---Mike
>>>
>>>
>>>
>>>--------------------------------------------------------------------
>>>Mike Tancsa, tel +1 519 651 3400
>>>Sentex Communications, <mailto:mike at sentex.net>mike at sentex.net
>>>Providing Internet since
>>>1994 <http://www.sentex.net>www.sentex.net
>>>Cambridge, Ontario
>>>Canada <http://www.sentex.net/mike>www.sentex.net/mike
>>
>>--------------------------------------------------------------------
>>Mike Tancsa, tel +1 519 651 3400
>>Sentex Communications, mike at sentex.net
>>Providing Internet since 1994 www.sentex.net
>>Cambridge, Ontario Canada www.sentex.net/mike
>>
>>_______________________________________________
>>freebsd-stable at freebsd.org mailing list
>>http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>>To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>
>--------------------------------------------------------------------
>Mike Tancsa, tel +1 519 651 3400
>Sentex Communications, mike at sentex.net
>Providing Internet since 1994 www.sentex.net
>Cambridge, Ontario Canada www.sentex.net/mike
>
>_______________________________________________
>freebsd-stable at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
More information about the freebsd-stable
mailing list