Date: Tue, 23 Nov 2010 09:06:20 -0500 From: Mike Tancsa <mike@sentex.net> To: freebsd-stable@freebsd.org Subject: Re: RELENG_7 em problems (and RELENG_8) Message-ID: <201011231406.oANE6Wq0067461@lava.sentex.ca> In-Reply-To: <201011071722.oA7HMHUQ037325@lava.sentex.ca> References: <201006102031.o5AKVCH2016467@lava.sentex.ca> <201007021739.o62HdMOU092319@lava.sentex.ca> <20100702193654.GD10862@michelle.cdnetworks.com> <201008162107.o7GL76pA080191@lava.sentex.ca> <20100817185208.GA6482@michelle.cdnetworks.com> <201008171955.o7HJt67T087902@lava.sentex.ca> <20100817200020.GE6482@michelle.cdnetworks.com> <201009141759.o8EHxcZ0013539@lava.sentex.ca> <AANLkTimiTmA1HHeWmGm1MAFf-H=OqC17vwZvFWpgcHCZ@mail.gmail.com> <201009262157.o8QLvR0L012171@lava.sentex.ca> <AANLkTinxLScVxQ2ib%2BcLXEBGTATAU36%2BOKr7%2B5SQXE89@mail.gmail.com> <201009262343.o8QNhgDG012676@lava.sentex.ca> <201011071722.oA7HMHUQ037325@lava.sentex.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@sentex.net>mike@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@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@sentex.net>mike@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@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-unsubscribe@freebsd.org" > >-------------------------------------------------------------------- >Mike Tancsa, tel +1 519 651 3400 >Sentex Communications, mike@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-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201011231406.oANE6Wq0067461>