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)
e...@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:m...@sentex.net>m...@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
e...@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:m...@sentex.net>m...@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, m...@sentex.net
Providing Internet since 1994 www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
--------------------------------------------------------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet since 1994 www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
