From owner-freebsd-net@FreeBSD.ORG Sun Aug 31 15:19:52 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D4A05A9 for ; Sun, 31 Aug 2014 15:19:52 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C98911F7 for ; Sun, 31 Aug 2014 15:19:51 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 9ABA2139C8 for ; Sun, 31 Aug 2014 12:15:07 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type:subject :subject:to:mime-version:user-agent:from:from:date:date :message-id; s=dkim; t=1409498106; x=1410362107; bh=xJskYGTZKorR SEfti9bPj0XMbRFgRaf9XSjUaQ3gbjs=; b=aGwWQLxTGSnmR1IeHZvE8ACPA3KQ 6DKzgUZM2zrVlYjPJnOMe4FlIhoz6LFGsXHHVfk9Aau5ldpRCZZuFa3aU0jXUUOP 4BJZAmzZS8z29oMRl4XteqiJ1i6UQsSmSEK6qA8dab9oBfGJrDJsqpZBmHx1BsME QLAQwD4JH6aA1hI= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7PSetfx-Val for ; Sun, 31 Aug 2014 12:15:06 -0300 (BRT) Received: from [127.0.0.1] (unknown [186.193.54.69]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id D066B139C4 for ; Sun, 31 Aug 2014 12:15:05 -0300 (BRT) Message-ID: <54033BD2.30608@bsdinfo.com.br> Date: Sun, 31 Aug 2014 12:14:26 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: ipfw table fix Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 140831-0, 31/08/2014), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 15:19:52 -0000 Dear, Could you tell me if this fix will come out in time for version 10.1? # ipfw table 99 add 0.0.0.0/8 # ipfw table 99 list ::/8 0 Thanks and best regards, Gondim --- Este email est=E1 limpo de v=EDrus e malwares porque a prote=E7=E3o do avas= t! Antiv=EDrus est=E1 ativa. http://www.avast.com From owner-freebsd-net@FreeBSD.ORG Mon Sep 1 08:00:13 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2ADA7795 for ; Mon, 1 Sep 2014 08:00:13 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F2D2A14C3 for ; Mon, 1 Sep 2014 08:00:12 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8180CDL088769 for ; Mon, 1 Sep 2014 08:00:12 GMT (envelope-from bugzilla-noreply@freebsd.org) Message-Id: <201409010800.s8180CDL088769@kenobi.freebsd.org> From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bugzilla] Commit Needs MFC MIME-Version: 1.0 X-Bugzilla-Type: whine X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated Date: Mon, 01 Sep 2014 08:00:12 +0000 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 08:00:13 -0000 Hi, You have a bug in the "Needs MFC" state which has not been touched in 7 or more days. This email serves as a reminder that you may want to MFC this bug or marked it as completed. In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days. This reminder is only sent on Mondays. Please file a bug about concerns you may have. This search was scheduled by eadler@FreeBSD.org. (1 bugs) Bug 183659: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183659 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-net@FreeBSD.org Status: Needs MFC Resolution: Summary: [tcp] TCP stack lock contention with short-lived connections From owner-freebsd-net@FreeBSD.ORG Mon Sep 1 09:18:26 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 321953CC for ; Mon, 1 Sep 2014 09:18:26 +0000 (UTC) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx12.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0927C1E29 for ; Mon, 1 Sep 2014 09:18:25 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.04,441,1406617200"; d="asc'?scan'208";a="185487292" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx12-out.netapp.com with ESMTP; 01 Sep 2014 02:18:20 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by vmwexceht04-prd.hq.netapp.com (10.106.77.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 1 Sep 2014 02:17:39 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 1 Sep 2014 02:17:38 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::55e3:a7dc:11bd:462%21]) with mapi id 15.00.0913.011; Mon, 1 Sep 2014 02:17:38 -0700 From: "Eggert, Lars" To: John-Mark Gurney Subject: Re: igb "requests for mbufs denied" Thread-Topic: igb "requests for mbufs denied" Thread-Index: AQHPwpqIzDi3XZpt70OIdoMh57Bi85voomOAgAPZFIA= Date: Mon, 1 Sep 2014 09:17:38 +0000 Message-ID: References: <20140829223233.GL71691@funkthat.com> In-Reply-To: <20140829223233.GL71691@funkthat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_025768C4-3F9F-4E1F-9307-3B7C647642BC"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 09:18:26 -0000 --Apple-Mail=_025768C4-3F9F-4E1F-9307-3B7C647642BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2014-8-30, at 0:32, John-Mark Gurney wrote: > Also, what does sysctl dev.em and sysctl dev.igb show? The box has no em interfaces. [root@laurel: ~] sysctl dev.igb dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.4.0 dev.igb.0.%driver: igb dev.igb.0.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.RP03.LAN1 dev.igb.0.%pnpinfo: vendor=3D0x8086 device=3D0x1533 subvendor=3D0x1734 = subdevice=3D0x11f1 class=3D0x020000 dev.igb.0.%parent: pci4 dev.igb.0.nvm: -1 dev.igb.0.enable_aim: 1 dev.igb.0.fc: 3 dev.igb.0.rx_processing_limit: 100 dev.igb.0.dmac: 0 dev.igb.0.eee_disabled: 0 dev.igb.0.link_irq: 0 dev.igb.0.dropped: 0 dev.igb.0.tx_dma_fail: 0 dev.igb.0.rx_overruns: 0 dev.igb.0.watchdog_timeouts: 0 dev.igb.0.device_control: 135266881 dev.igb.0.rx_control: 4194304 dev.igb.0.interrupt_mask: 0 dev.igb.0.extended_int_mask: 2147483648 dev.igb.0.tx_buf_alloc: 0 dev.igb.0.rx_buf_alloc: 0 dev.igb.0.fc_high_water: 31328 dev.igb.0.fc_low_water: 31312 dev.igb.0.queue0.no_desc_avail: 0 dev.igb.0.queue0.tx_packets: 0 dev.igb.0.queue0.rx_packets: 0 dev.igb.0.queue0.rx_bytes: 0 dev.igb.0.queue0.lro_queued: 0 dev.igb.0.queue0.lro_flushed: 0 dev.igb.0.mac_stats.excess_coll: 0 dev.igb.0.mac_stats.single_coll: 0 dev.igb.0.mac_stats.multiple_coll: 0 dev.igb.0.mac_stats.late_coll: 0 dev.igb.0.mac_stats.collision_count: 0 dev.igb.0.mac_stats.symbol_errors: 0 dev.igb.0.mac_stats.sequence_errors: 0 dev.igb.0.mac_stats.defer_count: 0 dev.igb.0.mac_stats.missed_packets: 0 dev.igb.0.mac_stats.recv_no_buff: 0 dev.igb.0.mac_stats.recv_undersize: 0 dev.igb.0.mac_stats.recv_fragmented: 0 dev.igb.0.mac_stats.recv_oversize: 0 dev.igb.0.mac_stats.recv_jabber: 0 dev.igb.0.mac_stats.recv_errs: 0 dev.igb.0.mac_stats.crc_errs: 0 dev.igb.0.mac_stats.alignment_errs: 0 dev.igb.0.mac_stats.coll_ext_errs: 0 dev.igb.0.mac_stats.xon_recvd: 0 dev.igb.0.mac_stats.xon_txd: 0 dev.igb.0.mac_stats.xoff_recvd: 0 dev.igb.0.mac_stats.xoff_txd: 0 dev.igb.0.mac_stats.total_pkts_recvd: 0 dev.igb.0.mac_stats.good_pkts_recvd: 0 dev.igb.0.mac_stats.bcast_pkts_recvd: 0 dev.igb.0.mac_stats.mcast_pkts_recvd: 0 dev.igb.0.mac_stats.rx_frames_64: 0 dev.igb.0.mac_stats.rx_frames_65_127: 0 dev.igb.0.mac_stats.rx_frames_128_255: 0 dev.igb.0.mac_stats.rx_frames_256_511: 0 dev.igb.0.mac_stats.rx_frames_512_1023: 0 dev.igb.0.mac_stats.rx_frames_1024_1522: 0 dev.igb.0.mac_stats.good_octets_recvd: 0 dev.igb.0.mac_stats.good_octets_txd: 0 dev.igb.0.mac_stats.total_pkts_txd: 0 dev.igb.0.mac_stats.good_pkts_txd: 0 dev.igb.0.mac_stats.bcast_pkts_txd: 0 dev.igb.0.mac_stats.mcast_pkts_txd: 0 dev.igb.0.mac_stats.tx_frames_64: 0 dev.igb.0.mac_stats.tx_frames_65_127: 0 dev.igb.0.mac_stats.tx_frames_128_255: 0 dev.igb.0.mac_stats.tx_frames_256_511: 0 dev.igb.0.mac_stats.tx_frames_512_1023: 0 dev.igb.0.mac_stats.tx_frames_1024_1522: 0 dev.igb.0.mac_stats.tso_txd: 0 dev.igb.0.mac_stats.tso_ctx_fail: 0 dev.igb.0.interrupts.asserts: 0 dev.igb.0.interrupts.rx_pkt_timer: 0 dev.igb.0.interrupts.rx_abs_timer: 0 dev.igb.0.interrupts.tx_pkt_timer: 0 dev.igb.0.interrupts.tx_abs_timer: 0 dev.igb.0.interrupts.tx_queue_empty: 0 dev.igb.0.interrupts.tx_queue_min_thresh: 0 dev.igb.0.interrupts.rx_desc_min_thresh: 0 dev.igb.0.interrupts.rx_overrun: 0 dev.igb.0.host.breaker_tx_pkt: 0 dev.igb.0.host.host_tx_pkt_discard: 0 dev.igb.0.host.rx_pkt: 0 dev.igb.0.host.breaker_rx_pkts: 0 dev.igb.0.host.breaker_rx_pkt_drop: 0 dev.igb.0.host.tx_good_pkt: 0 dev.igb.0.host.breaker_tx_pkt_drop: 0 dev.igb.0.host.rx_good_bytes: 0 dev.igb.0.host.tx_good_bytes: 0 dev.igb.0.host.length_errors: 0 dev.igb.0.host.serdes_violation_pkt: 0 dev.igb.0.host.header_redir_missed: 0 dev.igb.1.%desc: Intel(R) PRO/1000 Network Connection version - 2.4.0 dev.igb.1.%driver: igb dev.igb.1.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.RP04.LAN2 dev.igb.1.%pnpinfo: vendor=3D0x8086 device=3D0x1533 subvendor=3D0x1734 = subdevice=3D0x11f1 class=3D0x020000 dev.igb.1.%parent: pci5 dev.igb.1.nvm: -1 dev.igb.1.enable_aim: 1 dev.igb.1.fc: 3 dev.igb.1.rx_processing_limit: 100 dev.igb.1.dmac: 0 dev.igb.1.eee_disabled: 0 dev.igb.1.link_irq: 0 dev.igb.1.dropped: 0 dev.igb.1.tx_dma_fail: 0 dev.igb.1.rx_overruns: 0 dev.igb.1.watchdog_timeouts: 0 dev.igb.1.device_control: 135266881 dev.igb.1.rx_control: 4194304 dev.igb.1.interrupt_mask: 0 dev.igb.1.extended_int_mask: 2147483648 dev.igb.1.tx_buf_alloc: 0 dev.igb.1.rx_buf_alloc: 0 dev.igb.1.fc_high_water: 31328 dev.igb.1.fc_low_water: 31312 dev.igb.1.queue0.no_desc_avail: 0 dev.igb.1.queue0.tx_packets: 0 dev.igb.1.queue0.rx_packets: 0 dev.igb.1.queue0.rx_bytes: 0 dev.igb.1.queue0.lro_queued: 0 dev.igb.1.queue0.lro_flushed: 0 dev.igb.1.mac_stats.excess_coll: 0 dev.igb.1.mac_stats.single_coll: 0 dev.igb.1.mac_stats.multiple_coll: 0 dev.igb.1.mac_stats.late_coll: 0 dev.igb.1.mac_stats.collision_count: 0 dev.igb.1.mac_stats.symbol_errors: 0 dev.igb.1.mac_stats.sequence_errors: 0 dev.igb.1.mac_stats.defer_count: 0 dev.igb.1.mac_stats.missed_packets: 0 dev.igb.1.mac_stats.recv_no_buff: 0 dev.igb.1.mac_stats.recv_undersize: 0 dev.igb.1.mac_stats.recv_fragmented: 0 dev.igb.1.mac_stats.recv_oversize: 0 dev.igb.1.mac_stats.recv_jabber: 0 dev.igb.1.mac_stats.recv_errs: 0 dev.igb.1.mac_stats.crc_errs: 0 dev.igb.1.mac_stats.alignment_errs: 0 dev.igb.1.mac_stats.coll_ext_errs: 0 dev.igb.1.mac_stats.xon_recvd: 0 dev.igb.1.mac_stats.xon_txd: 0 dev.igb.1.mac_stats.xoff_recvd: 0 dev.igb.1.mac_stats.xoff_txd: 0 dev.igb.1.mac_stats.total_pkts_recvd: 0 dev.igb.1.mac_stats.good_pkts_recvd: 0 dev.igb.1.mac_stats.bcast_pkts_recvd: 0 dev.igb.1.mac_stats.mcast_pkts_recvd: 0 dev.igb.1.mac_stats.rx_frames_64: 0 dev.igb.1.mac_stats.rx_frames_65_127: 0 dev.igb.1.mac_stats.rx_frames_128_255: 0 dev.igb.1.mac_stats.rx_frames_256_511: 0 dev.igb.1.mac_stats.rx_frames_512_1023: 0 dev.igb.1.mac_stats.rx_frames_1024_1522: 0 dev.igb.1.mac_stats.good_octets_recvd: 0 dev.igb.1.mac_stats.good_octets_txd: 0 dev.igb.1.mac_stats.total_pkts_txd: 0 dev.igb.1.mac_stats.good_pkts_txd: 0 dev.igb.1.mac_stats.bcast_pkts_txd: 0 dev.igb.1.mac_stats.mcast_pkts_txd: 0 dev.igb.1.mac_stats.tx_frames_64: 0 dev.igb.1.mac_stats.tx_frames_65_127: 0 dev.igb.1.mac_stats.tx_frames_128_255: 0 dev.igb.1.mac_stats.tx_frames_256_511: 0 dev.igb.1.mac_stats.tx_frames_512_1023: 0 dev.igb.1.mac_stats.tx_frames_1024_1522: 0 dev.igb.1.mac_stats.tso_txd: 0 dev.igb.1.mac_stats.tso_ctx_fail: 0 dev.igb.1.interrupts.asserts: 0 dev.igb.1.interrupts.rx_pkt_timer: 0 dev.igb.1.interrupts.rx_abs_timer: 0 dev.igb.1.interrupts.tx_pkt_timer: 0 dev.igb.1.interrupts.tx_abs_timer: 0 dev.igb.1.interrupts.tx_queue_empty: 0 dev.igb.1.interrupts.tx_queue_min_thresh: 0 dev.igb.1.interrupts.rx_desc_min_thresh: 0 dev.igb.1.interrupts.rx_overrun: 0 dev.igb.1.host.breaker_tx_pkt: 0 dev.igb.1.host.host_tx_pkt_discard: 0 dev.igb.1.host.rx_pkt: 0 dev.igb.1.host.breaker_rx_pkts: 0 dev.igb.1.host.breaker_rx_pkt_drop: 0 dev.igb.1.host.tx_good_pkt: 0 dev.igb.1.host.breaker_tx_pkt_drop: 0 dev.igb.1.host.rx_good_bytes: 0 dev.igb.1.host.tx_good_bytes: 0 dev.igb.1.host.length_errors: 0 dev.igb.1.host.serdes_violation_pkt: 0 dev.igb.1.host.header_redir_missed: 0 dev.igb.2.%desc: Intel(R) PRO/1000 Network Connection version - 2.4.0 dev.igb.2.%driver: igb dev.igb.2.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.RP05.PXSX dev.igb.2.%pnpinfo: vendor=3D0x8086 device=3D0x150e subvendor=3D0x8086 = subdevice=3D0x12a2 class=3D0x020000 dev.igb.2.%parent: pci6 dev.igb.2.nvm: -1 dev.igb.2.enable_aim: 1 dev.igb.2.fc: 3 dev.igb.2.rx_processing_limit: 100 dev.igb.2.link_irq: 2 dev.igb.2.dropped: 0 dev.igb.2.tx_dma_fail: 0 dev.igb.2.rx_overruns: 0 dev.igb.2.watchdog_timeouts: 0 dev.igb.2.device_control: 1221591617 dev.igb.2.rx_control: 67141634 dev.igb.2.interrupt_mask: 4 dev.igb.2.extended_int_mask: 2147483651 dev.igb.2.tx_buf_alloc: 0 dev.igb.2.rx_buf_alloc: 0 dev.igb.2.fc_high_water: 33168 dev.igb.2.fc_low_water: 33152 dev.igb.2.queue0.no_desc_avail: 0 dev.igb.2.queue0.tx_packets: 306966 dev.igb.2.queue0.rx_packets: 3457514 dev.igb.2.queue0.rx_bytes: 969397519 dev.igb.2.queue0.lro_queued: 0 dev.igb.2.queue0.lro_flushed: 0 dev.igb.2.mac_stats.excess_coll: 0 dev.igb.2.mac_stats.single_coll: 0 dev.igb.2.mac_stats.multiple_coll: 0 dev.igb.2.mac_stats.late_coll: 0 dev.igb.2.mac_stats.collision_count: 0 dev.igb.2.mac_stats.symbol_errors: 0 dev.igb.2.mac_stats.sequence_errors: 0 dev.igb.2.mac_stats.defer_count: 0 dev.igb.2.mac_stats.missed_packets: 0 dev.igb.2.mac_stats.recv_no_buff: 0 dev.igb.2.mac_stats.recv_undersize: 0 dev.igb.2.mac_stats.recv_fragmented: 0 dev.igb.2.mac_stats.recv_oversize: 0 dev.igb.2.mac_stats.recv_jabber: 0 dev.igb.2.mac_stats.recv_errs: 0 dev.igb.2.mac_stats.crc_errs: 0 dev.igb.2.mac_stats.alignment_errs: 0 dev.igb.2.mac_stats.coll_ext_errs: 0 dev.igb.2.mac_stats.xon_recvd: 0 dev.igb.2.mac_stats.xon_txd: 0 dev.igb.2.mac_stats.xoff_recvd: 0 dev.igb.2.mac_stats.xoff_txd: 0 dev.igb.2.mac_stats.total_pkts_recvd: 3557355 dev.igb.2.mac_stats.good_pkts_recvd: 3457471 dev.igb.2.mac_stats.bcast_pkts_recvd: 2816429 dev.igb.2.mac_stats.mcast_pkts_recvd: 97826 dev.igb.2.mac_stats.rx_frames_64: 2711291 dev.igb.2.mac_stats.rx_frames_65_127: 79710 dev.igb.2.mac_stats.rx_frames_128_255: 107918 dev.igb.2.mac_stats.rx_frames_256_511: 26082 dev.igb.2.mac_stats.rx_frames_512_1023: 39103 dev.igb.2.mac_stats.rx_frames_1024_1522: 493367 dev.igb.2.mac_stats.good_octets_recvd: 983224310 dev.igb.2.mac_stats.good_octets_txd: 22508632 dev.igb.2.mac_stats.total_pkts_txd: 306857 dev.igb.2.mac_stats.good_pkts_txd: 306857 dev.igb.2.mac_stats.bcast_pkts_txd: 2 dev.igb.2.mac_stats.mcast_pkts_txd: 7 dev.igb.2.mac_stats.tx_frames_64: 2762 dev.igb.2.mac_stats.tx_frames_65_127: 301853 dev.igb.2.mac_stats.tx_frames_128_255: 2173 dev.igb.2.mac_stats.tx_frames_256_511: 20 dev.igb.2.mac_stats.tx_frames_512_1023: 19 dev.igb.2.mac_stats.tx_frames_1024_1522: 30 dev.igb.2.mac_stats.tso_txd: 0 dev.igb.2.mac_stats.tso_ctx_fail: 0 dev.igb.2.interrupts.asserts: 3098990 dev.igb.2.interrupts.rx_pkt_timer: 3457365 dev.igb.2.interrupts.rx_abs_timer: 0 dev.igb.2.interrupts.tx_pkt_timer: 0 dev.igb.2.interrupts.tx_abs_timer: 0 dev.igb.2.interrupts.tx_queue_empty: 306856 dev.igb.2.interrupts.tx_queue_min_thresh: 4015036 dev.igb.2.interrupts.rx_desc_min_thresh: 0 dev.igb.2.interrupts.rx_overrun: 0 dev.igb.2.host.breaker_tx_pkt: 0 dev.igb.2.host.host_tx_pkt_discard: 0 dev.igb.2.host.rx_pkt: 106 dev.igb.2.host.breaker_rx_pkts: 0 dev.igb.2.host.breaker_rx_pkt_drop: 0 dev.igb.2.host.tx_good_pkt: 1 dev.igb.2.host.breaker_tx_pkt_drop: 0 dev.igb.2.host.rx_good_bytes: 983224310 dev.igb.2.host.tx_good_bytes: 22508632 dev.igb.2.host.length_errors: 0 dev.igb.2.host.serdes_violation_pkt: 0 dev.igb.2.host.header_redir_missed: 0 dev.igb.2.wake: 0 dev.igb.3.%desc: Intel(R) PRO/1000 Network Connection version - 2.4.0 dev.igb.3.%driver: igb dev.igb.3.%location: slot=3D0 function=3D1 dev.igb.3.%pnpinfo: vendor=3D0x8086 device=3D0x150e subvendor=3D0x8086 = subdevice=3D0x12a2 class=3D0x020000 dev.igb.3.%parent: pci6 dev.igb.3.nvm: -1 dev.igb.3.enable_aim: 1 dev.igb.3.fc: 3 dev.igb.3.rx_processing_limit: 100 dev.igb.3.link_irq: 2 dev.igb.3.dropped: 0 dev.igb.3.tx_dma_fail: 0 dev.igb.3.rx_overruns: 0 dev.igb.3.watchdog_timeouts: 0 dev.igb.3.device_control: 1087373889 dev.igb.3.rx_control: 67141634 dev.igb.3.interrupt_mask: 4 dev.igb.3.extended_int_mask: 2147483651 dev.igb.3.tx_buf_alloc: 0 dev.igb.3.rx_buf_alloc: 0 dev.igb.3.fc_high_water: 33168 dev.igb.3.fc_low_water: 33152 dev.igb.3.queue0.no_desc_avail: 0 dev.igb.3.queue0.tx_packets: 886989 dev.igb.3.queue0.rx_packets: 547678 dev.igb.3.queue0.rx_bytes: 40365412 dev.igb.3.queue0.lro_queued: 0 dev.igb.3.queue0.lro_flushed: 0 dev.igb.3.mac_stats.excess_coll: 0 dev.igb.3.mac_stats.single_coll: 0 dev.igb.3.mac_stats.multiple_coll: 0 dev.igb.3.mac_stats.late_coll: 0 dev.igb.3.mac_stats.collision_count: 0 dev.igb.3.mac_stats.symbol_errors: 0 dev.igb.3.mac_stats.sequence_errors: 0 dev.igb.3.mac_stats.defer_count: 0 dev.igb.3.mac_stats.missed_packets: 0 dev.igb.3.mac_stats.recv_no_buff: 0 dev.igb.3.mac_stats.recv_undersize: 0 dev.igb.3.mac_stats.recv_fragmented: 0 dev.igb.3.mac_stats.recv_oversize: 0 dev.igb.3.mac_stats.recv_jabber: 0 dev.igb.3.mac_stats.recv_errs: 0 dev.igb.3.mac_stats.crc_errs: 0 dev.igb.3.mac_stats.alignment_errs: 0 dev.igb.3.mac_stats.coll_ext_errs: 0 dev.igb.3.mac_stats.xon_recvd: 0 dev.igb.3.mac_stats.xon_txd: 0 dev.igb.3.mac_stats.xoff_recvd: 0 dev.igb.3.mac_stats.xoff_txd: 0 dev.igb.3.mac_stats.total_pkts_recvd: 1090438 dev.igb.3.mac_stats.good_pkts_recvd: 547678 dev.igb.3.mac_stats.bcast_pkts_recvd: 36046 dev.igb.3.mac_stats.mcast_pkts_recvd: 5053 dev.igb.3.mac_stats.rx_frames_64: 50976 dev.igb.3.mac_stats.rx_frames_65_127: 475752 dev.igb.3.mac_stats.rx_frames_128_255: 20056 dev.igb.3.mac_stats.rx_frames_256_511: 690 dev.igb.3.mac_stats.rx_frames_512_1023: 130 dev.igb.3.mac_stats.rx_frames_1024_1522: 74 dev.igb.3.mac_stats.good_octets_recvd: 42556124 dev.igb.3.mac_stats.good_octets_txd: 1265679425 dev.igb.3.mac_stats.total_pkts_txd: 886989 dev.igb.3.mac_stats.good_pkts_txd: 886989 dev.igb.3.mac_stats.bcast_pkts_txd: 671 dev.igb.3.mac_stats.mcast_pkts_txd: 669 dev.igb.3.mac_stats.tx_frames_64: 15191 dev.igb.3.mac_stats.tx_frames_65_127: 29757 dev.igb.3.mac_stats.tx_frames_128_255: 464 dev.igb.3.mac_stats.tx_frames_256_511: 395 dev.igb.3.mac_stats.tx_frames_512_1023: 16442 dev.igb.3.mac_stats.tx_frames_1024_1522: 824740 dev.igb.3.mac_stats.tso_txd: 0 dev.igb.3.mac_stats.tso_ctx_fail: 0 dev.igb.3.interrupts.asserts: 458310 dev.igb.3.interrupts.rx_pkt_timer: 547673 dev.igb.3.interrupts.rx_abs_timer: 0 dev.igb.3.interrupts.tx_pkt_timer: 0 dev.igb.3.interrupts.tx_abs_timer: 0 dev.igb.3.interrupts.tx_queue_empty: 886976 dev.igb.3.interrupts.tx_queue_min_thresh: 35 dev.igb.3.interrupts.rx_desc_min_thresh: 0 dev.igb.3.interrupts.rx_overrun: 0 dev.igb.3.host.breaker_tx_pkt: 0 dev.igb.3.host.host_tx_pkt_discard: 0 dev.igb.3.host.rx_pkt: 5 dev.igb.3.host.breaker_rx_pkts: 0 dev.igb.3.host.breaker_rx_pkt_drop: 0 dev.igb.3.host.tx_good_pkt: 13 dev.igb.3.host.breaker_tx_pkt_drop: 0 dev.igb.3.host.rx_good_bytes: 42556124 dev.igb.3.host.tx_good_bytes: 1265679425 dev.igb.3.host.length_errors: 0 dev.igb.3.host.serdes_violation_pkt: 0 dev.igb.3.host.header_redir_missed: 0 dev.igb.4.%desc: Intel(R) PRO/1000 Network Connection version - 2.4.0 dev.igb.4.%driver: igb dev.igb.4.%location: slot=3D0 function=3D2 dev.igb.4.%pnpinfo: vendor=3D0x8086 device=3D0x150e subvendor=3D0x8086 = subdevice=3D0x12a2 class=3D0x020000 dev.igb.4.%parent: pci6 dev.igb.4.nvm: -1 dev.igb.4.enable_aim: 1 dev.igb.4.fc: 3 dev.igb.4.rx_processing_limit: 100 dev.igb.4.link_irq: 2 dev.igb.4.dropped: 0 dev.igb.4.tx_dma_fail: 0 dev.igb.4.rx_overruns: 0 dev.igb.4.watchdog_timeouts: 0 dev.igb.4.device_control: 1087373889 dev.igb.4.rx_control: 67141634 dev.igb.4.interrupt_mask: 4 dev.igb.4.extended_int_mask: 2147483651 dev.igb.4.tx_buf_alloc: 0 dev.igb.4.rx_buf_alloc: 0 dev.igb.4.fc_high_water: 33168 dev.igb.4.fc_low_water: 33152 dev.igb.4.queue0.no_desc_avail: 0 dev.igb.4.queue0.tx_packets: 10406 dev.igb.4.queue0.rx_packets: 9922 dev.igb.4.queue0.rx_bytes: 628870 dev.igb.4.queue0.lro_queued: 0 dev.igb.4.queue0.lro_flushed: 0 dev.igb.4.mac_stats.excess_coll: 0 dev.igb.4.mac_stats.single_coll: 0 dev.igb.4.mac_stats.multiple_coll: 0 dev.igb.4.mac_stats.late_coll: 0 dev.igb.4.mac_stats.collision_count: 0 dev.igb.4.mac_stats.symbol_errors: 0 dev.igb.4.mac_stats.sequence_errors: 0 dev.igb.4.mac_stats.defer_count: 0 dev.igb.4.mac_stats.missed_packets: 0 dev.igb.4.mac_stats.recv_no_buff: 0 dev.igb.4.mac_stats.recv_undersize: 0 dev.igb.4.mac_stats.recv_fragmented: 0 dev.igb.4.mac_stats.recv_oversize: 0 dev.igb.4.mac_stats.recv_jabber: 0 dev.igb.4.mac_stats.recv_errs: 0 dev.igb.4.mac_stats.crc_errs: 0 dev.igb.4.mac_stats.alignment_errs: 0 dev.igb.4.mac_stats.coll_ext_errs: 0 dev.igb.4.mac_stats.xon_recvd: 0 dev.igb.4.mac_stats.xon_txd: 0 dev.igb.4.mac_stats.xoff_recvd: 0 dev.igb.4.mac_stats.xoff_txd: 0 dev.igb.4.mac_stats.total_pkts_recvd: 172503 dev.igb.4.mac_stats.good_pkts_recvd: 9922 dev.igb.4.mac_stats.bcast_pkts_recvd: 0 dev.igb.4.mac_stats.mcast_pkts_recvd: 671 dev.igb.4.mac_stats.rx_frames_64: 9251 dev.igb.4.mac_stats.rx_frames_65_127: 671 dev.igb.4.mac_stats.rx_frames_128_255: 0 dev.igb.4.mac_stats.rx_frames_256_511: 0 dev.igb.4.mac_stats.rx_frames_512_1023: 0 dev.igb.4.mac_stats.rx_frames_1024_1522: 0 dev.igb.4.mac_stats.good_octets_recvd: 668558 dev.igb.4.mac_stats.good_octets_txd: 835828 dev.igb.4.mac_stats.total_pkts_txd: 10406 dev.igb.4.mac_stats.good_pkts_txd: 10406 dev.igb.4.mac_stats.bcast_pkts_txd: 485 dev.igb.4.mac_stats.mcast_pkts_txd: 670 dev.igb.4.mac_stats.tx_frames_64: 9252 dev.igb.4.mac_stats.tx_frames_65_127: 668 dev.igb.4.mac_stats.tx_frames_128_255: 2 dev.igb.4.mac_stats.tx_frames_256_511: 484 dev.igb.4.mac_stats.tx_frames_512_1023: 0 dev.igb.4.mac_stats.tx_frames_1024_1522: 0 dev.igb.4.mac_stats.tso_txd: 0 dev.igb.4.mac_stats.tso_ctx_fail: 0 dev.igb.4.interrupts.asserts: 278311 dev.igb.4.interrupts.rx_pkt_timer: 9922 dev.igb.4.interrupts.rx_abs_timer: 0 dev.igb.4.interrupts.tx_pkt_timer: 0 dev.igb.4.interrupts.tx_abs_timer: 0 dev.igb.4.interrupts.tx_queue_empty: 10406 dev.igb.4.interrupts.tx_queue_min_thresh: 0 dev.igb.4.interrupts.rx_desc_min_thresh: 0 dev.igb.4.interrupts.rx_overrun: 0 dev.igb.4.host.breaker_tx_pkt: 0 dev.igb.4.host.host_tx_pkt_discard: 0 dev.igb.4.host.rx_pkt: 0 dev.igb.4.host.breaker_rx_pkts: 0 dev.igb.4.host.breaker_rx_pkt_drop: 0 dev.igb.4.host.tx_good_pkt: 0 dev.igb.4.host.breaker_tx_pkt_drop: 0 dev.igb.4.host.rx_good_bytes: 668558 dev.igb.4.host.tx_good_bytes: 835828 dev.igb.4.host.length_errors: 0 dev.igb.4.host.serdes_violation_pkt: 0 dev.igb.4.host.header_redir_missed: 0 dev.igb.5.%desc: Intel(R) PRO/1000 Network Connection version - 2.4.0 dev.igb.5.%driver: igb dev.igb.5.%location: slot=3D0 function=3D3 dev.igb.5.%pnpinfo: vendor=3D0x8086 device=3D0x150e subvendor=3D0x8086 = subdevice=3D0x12a2 class=3D0x020000 dev.igb.5.%parent: pci6 dev.igb.5.nvm: -1 dev.igb.5.enable_aim: 1 dev.igb.5.fc: 3 dev.igb.5.rx_processing_limit: 100 dev.igb.5.link_irq: 0 dev.igb.5.dropped: 0 dev.igb.5.tx_dma_fail: 0 dev.igb.5.rx_overruns: 0 dev.igb.5.watchdog_timeouts: 0 dev.igb.5.device_control: 147849793 dev.igb.5.rx_control: 0 dev.igb.5.interrupt_mask: 0 dev.igb.5.extended_int_mask: 2147483648 dev.igb.5.tx_buf_alloc: 0 dev.igb.5.rx_buf_alloc: 0 dev.igb.5.fc_high_water: 33168 dev.igb.5.fc_low_water: 33152 dev.igb.5.queue0.no_desc_avail: 0 dev.igb.5.queue0.tx_packets: 0 dev.igb.5.queue0.rx_packets: 0 dev.igb.5.queue0.rx_bytes: 0 dev.igb.5.queue0.lro_queued: 0 dev.igb.5.queue0.lro_flushed: 0 dev.igb.5.mac_stats.excess_coll: 0 dev.igb.5.mac_stats.single_coll: 0 dev.igb.5.mac_stats.multiple_coll: 0 dev.igb.5.mac_stats.late_coll: 0 dev.igb.5.mac_stats.collision_count: 0 dev.igb.5.mac_stats.symbol_errors: 0 dev.igb.5.mac_stats.sequence_errors: 0 dev.igb.5.mac_stats.defer_count: 0 dev.igb.5.mac_stats.missed_packets: 0 dev.igb.5.mac_stats.recv_no_buff: 0 dev.igb.5.mac_stats.recv_undersize: 0 dev.igb.5.mac_stats.recv_fragmented: 0 dev.igb.5.mac_stats.recv_oversize: 0 dev.igb.5.mac_stats.recv_jabber: 0 dev.igb.5.mac_stats.recv_errs: 0 dev.igb.5.mac_stats.crc_errs: 0 dev.igb.5.mac_stats.alignment_errs: 0 dev.igb.5.mac_stats.coll_ext_errs: 0 dev.igb.5.mac_stats.xon_recvd: 0 dev.igb.5.mac_stats.xon_txd: 0 dev.igb.5.mac_stats.xoff_recvd: 0 dev.igb.5.mac_stats.xoff_txd: 0 dev.igb.5.mac_stats.total_pkts_recvd: 0 dev.igb.5.mac_stats.good_pkts_recvd: 0 dev.igb.5.mac_stats.bcast_pkts_recvd: 0 dev.igb.5.mac_stats.mcast_pkts_recvd: 0 dev.igb.5.mac_stats.rx_frames_64: 0 dev.igb.5.mac_stats.rx_frames_65_127: 0 dev.igb.5.mac_stats.rx_frames_128_255: 0 dev.igb.5.mac_stats.rx_frames_256_511: 0 dev.igb.5.mac_stats.rx_frames_512_1023: 0 dev.igb.5.mac_stats.rx_frames_1024_1522: 0 dev.igb.5.mac_stats.good_octets_recvd: 0 dev.igb.5.mac_stats.good_octets_txd: 0 dev.igb.5.mac_stats.total_pkts_txd: 0 dev.igb.5.mac_stats.good_pkts_txd: 0 dev.igb.5.mac_stats.bcast_pkts_txd: 0 dev.igb.5.mac_stats.mcast_pkts_txd: 0 dev.igb.5.mac_stats.tx_frames_64: 0 dev.igb.5.mac_stats.tx_frames_65_127: 0 dev.igb.5.mac_stats.tx_frames_128_255: 0 dev.igb.5.mac_stats.tx_frames_256_511: 0 dev.igb.5.mac_stats.tx_frames_512_1023: 0 dev.igb.5.mac_stats.tx_frames_1024_1522: 0 dev.igb.5.mac_stats.tso_txd: 0 dev.igb.5.mac_stats.tso_ctx_fail: 0 dev.igb.5.interrupts.asserts: 0 dev.igb.5.interrupts.rx_pkt_timer: 0 dev.igb.5.interrupts.rx_abs_timer: 0 dev.igb.5.interrupts.tx_pkt_timer: 0 dev.igb.5.interrupts.tx_abs_timer: 0 dev.igb.5.interrupts.tx_queue_empty: 0 dev.igb.5.interrupts.tx_queue_min_thresh: 0 dev.igb.5.interrupts.rx_desc_min_thresh: 0 dev.igb.5.interrupts.rx_overrun: 0 dev.igb.5.host.breaker_tx_pkt: 0 dev.igb.5.host.host_tx_pkt_discard: 0 dev.igb.5.host.rx_pkt: 0 dev.igb.5.host.breaker_rx_pkts: 0 dev.igb.5.host.breaker_rx_pkt_drop: 0 dev.igb.5.host.tx_good_pkt: 0 dev.igb.5.host.breaker_tx_pkt_drop: 0 dev.igb.5.host.rx_good_bytes: 0 dev.igb.5.host.tx_good_bytes: 0 dev.igb.5.host.length_errors: 0 dev.igb.5.host.serdes_violation_pkt: 0 dev.igb.5.host.header_redir_missed: 0 --Apple-Mail=_025768C4-3F9F-4E1F-9307-3B7C647642BC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVAQ52dZcnpRveo1xAQJmVQQAk9R9yH1bJ6G91Xe7ENw+iwB1kjwKhAxe Aa+8MwBG6niNyY9n0zLsU4VbfZhj6L/oJ7mjIFs+Jr7/BEPONOARjVmRRCMTbjko 2BpgOEaW2weXY4MVZIyJbbNMrWBDLL6zEG1h/FsAGlAX/KU922NBqyC0qsiQWLRl wKn7wbU/otM= =h62E -----END PGP SIGNATURE----- --Apple-Mail=_025768C4-3F9F-4E1F-9307-3B7C647642BC-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 1 09:19:04 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40BDC53E; Mon, 1 Sep 2014 09:19:04 +0000 (UTC) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx12.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1843D1E3B; Mon, 1 Sep 2014 09:19:04 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.04,441,1406617200"; d="asc'?scan'208";a="185487344" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx12-out.netapp.com with ESMTP; 01 Sep 2014 02:19:03 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by vmwexceht01-prd.hq.netapp.com (10.106.76.239) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 1 Sep 2014 02:18:23 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 1 Sep 2014 02:18:22 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::55e3:a7dc:11bd:462%21]) with mapi id 15.00.0913.011; Mon, 1 Sep 2014 02:18:22 -0700 From: "Eggert, Lars" To: Adrian Chadd Subject: Re: igb "requests for mbufs denied" Thread-Topic: igb "requests for mbufs denied" Thread-Index: AQHPwpqIzDi3XZpt70OIdoMh57Bi85voomOAgABzNgCAA2YSAA== Date: Mon, 1 Sep 2014 09:18:21 +0000 Message-ID: References: <20140829223233.GL71691@funkthat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_B0F3BA5F-8EC3-40F4-9F3B-7A909E8CC473"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 09:19:04 -0000 --Apple-Mail=_B0F3BA5F-8EC3-40F4-9F3B-7A909E8CC473 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 2014-8-30, at 7:24, Adrian Chadd wrote: > What's the output of vmstat -z ? [root@laurel: ~] vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 384, 0, 99, 1, 99, 0, 0 UMA Zones: 1152, 0, 99, 0, 99, 0, 0 UMA Slabs: 80, 0, 15827, 23, 56426, 0, 0 UMA RCntSlabs: 88, 0, 2283, 12, 2283, 0, 0 UMA Hash: 256, 0, 5, 10, 8, 0, 0 4 Bucket: 32, 0, 40, 835, 97770, 0, 0 8 Bucket: 64, 0, 168, 514, 95742, 0, 0 16 Bucket: 128, 0, 91, 715, 44919, 202, 0 32 Bucket: 256, 0, 3084, 1386, 32197, 106, 0 64 Bucket: 512, 0, 1579, 2805, 37281, 101, 0 128 Bucket: 1024, 0, 2043, 361, 69687,82929, 0 vmem btag: 56, 0, 48977, 12722, 346536, 869, 0 VM OBJECT: 256, 0, 154107, 348, 389148, 0, 0 RADIX NODE: 144, 0, 184412, 22624, 674520, 49, 0 MAP: 240, 0, 3, 61, 3, 0, 0 KMAP ENTRY: 128, 0, 9, 394, 9, 0, 0 MAP ENTRY: 128, 0, 760, 1131, 430304, 0, 0 VMSPACE: 448, 0, 28, 179, 11739, 0, 0 fakepg: 104, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 360, 0, 360, 0, 0 16: 16, 0, 4012, 506, 518238, 0, 0 32: 32, 0, 3760, 615, 36818, 0, 0 64: 64, 0, 14097, 74625, 3633439, 0, 0 128: 128, 0, 8331, 125930, 1771231, 0, 0 256: 256, 0, 1027, 82298, 1877944, 0, 0 512: 512, 0, 854, 95994, 345637, 0, 0 1024: 1024, 0, 84, 168, 93998, 0, 0 2048: 2048, 0, 631, 733, 22957, 0, 0 4096: 4096, 0, 501, 32, 14417, 0, 0 SLEEPQUEUE: 80, 0, 193, 458, 193, 0, 0 uint64 pcpu: 8, 0, 1602, 62, 1602, 0, 0 Files: 80, 0, 147, 603, 1158104, 0, 0 TURNSTILE: 136, 0, 193, 187, 193, 0, 0 rl_entry: 40, 0, 86, 414, 86, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1208, 0, 53, 52, 11825, 0, 0 THREAD: 1168, 0, 171, 21, 189, 0, 0 cpuset: 72, 0, 87, 463, 149, 0, 0 audit_record: 1248, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 52127340, 3069, 791, 4919006,3110, 0 mbuf: 256, 52127340, 1, 2259, 5017862,1247, 0 mbuf_cluster: 2048, 8144896, 3860, 682, 583821,3377, 0 mbuf_jumbo_page: 4096, 1018097, 0, 12, 150937, 5, 0 mbuf_jumbo_9k: 9216, 301658, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 169682, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 g_bio: 248, 0, 0, 11088,12456274, 0, 0 ttyinq: 160, 0, 210, 240, 705, 0, 0 ttyoutq: 256, 0, 109, 206, 367, 0, 0 ata_request: 336, 0, 0, 0, 0, 0, 0 vtnet_tx_hdr: 24, 0, 0, 0, 0, 0, 0 cryptop: 88, 0, 0, 0, 0, 0, 0 cryptodesc: 72, 0, 0, 0, 0, 0, 0 FPU_save_area: 832, 0, 0, 0, 0, 0, 0 VNODE: 472, 0, 308616, 152, 2156908, 0, 0 VNODEPOLL: 112, 0, 0, 0, 0, 0, 0 BUF TRIE: 144, 0, 951, 104997, 271764, 0, 0 NAMEI: 1024, 0, 0, 68, 6635607, 0, 0 S VFS Cache: 108, 0, 284884, 25741, 2028838, 0, 0 STS VFS Cache: 148, 0, 0, 0, 0, 0, 0 L VFS Cache: 328, 0, 33803, 805, 275904, 0, 0 LTS VFS Cache: 368, 0, 10, 80, 30, 0, 0 DIRHASH: 1024, 0, 2828, 8, 4099, 0, 0 NCLNODE: 528, 0, 14, 28, 14, 0, 0 fuse_ticket: 224, 0, 0, 0, 0, 0, 0 Mountpoints: 816, 0, 11, 44, 11, 0, 0 pipe: 744, 0, 3, 77, 5707, 0, 0 procdesc: 128, 0, 0, 0, 0, 0, 0 ksiginfo: 112, 0, 92, 958, 972621, 0, 0 itimer: 352, 0, 1, 32, 1, 0, 0 KNOTE: 128, 0, 23, 628, 325646, 0, 0 socket: 696, 1045215, 83, 77, 22905, 0, 0 unpcb: 240, 1045216, 15, 241, 4010, 0, 0 ipq: 56, 254535, 0, 0, 0, 0, 0 udp_inpcb: 392, 1045220, 37, 143, 18713, 0, 0 udpcb: 16, 1045415, 37, 716, 18713, 0, 0 tcp_inpcb: 392, 1045220, 26, 94, 153, 0, 0 tcpcb: 1024, 1045216, 26, 54, 153, 0, 0 tcptw: 88, 27810, 0, 270, 18, 0, 0 syncache: 160, 15375, 0, 250, 13, 0, 0 hostcache: 136, 15370, 1, 144, 14, 0, 0 tcpreass: 40, 509100, 0, 200, 65, 0, 0 sackhole: 32, 0, 0, 250, 45, 0, 0 sctp_ep: 1408, 1045216, 0, 0, 0, 0, 0 sctp_asoc: 2352, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80012, 0, 415, 10, 0, 0 sctp_raddr: 728, 80000, 0, 0, 0, 0, 0 sctp_chunk: 136, 400026, 0, 0, 0, 0, 0 sctp_readq: 104, 400026, 0, 0, 0, 0, 0 sctp_stream_msg_out: 104, 400026, 0, 0, 0, 0, 0 sctp_asconf: 40, 400000, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400060, 0, 0, 0, 0, 0 ripcb: 392, 1045220, 2, 118, 20, 0, 0 rtentry: 200, 0, 34, 226, 34, 0, 0 selfd: 56, 0, 96, 685, 4425576, 0, 0 SWAPMETA: 288, 4072393, 0, 0, 0, 0, 0 FFS inode: 168, 0, 308570, 228, 2156771, 0, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 308570, 220, 2156771, 0, 0 IPFW dynamic rule: 120, 4125, 0, 0, 0, 0, 0 --Apple-Mail=_B0F3BA5F-8EC3-40F4-9F3B-7A909E8CC473 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVAQ6BNZcnpRveo1xAQL3xQQAplpZ0vf/z8dtkt39BK1zoBdmVHEqDHJE xw6l+N4YlVNu6pCbnSgmr3J7iFzJOKki/dimZV+74A27OSfo4mCpg3E2RuxMCWnd BUYFluaE6YIzzeZd+uuLFb+fU8Znip0tffhBBWwmnI8XXtDH/y9bvV+mg1ZFtiOc 3TGSMXekV4w= =madJ -----END PGP SIGNATURE----- --Apple-Mail=_B0F3BA5F-8EC3-40F4-9F3B-7A909E8CC473-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 1 09:19:54 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A07C5DB for ; Mon, 1 Sep 2014 09:19:54 +0000 (UTC) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx12.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E5DFF1E4C for ; Mon, 1 Sep 2014 09:19:53 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.04,441,1406617200"; d="asc'?scan'208";a="185487452" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx12-out.netapp.com with ESMTP; 01 Sep 2014 02:19:53 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by vmwexceht01-prd.hq.netapp.com (10.106.76.239) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 1 Sep 2014 02:19:12 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 1 Sep 2014 02:19:11 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::55e3:a7dc:11bd:462%21]) with mapi id 15.00.0913.011; Mon, 1 Sep 2014 02:19:05 -0700 From: "Eggert, Lars" To: Carlos Ferreira Subject: Re: tutorial on Netmap in Mountain View - Aug.28 Thread-Topic: tutorial on Netmap in Mountain View - Aug.28 Thread-Index: AQHPr8w/OJgYMqrfQESP3X3y/E75I5vWtEeAgBXtNoA= Date: Mon, 1 Sep 2014 09:19:05 +0000 Message-ID: <7E11AB18-849A-48F0-9103-4E79387F6273@netapp.com> References: <20140804095528.GA12625@onelab2.iet.unipi.it> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_4833C929-CE18-46F6-BC8D-22D61758BCF3"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: FreeBSD Net , Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 09:19:54 -0000 --Apple-Mail=_4833C929-CE18-46F6-BC8D-22D61758BCF3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 2014-8-18, at 12:29, Carlos Ferreira wrote: > Do you have presentations or tutorial code from that tutorial, that you can > share here? +1 Lars --Apple-Mail=_4833C929-CE18-46F6-BC8D-22D61758BCF3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVAQ6MdZcnpRveo1xAQKFXgP/ag+sCPnXGIG6UkCRtPVLVjIUO/CTbEu5 lSgeiWuTs4WBnoz/4KG2WlYdEtixKXk4WjWOox+Fs4uDpJ17JXG2y6mRlJOvZWya cnMU7ObsRNh7BYS//jMpW7v065aGSVLe3fDXqfspFMCFWT4y8nl4bk6tQqctpAZx gFieuwE3Ti0= =RuYi -----END PGP SIGNATURE----- --Apple-Mail=_4833C929-CE18-46F6-BC8D-22D61758BCF3-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 1 19:09:39 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40D3F8D8 for ; Mon, 1 Sep 2014 19:09:39 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C52C1446 for ; Mon, 1 Sep 2014 19:09:38 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s81J9WiT040413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Sep 2014 12:09:32 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s81J9Wca040412; Mon, 1 Sep 2014 12:09:32 -0700 (PDT) (envelope-from jmg) Date: Mon, 1 Sep 2014 12:09:32 -0700 From: John-Mark Gurney To: "Eggert, Lars" Subject: Re: igb "requests for mbufs denied" Message-ID: <20140901190932.GV71691@funkthat.com> Mail-Followup-To: "Eggert, Lars" , FreeBSD Net References: <20140829223233.GL71691@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 01 Sep 2014 12:09:32 -0700 (PDT) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 19:09:39 -0000 Eggert, Lars wrote this message on Mon, Sep 01, 2014 at 09:17 +0000: > On 2014-8-30, at 0:32, John-Mark Gurney wrote: > > Also, what does sysctl dev.em and sysctl dev.igb show? > > The box has no em interfaces. Hard to know w/o complete info, i.e. complete dmesg... Still waiting for the other info I requested in my email... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Mon Sep 1 20:53:32 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9027B6F for ; Mon, 1 Sep 2014 20:53:32 +0000 (UTC) Received: from o3.email.wpengine.com (o3.email.wpengine.com [198.37.148.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7876B1017 for ; Mon, 1 Sep 2014 20:53:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=email.wpengine.com; h=to:subject:from:mime-version:content-type; s=smtpapi; bh=+POwZEBwtxmudNBc7p7SK44P+7Q=; b=QMcfiNmUBba83Lqn3MWT1qh7ChEn5 fjaSqGN9UKJ5f00hR7gUFt29B65Q/hClQOpurCwb2T5XXSPmlTOlgB7NJgyEDWd6 CHRSgzglw9liw82YYHadaNEm7neqw83GmoQNgNZIL67I4w+sZ/eMcJxh/Fd13GMU dq3gCvN9FMDfKo= Received: by mf202.sendgrid.net with SMTP id mf202.36963.5404DCC91E 2014-09-01 20:53:30.393888702 +0000 UTC Received: from pod-2836 (li169-211.members.linode.com [173.230.129.211]) by ismtpd-008.iad1.sendgrid.net (SG) with ESMTP id 14832fe75ef.729.240aa4 for ; Mon, 01 Sep 2014 20:53:30 +0000 (GMT) X-SendGrid-User: wpengine-pod-2836 Received: by pod-2836 (Postfix, from userid 33) id 12CEE5506D; Mon, 1 Sep 2014 20:53:30 +0000 (UTC) To: freebsd-net@freebsd.org Subject: Warning : You must confirm your informations ! X-PHP-Originating-Script: 33:zedity.php From: PayPal Inc Message-Id: <20140901205330.12CEE5506D@pod-2836> Date: Mon, 1 Sep 2014 20:53:30 +0000 (UTC) X-SG-EID: ISGKkmHlRE12gnWy0TjFyGQSFR1WnpjQdICm3qu6YxEDbV0KYnxFDsQ9W4Dgt09jN+HAxKrZqR7a5g2qf16hs7/FRP7gpAOJZGreyqBgNVHuKMaJUssLZkQjMwoQyljSiBxnq0gXf9uNvtPXhDGJ4IvPAvkgBpnOrFCj/pFolTc= MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 20:53:32 -0000 PayPal This is an automated email, please do not reply Dear Client, You Must Confirm Your Informations! Please click on the following link to Confirm It: [1]Click here to Confirm Your Account Informations. You Must Confirm Your Information To Save It . Thanks You For Helping, Support Team Need Assistance? We're happy to help by phone at 1-518-741-2708, Monday to Friday 9:00am to 5:00 pm EST, or by email Copyright 2014. All rights reserved. Email ID: 18460 References 1. http://bit.ly/1lEMdxa From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 00:05:39 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6536699E for ; Tue, 2 Sep 2014 00:05:39 +0000 (UTC) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 29ECD1452 for ; Tue, 2 Sep 2014 00:05:38 +0000 (UTC) Received: from lgwl-lstewart2.corp.netflix.com (c110-22-7-57.eburwd3.vic.optusnet.com.au [110.22.7.57]) by lauren.room52.net (Postfix) with ESMTPSA id BCC587E820; Tue, 2 Sep 2014 10:05:35 +1000 (EST) Message-ID: <540509C1.6090006@freebsd.org> Date: Tue, 02 Sep 2014 10:05:21 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Midori Kato Subject: Re: DCTCP implementation References: <5338FF05.1020302@sfc.wide.ad.jp> In-Reply-To: <5338FF05.1020302@sfc.wide.ad.jp> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: "Eggert, Lars" , hiren panchasara , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 00:05:39 -0000 Hi Midori (& Lars), On 03/31/14 16:37, Midori Kato wrote: > Hi FreeBSD developpers, > > I'm Midori Kato. I'm working on the DCTCP implementation in the FreeBSD > with Lars Eggert. I mail you because I would like to ask you a code > review and testing. The attached patch is not good enough to test our > code. Please give me your message. I will send an ECN marking > implmenetation in dummynet and test scripts personally to you. [snip] Firstly, please let me apologise for not providing follow up feedback and review after our initial discussion of your work last year. It was always my intention to come back to this but life has been particularly crazy the past 12 months and I have been unsuccessful in my attempts to keep a number of balls in the air. Hiren has been diligently working on shepherding your code into the FreeBSD source tree and has been prodding me for a review which I finally got around to yesterday. Unfortunately, my understanding is that non developers are unable to interact with the code review system being used, so we're moving the discussion back to the mailing list so that you and others can participate. You can read the review discussion history to date at [1]. Leaving editorial work on the documentation aside for the time being, I'd like to discuss the KPI changes and stack integration aspects of the patch to start with. Specifically: - The ect_handler KPI addition seems redundant to me and I believe the patch can be simplified by removing it entirely. - The ecnpkt_handler KPI addition takes arguments which are too specific to DCTCP, and is too indiscriminate in what it matches i.e. all packets for ECN enabled connections. I would argue we either add a fully generalist hook which would catch all packets of an ESTABLISHED connection, and have the dctcp module check if ECN is enabled or not before continuing processing (not my preferred option), or we extract the essence of what dctcp_ecnpkt_handler() needs to do into a less generic hook or bit of meta data passed in to an existing hook via struct cc_var (I need to study the code a bit more, but will likely strongly push for this option). - I don't believe the code correctly handles the case of dctcp being used on connections which did not successfully negotiate ECN. There is more to discuss but I think getting these high level technical things resolved first will help guide the remainder of the review discussion. Cheers, Lawrence [1] https://reviews.freebsd.org/D604 From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 08:10:00 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D9EFAAB for ; Tue, 2 Sep 2014 08:10:00 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4109C1906 for ; Tue, 2 Sep 2014 08:10:00 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s828A0tr017132 for ; Tue, 2 Sep 2014 08:10:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193246] Bug in multicast bind(), uncovered by Jenkins Date: Tue, 02 Sep 2014 08:10:00 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: rodrigc@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 08:10:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193246 Craig Rodrigues changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |freebsd-java@FreeBSD.org, | |freebsd-net@FreeBSD.org Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 08:21:31 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA99FE77 for ; Tue, 2 Sep 2014 08:21:31 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A14201AB3 for ; Tue, 2 Sep 2014 08:21:31 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s828LVq7055087 for ; Tue, 2 Sep 2014 08:21:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193246] Bug in multicast bind(), uncovered by Jenkins Date: Tue, 02 Sep 2014 08:21:31 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: rodrigc@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 08:21:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193246 --- Comment #1 from Craig Rodrigues --- Previously, I reported some error messages reported by Jenkins on startup: http://lists.freebsd.org/pipermail/freebsd-java/2014-February/010593.html I looked at the Jenkins source code, and isolated the problem. I wrote this simple testcase (see attached MulticastTest.java), which I am also including inline: ================================================================================ /* * To build this test, * (1) Make sure that the OpenJDK is installed from ports: * * pkg install openjdk * * (2) Rename this file to: MulticastTest.java * (3) Build it: * * javac MulticastTest.java * * (4) Run it: * * java MulticastTest.java * */ import java.net.InetAddress; import java.net.MulticastSocket; class MulticastTest { public static void main(String[] args) { try { int PORT = Integer.getInteger("hudson.udp",33848); InetAddress MULTICAST = InetAddress.getByAddress(new byte[]{(byte)239, (byte)77, (byte)124, (byte)213}); MulticastSocket mcs = new MulticastSocket(PORT); mcs.joinGroup(MULTICAST); } catch (Exception e) { e.printStackTrace(); System.exit(-1); } } } ================================================================================ If I run this testcase, I get the same error as what I reported earlier with Jenkins: java.net.SocketException: Invalid argument at java.net.PlainDatagramSocketImpl.join(Native Method) at java.net.AbstractPlainDatagramSocketImpl.join(AbstractPlainDatagramSocketImpl.java:178) at java.net.MulticastSocket.joinGroup(MulticastSocket.java:319) at MulticastTest.main(MulticastTest.java:31) If I run: ktrace java MulticastTest I see that the error here: 13253 java CALL setsockopt(0x4,0x29,0x1b,0x7fffffbfd7dc,0x4) 13253 java RET setsockopt 0 13253 java CALL setsockopt(0x4,SOL_SOCKET,SO_BROADCAST,0x7fffffbfd7d8,0x4) 13253 java RET setsockopt 0 13253 java CALL getsockopt(0x4,SOL_SOCKET,SO_TYPE,0x7fffffbfd77c,0x7fffffbfd778) 13253 java RET getsockopt 0 13253 java CALL setsockopt(0x4,SOL_SOCKET,SO_REUSEPORT,0x7fffffbfd7e0,0x4) 13253 java RET setsockopt 0 13253 java CALL setsockopt(0x4,SOL_SOCKET,SO_REUSEADDR,0x7fffffbfd7e0,0x4) 13253 java RET setsockopt 0 13253 java CALL bind(0x4,0x7fffffbfd7a8,0x1c) 13253 java STRU struct sockaddr { AF_INET6, [::]:33848 } 13253 java RET bind 0 13253 java CALL setsockopt(0x4,0x29,0x9,0x7fffffbfd7f4,0x4) 13253 java RET setsockopt 0 13253 java CALL getsockopt(0x4,0x29,0x9,0x7fffffbfd8ac,0x7fffffbfd864) 13253 java RET getsockopt 0 13253 java CALL setsockopt(0x4,0x29,0xc,0x7fffffbfd8c0,0x14) 13253 java RET setsockopt -1 errno 22 Invalid argument This looks like a bug in the FreeBSD networking code for multicast, or a bug in the FreeBSD code in the OpenJDK. This Java code works under Linux, Solaris, Windows, etc., so it would be good to fix this problem on FreeBSD. Can a networking person help me with this? -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 09:02:47 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0DDBD84C for ; Tue, 2 Sep 2014 09:02:47 +0000 (UTC) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx12.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D95391F89 for ; Tue, 2 Sep 2014 09:02:46 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.04,447,1406617200"; d="asc'?scan'208";a="185663614" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx12-out.netapp.com with ESMTP; 02 Sep 2014 02:02:46 -0700 Received: from HIOEXCMBX08-PRD.hq.netapp.com (10.122.105.41) by vmwexceht05-prd.hq.netapp.com (10.106.77.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 2 Sep 2014 02:02:01 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 2 Sep 2014 02:02:01 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::55e3:a7dc:11bd:462%21]) with mapi id 15.00.0913.011; Tue, 2 Sep 2014 02:02:01 -0700 From: "Eggert, Lars" To: John-Mark Gurney Subject: Re: igb "requests for mbufs denied" Thread-Topic: igb "requests for mbufs denied" Thread-Index: AQHPwpqIzDi3XZpt70OIdoMh57Bi85voomOAgAPZFICAAKUyAIAA6MyA Date: Tue, 2 Sep 2014 09:02:00 +0000 Message-ID: References: <20140829223233.GL71691@funkthat.com> <20140901190932.GV71691@funkthat.com> In-Reply-To: <20140901190932.GV71691@funkthat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_698F0DBA-440B-4007-840A-6B19163E0A6F"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 09:02:47 -0000 --Apple-Mail=_698F0DBA-440B-4007-840A-6B19163E0A6F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 2014-9-1, at 21:09, John-Mark Gurney wrote: > Still waiting for the other info I requested in my email... Sorry, which other info? (The message is not in dmesg, it's from netstat -m.) Lars --Apple-Mail=_698F0DBA-440B-4007-840A-6B19163E0A6F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVAWHtdZcnpRveo1xAQIuQQP/SBGlA9R5yNk+zdMneNFKUS/UKj9cwIOT varbZApGi0QNnBKWIdf3HK6XH7mRRRQoL2C0zkl8R4wFqdihtHVtlh4Ghf8FGNTH Sk+ZdIRcl3RCYgS/EDV2uMaodiVsFTPaycCnImhJnsynl9wuvGz+dcP0JOhpX49m UfdMsvAgxg0= =HWqf -----END PGP SIGNATURE----- --Apple-Mail=_698F0DBA-440B-4007-840A-6B19163E0A6F-- From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 10:08:03 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A512A9F5 for ; Tue, 2 Sep 2014 10:08:03 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8BDF11899 for ; Tue, 2 Sep 2014 10:08:03 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s82A83Hm054368 for ; Tue, 2 Sep 2014 10:08:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193246] Bug in multicast bind(), uncovered by Jenkins Date: Tue, 02 Sep 2014 10:08:03 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: rodrigc@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 10:08:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193246 --- Comment #2 from Craig Rodrigues --- I did some more analysis and found that this code: 13253 java CALL bind(0x4,0x7fffffbfd7a8,0x1c) 13253 java STRU struct sockaddr { AF_INET6, [::]:33848 } 13253 java RET bind 0 13253 java CALL setsockopt(0x4,0x29,0x9,0x7fffffbfd7f4,0x4) 13253 java RET setsockopt 0 13253 java CALL getsockopt(0x4,0x29,0x9,0x7fffffbfd8ac,0x7fffffbfd864) 13253 java RET getsockopt 0 13253 java CALL setsockopt(0x4,0x29,0xc,0x7fffffbfd8c0,0x14) 13253 java RET setsockopt -1 errno 22 Invalid argument is happening inside the mcast_join_leave() function inside the JDK here: http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/9b8c96f96a0f/src/solaris/native/java/net/PlainDatagramSocketImpl.c >From looking at the FreeBSD header files, IPPROTO_IPV6 = 41 (0x29) IPV6_MULTICAST_IF = IPV6_JOIN_GROUP = 12 (0xc)_ inside the mcast_join_leave() function what is basically happening is: setsockopt(0x4, IPPROTO_IPV6, IPV6_MULTICAST_IF, ...) getsockopt(0x4, IPPROTO_IPV6, IPV6_MULTICAST_IF, ...) setsockopt(0x4, IPPROTO_IPV6, IPV6_JOIN_GROUP, ...) the second setsockopt() is returning EINVAL -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 11:13:53 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BBA01413 for ; Tue, 2 Sep 2014 11:13:53 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A2A8E10B0 for ; Tue, 2 Sep 2014 11:13:53 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s82BDrnY056310 for ; Tue, 2 Sep 2014 11:13:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193246] Bug in multicast bind(), uncovered by Jenkins Date: Tue, 02 Sep 2014 11:13:53 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: rodrigc@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 11:13:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193246 --- Comment #3 from Craig Rodrigues --- I ran the same test program under truss with: truss java MulticastTest and found this: socket(PF_INET6,SOCK_DGRAM,0) = 4 (0x4) setsockopt(0x4,0x29,0x1b,0x7fffffbfd7dc,0x4,0x0) = 0 (0x0) setsockopt(0x4,0xffff,0x20,0x7fffffbfd7d8,0x4,0x0) = 0 (0x0) getsockopt(0x4,0xffff,0x1008,0x7fffffbfd77c,0x7fffffbfd778,0x83f5292d8) = 0 (0x0) setsockopt(0x4,0xffff,0x200,0x7fffffbfd7e0,0x4,0x83f5292d8) = 0 (0x0) setsockopt(0x4,0xffff,0x4,0x7fffffbfd7e0,0x4,0x83f5292d8) = 0 (0x0) bind(4,{ AF_INET6 [108c:bd00:800:0:4b41:9700:100:0]:36096 },28) = 0 (0x0) setsockopt(0x4,0x29,0x9,0x7fffffbfd7f4,0x4,0x83f54efd0) = 0 (0x0) getsockopt(0x4,0x29,0x9,0x7fffffbfd8ac,0x7fffffbfd864,0x83f54c798) = 0 (0x0) setsockopt(0x4,0x29,0xc,0x7fffffbfd8c0,0x14,0x83f54c798) ERR#22 'Invalid argument' -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 11:14:32 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB8134CA for ; Tue, 2 Sep 2014 11:14:32 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C239310C3 for ; Tue, 2 Sep 2014 11:14:32 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s82BEWj1056624 for ; Tue, 2 Sep 2014 11:14:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193246] Bug in IPv6 multicast join(), uncovered by Jenkins Date: Tue, 02 Sep 2014 11:14:33 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: rodrigc@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 11:14:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193246 Craig Rodrigues changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Bug in multicast bind(), |Bug in IPv6 multicast |uncovered by Jenkins |join(), uncovered by | |Jenkins -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 14:18:29 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0A5BEEA for ; Tue, 2 Sep 2014 14:18:29 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2CA81CCE for ; Tue, 2 Sep 2014 14:18:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=bNR5SSw6Y72SjJZdp5VmkxHSRQmkPDlPqZvs3ktuIRk=; b=QmFvk/2hWkRaMGIm20VBAXsTRTLLfh6LN5exqgg/6Jkz6g6GtZFxqhAumQYJSvhdFkPcJwsAfe374ZD07hpS5fOxCI8YoVf6mUbOTkEpGqJOejEYXHGx28SEo59ALWV9+8guVdaRwxnpmnulNe+d34UpQaC94t8FhBmNi5bi1EI=; Received: from 104-54-221-134.lightspeed.austtx.sbcglobal.net ([104.54.221.134]:15310 helo=borg.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XOouh-00055N-A8 for freebsd-net@freebsd.org; Tue, 02 Sep 2014 09:18:28 -0500 Date: Tue, 2 Sep 2014 09:18:16 -0500 From: Larry Rosenman To: freebsd-net@freebsd.org Subject: random "Can't allocate memory" from sshd Message-ID: <20140902141815.GA19120@borg.lerctr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TVD_RCVD_IP=0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TVD_RCVD_IP=0.001 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 14:18:30 -0000 I've had this issue for a while on 10 and 11.... merrily working along, in an SSH session, or doing zfs send/recv over ssh and randomly I'll get a "can't allocate memory" from sshd and the session gets killed. There is PLENTY of memory on the free list (>500meg). What can I do to catch what is having an issue, and better yet, fix it? What diagnostics do I need? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 14:47:48 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6ECA7D58 for ; Tue, 2 Sep 2014 14:47:48 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 20E6E10B7 for ; Tue, 2 Sep 2014 14:47:47 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3hnWNL4FZMz11F for ; Tue, 2 Sep 2014 16:47:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla2; t=1409669261; x=1412261262; bh=7Mo ShKJs4gVmAa2K4wRxj8xnFkw5Rd9MX8OvoAQT+AA=; b=kv+sP2LHs4RT32KCC+5 9qp++FwH1DjH0O3pnRkcjm7jOmjVPLwXSxno8zDgyG9zxs5mG35feUh7EfwRR4EE 9LFxsdgMKvnP21RNDPF6YdwlpHvTmKAaLRDBARlKbRjvX8fpyIeNWvZF8Un/ypkj eBA1VunMyzC/MoLt62G3HRNQ= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id urPnAPoqyED6 for ; Tue, 2 Sep 2014 16:47:41 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Tue, 2 Sep 2014 16:47:41 +0200 (CEST) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3hnWNF6Z8Yzs5 for ; Tue, 2 Sep 2014 16:47:41 +0200 (CEST) Received: from neli.ijs.si ([2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Tue, 02 Sep 2014 16:47:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 02 Sep 2014 16:47:41 +0200 From: Mark Martinec To: freebsd-net@freebsd.org Subject: Re: random "Can't allocate memory" from sshd Organization: J. Stefan Institute In-Reply-To: <20140902141815.GA19120@borg.lerctr.org> References: <20140902141815.GA19120@borg.lerctr.org> Message-ID: <2748836689ecfef3b8b921bc609d0b75@mailbox.ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.0.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 14:47:48 -0000 2014-09-02 Larry Rosenman wrote: > random "Can't allocate memory" from sshd > I've had this issue for a while on 10 and 11.... > > merrily working along, in an SSH session, or doing zfs send/recv over > ssh > and randomly I'll get a "can't allocate memory" from sshd and the > session > gets killed. > > There is PLENTY of memory on the free list (>500meg). > What can I do to catch what is having an issue, and better yet, fix it? > What diagnostics do I need? Possibly/likely a network resources issue, check these threads: Bumping up a default net.graph.maxdata to avoid "Write failed: Cannot allocate memory" http://lists.freebsd.org/pipermail/freebsd-net/2014-July/039347.html zfs send/recv: STILL invalid Backup Stream http://lists.freebsd.org/pipermail/freebsd-current/2014-July/051391.html Mark From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 14:56:53 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42F5DEE4; Tue, 2 Sep 2014 14:56:53 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1178A122C; Tue, 2 Sep 2014 14:56:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=mcWEeGCQPr/+Bf1HBoWkc61/XLE2jsvmqDAsX4lR1mo=; b=YLKTYZsa8EE1uKOfJIq6fusqbE9qGkhibQRbgY1T136g9dwICZOez4DrEYI6iFEcoWIai0VzIDBKZftnvWGY1C/ZIUYl24kvKw0gpL9QkiQSZt9Zh33itFKUa+N7R4rnJdUuNTb4EV1W+AxHFRSMCkQ9z81XVVKXnCWqdgKqYzE=; Received: from localhost.lerctr.org ([127.0.0.1]:55079 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XOpVp-0005g9-4E; Tue, 02 Sep 2014 09:56:50 -0500 Received: from host.alcatel.com ([198.205.55.139]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Tue, 02 Sep 2014 09:56:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 02 Sep 2014 09:56:49 -0500 From: Larry Rosenman To: Mark Martinec Subject: Re: random "Can't allocate memory" from sshd In-Reply-To: <2748836689ecfef3b8b921bc609d0b75@mailbox.ijs.si> References: <20140902141815.GA19120@borg.lerctr.org> <2748836689ecfef3b8b921bc609d0b75@mailbox.ijs.si> Message-ID: <3c89c1d4ca505156357b9a943cc6f6c6@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.2 X-Spam-Score: -4.6 (----) X-LERCTR-Spam-Score: -4.6 (----) X-Spam-Report: SpamScore (-4.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-1.713 X-LERCTR-Spam-Report: SpamScore (-4.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-1.713 Cc: freebsd-net@freebsd.org, owner-freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 14:56:53 -0000 On 2014-09-02 09:47, Mark Martinec wrote: > 2014-09-02 Larry Rosenman wrote: >> random "Can't allocate memory" from sshd >> I've had this issue for a while on 10 and 11.... >> >> merrily working along, in an SSH session, or doing zfs send/recv over >> ssh >> and randomly I'll get a "can't allocate memory" from sshd and the >> session >> gets killed. >> >> There is PLENTY of memory on the free list (>500meg). >> What can I do to catch what is having an issue, and better yet, fix >> it? >> What diagnostics do I need? > > Possibly/likely a network resources issue, check these threads: > > Bumping up a default net.graph.maxdata to avoid "Write failed: Cannot > allocate memory" > http://lists.freebsd.org/pipermail/freebsd-net/2014-July/039347.html > > zfs send/recv: STILL invalid Backup Stream > > http://lists.freebsd.org/pipermail/freebsd-current/2014-July/051391.html > > > Mark Ha. That 2nd one is MY thread :) I just made the change to net.graph.maxdata -- will play. Thanks! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 20:28:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9C4C934 for ; Tue, 2 Sep 2014 20:28:00 +0000 (UTC) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 87E2D1EB9 for ; Tue, 2 Sep 2014 20:28:00 +0000 (UTC) Received: by mail-qg0-f53.google.com with SMTP id z107so7262323qgd.12 for ; Tue, 02 Sep 2014 13:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gGzNqjAt1AdeLhHZPAdyOB1Vd2BXlcy43Ba3bR8swkY=; b=u8R9ZSVSMT91QJlj+VU6pZ87ZdGlhti/MzoPBHhNOyPtEam0M78GWq1MQ9aSS5xPSy u+kXc/23dr4GeAKf0fX4drKSe4gdNAC7wl8ktPUSg48kOqA5r/b896oNpv/ccILRMO6D CHtbiPp3S4bFH7cdf9ZygrpZzUJnXQ5G7K5QuivihCioucBb93cWec5tHu7M+s9F9nUH dbjuK4TfgjpTM/d8i26EyDEJzPzM4RjskIjop+HR1fu0dNy35344uXXAA+oouQ08wZT0 E6nV3Rd1aSo/NbNHzW5nHmrZ5/wWxY/lAB2vweEi1GOcknZffzWbOeLVYmfiV9ALoJRf IxPA== MIME-Version: 1.0 X-Received: by 10.140.46.55 with SMTP id j52mr45525745qga.27.1409689679519; Tue, 02 Sep 2014 13:27:59 -0700 (PDT) Sender: djmitche@gmail.com Received: by 10.140.167.130 with HTTP; Tue, 2 Sep 2014 13:27:59 -0700 (PDT) In-Reply-To: <540625B4.6040907@wp.pl> References: <20120827094956.GA93853@server.rulingia.com> <20120901215514.GA84970@server.rulingia.com> <540625B4.6040907@wp.pl> Date: Tue, 2 Sep 2014 16:27:59 -0400 X-Google-Sender-Auth: qEQoTKKFyC5wNjiWTDyIj5CnXyY Message-ID: Subject: Re: bridging VLAN interfaces and STP From: "Dustin J. Mitchell" To: Marek Salwerowicz Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org, Peter Jeremy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 20:28:00 -0000 No, I never figured it out. I never really even got Peter to understand the problem - he was still asking about whether STP packets were on the wire when I left the issue, yet the problem is interface configuration, not traffic. FreeBSD doesn't support configuring STP on VLAN interfaces - whether that's a bug or a feature is for someone else to decide. I can confirm it is still the case: hilbert ~ # sysctl -n kern.osrelease kern.ostype 9.2-RELEASE-p10 FreeBSD hilbert ~ # ifconfig bridge10 bridge10: flags=8843 metric 0 mtu 1500 ether 02:f4:a1:63:5a:0a inet6 fe80::f4:a1ff:fe63:5a0a%bridge10 prefixlen 64 scopeid 0xd inet 172.16.1.21 netmask 0xffffff00 broadcast 172.16.1.255 inet 172.16.1.1 netmask 0xffffffff broadcast 172.16.1.1 inet6 2001:470:1f11:826::1:15 prefixlen 64 inet6 2001:470:1f11:826::1:1 prefixlen 128 nd6 options=21 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: vr3 flags=143 ifmaxaddr 0 port 4 priority 128 path cost 55 member: vr2 flags=143 ifmaxaddr 0 port 3 priority 128 path cost 200000 member: vr1.10 flags=143 ifmaxaddr 0 port 9 priority 128 path cost 200000 hilbert ~ # ifconfig vr1.10 vr1.10: flags=8943 metric 0 mtu 1500 ether 00:00:24:ce:ec:95 inet6 fe80::200:24ff:fece:ec95%vr1.10 prefixlen 64 scopeid 0x9 nd6 options=21 media: Ethernet autoselect (100baseTX ) status: active vlan: 10 parent interface: vr1 hilbert ~ # ifconfig bridge10 stp vr1.10 ifconfig: unable to set bridge flags: Invalid argument Dustin On Tue, Sep 2, 2014 at 4:16 PM, Marek Salwerowicz wrote: > Hello Dustin, > > W dniu 2012-09-02 o 01:13, Dustin J. Mitchell pisze: >> >> On Sat, Sep 1, 2012 at 5:55 PM, Peter Jeremy wrote: >>> >>> >That looks like RSTP is enabled on both bridge10 and bridge20 but is >>> >not seeing incoming [R]STP packets. Are you sure the switch connected >>> >to vr1 is configured with per-VLAN STP (this is probably not the >>> >switch default). >>> > >>> >Have you tried running tcpdump on vr1 and checked that you are seeing >>> >STP packets within the VLANs. >> >> Actually, if you compare with my original ifconfig, you'll see that >> this particular arrangement shows STP as enabled on the bridge, but >> not on any of the members (no STP in their options. In the OP, you >> can see that the vr{2,3} get STP in their flags >> () while vr1.10 does not. >> That, and the error message from the 'ifconfig bridge10 stp vr1.10' >> command.. > > > > I'd like to ask if have you managed to figure out this issue? I am facing > more or less the same problem > > I have set up multiple VLANs on my FreeBSD box and now would like to bridge > WiFi adapter (wlan0) with only one vlan: > > When I try to configure bridge: > > % sudo ifconfig bridge create > % sudo ifconfig bridge addm wlan0 > % sudo ifconfig bridge addm vlan1200 > bridge0: error setting interface capabilities on vlan1200 > % sudo ifconfig bridge stp wlan0 > % sudo ifconfig bridge0 stp vlan1200 > ifconfig: unable to set bridge flags: Invalid argument > > % ifconfig bridge0 > bridge0: flags=8802 metric 0 mtu 1500 > ether 02:8e:2e:18:3e:00 > nd6 options=9 > id 04:f0:21:0f:77:d7 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > root id 04:f0:21:0f:77:d7 priority 32768 ifcost 0 port 0 > member: vlan1200 flags=143 > ifmaxaddr 0 port 6 priority 128 path cost 20000 > member: wlan0 flags=147 > ifmaxaddr 0 port 11 priority 128 path cost 33333 proto rstp > role designated state discarding > > > If I change vlan1200 to physical interface, everything works without any > problems.. > > Do you have any idea? > > Cheers, > > Marek > > > From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 21:17:02 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCECF8B3 for ; Tue, 2 Sep 2014 21:17:01 +0000 (UTC) Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.wp.pl", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A12914A6 for ; Tue, 2 Sep 2014 21:17:00 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 18919 invoked from network); 2 Sep 2014 22:16:55 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1409689015; bh=69Y72XE9BGxh+VgRqeqh4IMIV7jWZLVnrFgKqvRvjos=; h=From:To:CC:Subject; b=IAmjKqO62lrASdICEdPl/0pQWR7GK8vB7e1humpr3yBB2GdY17IRCTVhpWFto9FH9 JcvQamar8qiAl9pMaZOEji11dpPy1NsxiLIxMu2CYKoxsVMf3eveWJdHvIw2UbW3+7 ujes/ox31QLtBAMhvsJ3cABwXCBDcSeYCdvXMzro= Received: from 250-210-250-178.ftth.cust.kwaoo.net (HELO [10.0.5.104]) (marek_sal@[178.250.210.250]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with AES128-SHA encrypted SMTP for ; 2 Sep 2014 22:16:55 +0200 Message-ID: <540625B4.6040907@wp.pl> Date: Tue, 02 Sep 2014 22:16:52 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Dustin J. Mitchell" , Peter Jeremy Subject: Re: bridging VLAN interfaces and STP References: <20120827094956.GA93853@server.rulingia.com> <20120901215514.GA84970@server.rulingia.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [IePU] Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 21:17:02 -0000 Hello Dustin, W dniu 2012-09-02 o 01:13, Dustin J. Mitchell pisze: > On Sat, Sep 1, 2012 at 5:55 PM, Peter Jeremy wrote: >> >That looks like RSTP is enabled on both bridge10 and bridge20 but is >> >not seeing incoming [R]STP packets. Are you sure the switch connected >> >to vr1 is configured with per-VLAN STP (this is probably not the >> >switch default). >> > >> >Have you tried running tcpdump on vr1 and checked that you are seeing >> >STP packets within the VLANs. > Actually, if you compare with my original ifconfig, you'll see that > this particular arrangement shows STP as enabled on the bridge, but > not on any of the members (no STP in their options. In the OP, you > can see that the vr{2,3} get STP in their flags > () while vr1.10 does not. > That, and the error message from the 'ifconfig bridge10 stp vr1.10' > command.. I'd like to ask if have you managed to figure out this issue? I am facing more or less the same problem I have set up multiple VLANs on my FreeBSD box and now would like to bridge WiFi adapter (wlan0) with only one vlan: When I try to configure bridge: % sudo ifconfig bridge create % sudo ifconfig bridge addm wlan0 % sudo ifconfig bridge addm vlan1200 bridge0: error setting interface capabilities on vlan1200 % sudo ifconfig bridge stp wlan0 % sudo ifconfig bridge0 stp vlan1200 ifconfig: unable to set bridge flags: Invalid argument % ifconfig bridge0 bridge0: flags=8802 metric 0 mtu 1500 ether 02:8e:2e:18:3e:00 nd6 options=9 id 04:f0:21:0f:77:d7 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 04:f0:21:0f:77:d7 priority 32768 ifcost 0 port 0 member: vlan1200 flags=143 ifmaxaddr 0 port 6 priority 128 path cost 20000 member: wlan0 flags=147 ifmaxaddr 0 port 11 priority 128 path cost 33333 proto rstp role designated state discarding If I change vlan1200 to physical interface, everything works without any problems.. Do you have any idea? Cheers, Marek From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 22:34:22 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D804178 for ; Tue, 2 Sep 2014 22:34:22 +0000 (UTC) Received: from mx4.wp.pl (mx4.wp.pl [212.77.101.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.wp.pl", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CF0C21E22 for ; Tue, 2 Sep 2014 22:34:21 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 10806 invoked from network); 3 Sep 2014 00:34:16 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1409697256; bh=AhbBlg+guY7BVnS8XXv8ugX5bSLreZaXll5J8Zu3LSk=; h=From:To:CC:Subject; b=bHfW1f6FT2m6CUhQN2frw3eg3QLp5JA4Ov7GsK9otDEDeLrXzl0fGTfwbLOudOakG ymfhoY+sHOvWMxPOGGpqEIYpkMLdcn2JGGKfSsz061DGl2s8OT2wh24GaxriMgIpI6 IEH95rwB6x3btvAIn7cxPtUwqF2jmSGunuPU+QjY= Received: from 250-210-250-178.ftth.cust.kwaoo.net (HELO [10.0.5.12]) (marek_sal@[178.250.210.250]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with AES128-SHA encrypted SMTP for ; 3 Sep 2014 00:34:16 +0200 Message-ID: <540645E6.2050809@wp.pl> Date: Wed, 03 Sep 2014 00:34:14 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Dustin J. Mitchell" , Marek Salwerowicz Subject: Re: bridging VLAN interfaces and STP References: <20120827094956.GA93853@server.rulingia.com> <20120901215514.GA84970@server.rulingia.com> <540625B4.6040907@wp.pl> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-WP-DKIM-Status: good (id: wp.pl) X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [cVOE] Cc: freebsd-net@freebsd.org, Peter Jeremy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 22:34:22 -0000 W dniu 2014-09-02 o 22:27, Dustin J. Mitchell pisze: > No, I never figured it out. I never really even got Peter to > understand the problem - he was still asking about whether STP packets > were on the wire when I left the issue, yet the problem is interface > configuration, not traffic. > > FreeBSD doesn't support configuring STP on VLAN interfaces - whether > that's a bug or a feature is for someone else to decide. I can > confirm it is still the case: Does the bridge without STP work for you ? What do you actually bridge? As I see, there are 2 physical interfaces and 1 vlan I am wondering if the STP is really necessary for bridging vlan with wlan0 interface, but so far I can't figure out the answer Marek > > hilbert ~ # sysctl -n kern.osrelease kern.ostype > 9.2-RELEASE-p10 > FreeBSD > hilbert ~ # ifconfig bridge10 > bridge10: flags=8843 metric 0 mtu 1500 > ether 02:f4:a1:63:5a:0a > inet6 fe80::f4:a1ff:fe63:5a0a%bridge10 prefixlen 64 scopeid 0xd > inet 172.16.1.21 netmask 0xffffff00 broadcast 172.16.1.255 > inet 172.16.1.1 netmask 0xffffffff broadcast 172.16.1.1 > inet6 2001:470:1f11:826::1:15 prefixlen 64 > inet6 2001:470:1f11:826::1:1 prefixlen 128 > nd6 options=21 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: vr3 flags=143 > ifmaxaddr 0 port 4 priority 128 path cost 55 > member: vr2 flags=143 > ifmaxaddr 0 port 3 priority 128 path cost 200000 > member: vr1.10 flags=143 > ifmaxaddr 0 port 9 priority 128 path cost 200000 > hilbert ~ # ifconfig vr1.10 > vr1.10: flags=8943 > metric 0 mtu 1500 > ether 00:00:24:ce:ec:95 > inet6 fe80::200:24ff:fece:ec95%vr1.10 prefixlen 64 scopeid 0x9 > nd6 options=21 > media: Ethernet autoselect (100baseTX ) > status: active > vlan: 10 parent interface: vr1 > hilbert ~ # ifconfig bridge10 stp vr1.10 > ifconfig: unable to set bridge flags: Invalid argument > > Dustin > > On Tue, Sep 2, 2014 at 4:16 PM, Marek Salwerowicz wrote: >> Hello Dustin, >> >> W dniu 2012-09-02 o 01:13, Dustin J. Mitchell pisze: >>> On Sat, Sep 1, 2012 at 5:55 PM, Peter Jeremy wrote: >>>>> That looks like RSTP is enabled on both bridge10 and bridge20 but is >>>>> not seeing incoming [R]STP packets. Are you sure the switch connected >>>>> to vr1 is configured with per-VLAN STP (this is probably not the >>>>> switch default). >>>>> >>>>> Have you tried running tcpdump on vr1 and checked that you are seeing >>>>> STP packets within the VLANs. >>> Actually, if you compare with my original ifconfig, you'll see that >>> this particular arrangement shows STP as enabled on the bridge, but >>> not on any of the members (no STP in their options. In the OP, you >>> can see that the vr{2,3} get STP in their flags >>> () while vr1.10 does not. >>> That, and the error message from the 'ifconfig bridge10 stp vr1.10' >>> command.. >> >> >> I'd like to ask if have you managed to figure out this issue? I am facing >> more or less the same problem >> >> I have set up multiple VLANs on my FreeBSD box and now would like to bridge >> WiFi adapter (wlan0) with only one vlan: >> >> When I try to configure bridge: >> >> % sudo ifconfig bridge create >> % sudo ifconfig bridge addm wlan0 >> % sudo ifconfig bridge addm vlan1200 >> bridge0: error setting interface capabilities on vlan1200 >> % sudo ifconfig bridge stp wlan0 >> % sudo ifconfig bridge0 stp vlan1200 >> ifconfig: unable to set bridge flags: Invalid argument >> >> % ifconfig bridge0 >> bridge0: flags=8802 metric 0 mtu 1500 >> ether 02:8e:2e:18:3e:00 >> nd6 options=9 >> id 04:f0:21:0f:77:d7 priority 32768 hellotime 2 fwddelay 15 >> maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 >> root id 04:f0:21:0f:77:d7 priority 32768 ifcost 0 port 0 >> member: vlan1200 flags=143 >> ifmaxaddr 0 port 6 priority 128 path cost 20000 >> member: wlan0 flags=147 >> ifmaxaddr 0 port 11 priority 128 path cost 33333 proto rstp >> role designated state discarding >> >> >> If I change vlan1200 to physical interface, everything works without any >> problems.. >> >> Do you have any idea? >> >> Cheers, >> >> Marek >> >> >> From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 22:48:06 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5EFFBA4A for ; Tue, 2 Sep 2014 22:48:06 +0000 (UTC) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C1B51F45 for ; Tue, 2 Sep 2014 22:48:06 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id c9so7878801qcz.11 for ; Tue, 02 Sep 2014 15:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=sV/J7rJBO1RSyzKgZUwLRA7FoosD2PS8llLKI43W98o=; b=Jsp4Gru+fZ+jTkYB9tCJ3guq7fNTZWNa14bCzQVallunC9cNzSRqS6V/8c4X9dFCZf o6CMJ8mPR0Tvbi7s+BCz38szdFwaTBIF+0l8zyqZ7XWQIbGrUCNJaj7l0/L1zPnqZty7 WopgtzkcZqcXf8Rc8avV+XHLxpA3sqZ2NEl3+1qbUdBWN9ZQ/9O6/tYF/3XWAZvuaK9E 6QTgvfkURs0/AduehaIx9CbFbQANkFyh5wgv3OE2FH+xrAs7YAxnX8fo8kM2uHbVlm2Z wFGVIwBj53QvcakSWhtpamXBimdb+tAzrMlCjyDBrQzY0K1HHn88kEWANCo7PmSCKcMo AQdg== MIME-Version: 1.0 X-Received: by 10.140.48.5 with SMTP id n5mr56536565qga.102.1409698085150; Tue, 02 Sep 2014 15:48:05 -0700 (PDT) Sender: djmitche@gmail.com Received: by 10.140.167.130 with HTTP; Tue, 2 Sep 2014 15:48:05 -0700 (PDT) In-Reply-To: <540645E6.2050809@wp.pl> References: <20120827094956.GA93853@server.rulingia.com> <20120901215514.GA84970@server.rulingia.com> <540625B4.6040907@wp.pl> <540645E6.2050809@wp.pl> Date: Tue, 2 Sep 2014 18:48:05 -0400 X-Google-Sender-Auth: 8mocBN1t6hyJqww2jpMJUGuhV9I Message-ID: Subject: Re: bridging VLAN interfaces and STP From: "Dustin J. Mitchell" To: Marek Salwerowicz Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org, Peter Jeremy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 22:48:06 -0000 On Tue, Sep 2, 2014 at 6:34 PM, Marek Salwerowicz wrote: > Does the bridge without STP work for you ? It bridges, yes. It doesn't run STP. > What do you actually bridge? As I see, there are 2 physical interfaces and 1 > vlan Correct. > I am wondering if the STP is really necessary for bridging vlan with wlan0 > interface, but so far I can't figure out the answer It's certainly possible to conceive of a situation where a forwarding loop traverses a wireless link. Dustin From owner-freebsd-net@FreeBSD.ORG Wed Sep 3 10:05:53 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6BAFA66D for ; Wed, 3 Sep 2014 10:05:53 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 36ABA1E2C for ; Wed, 3 Sep 2014 10:05:53 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s83A5r9K004118 for ; Wed, 3 Sep 2014 10:05:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193246] Bug in IPv6 multicast join(), uncovered by Jenkins Date: Wed, 03 Sep 2014 10:05:53 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: rodrigc@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 10:05:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193246 --- Comment #4 from Craig Rodrigues --- I tracked this down some more. Inside the JDK, there is this code in http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/9b8c96f96a0f/src/solaris/native/java/net/PlainDatagramSocketImpl.c =============================================================================== /* * IPv6 join. If it's an IPv4 multicast group then we use an IPv4-mapped * address. */ #ifdef AF_INET6 { struct ipv6_mreq mname6; jbyteArray ipaddress; jbyte caddr[16]; jint family; jint address; family = (*env)->GetIntField(env, iaObj, ia_familyID) == IPv4? AF_INET : AF_INET6; if (family == AF_INET) { /* will convert to IPv4-mapped address */ memset((char *) caddr, 0, 16); address = (*env)->GetIntField(env, iaObj, ia_addressID); caddr[10] = 0xff; caddr[11] = 0xff; caddr[12] = ((address >> 24) & 0xff); caddr[13] = ((address >> 16) & 0xff); caddr[14] = ((address >> 8) & 0xff); caddr[15] = (address & 0xff); =============================================================================== I can confirm that the address created by this code looks something like: 0 0 0 0 0 0 0 0 0 0 ff ff ef 4d 7c d5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 In FreeBSD, in src/sys/netinet6/in6_mcast.c inside in6p_join_group(), there is this: if (!IN6_IS_ADDR_MULTICAST(&gsa->sin6.sin6_addr)) return (EINVAL); Since IN6_IS_ADDR_MULTICAST() only checks if the first octet is 0xff, that is what is returning the EINVAL. So the JDK is creating an IPV4 multicast address mapped inside an IPV6 address. The FreeBSD kernel code is rejecting this as a valid IPV6 multicast address. I'm not sure if it is better to fix this in the kernel or the JDK. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Sep 3 12:20:33 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 930BDDBB; Wed, 3 Sep 2014 12:20:33 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id C5D484A2C; Wed, 3 Sep 2014 12:20:32 +0000 (UTC) Message-ID: <54070758.2050405@FreeBSD.org> Date: Wed, 03 Sep 2014 16:19:36 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: bugzilla-noreply@freebsd.org, freebsd-net@FreeBSD.org Subject: Re: [Bug 193246] Bug in IPv6 multicast join(), uncovered by Jenkins References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 12:20:33 -0000 On 03.09.2014 14:05, bugzilla-noreply@freebsd.org wrote: > In FreeBSD, in src/sys/netinet6/in6_mcast.c inside in6p_join_group(), there > is this: > > if (!IN6_IS_ADDR_MULTICAST(&gsa->sin6.sin6_addr)) > return (EINVAL); > > Since IN6_IS_ADDR_MULTICAST() only checks if the first octet is 0xff, that is > what is returning the EINVAL. So the JDK is creating > an IPV4 multicast address mapped inside an IPV6 address. The FreeBSD > kernel code is rejecting this as a valid IPV6 multicast address. > > I'm not sure if it is better to fix this in the kernel or the JDK. Hi, you said that this code works in linux. I looked in the linux kernel source, and I think it should return EINVAL too. net/ipv6/mcast.c:ipv6_sock_mc_join: 154 if (!ipv6_addr_is_multicast(addr)) 155 return -EINVAL; -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Wed Sep 3 13:39:56 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21B98D69; Wed, 3 Sep 2014 13:39:56 +0000 (UTC) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 486CF1972; Wed, 3 Sep 2014 13:39:55 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id mc6so9853569lab.1 for ; Wed, 03 Sep 2014 06:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=TT0hyf4BjM1IZhBGMMPGnxGTUIGzLVkIiif8Ms96+00=; b=d26ORNwntcfouTXQRRhu7Z/DTlnWbYoq2B7HjKP72KFDA8Ah9ChxbdATbJDXohEN4Y GZpNJ3xGxxzEORJKZmJ6byy1XlxpDpZPCGAfsP6njpuNl9R1KG7cH8D7b8Z//VNR7Wxd v8DMIvdXqjp2VfyNiUV7fPU9XiuY04TGdxl8BWOyCMKBEBq6U1rJdxxqGP0R7s5lnr4x 7BQSn5/4opM0uTamB7lUTrXgrlM8m0glLk3C7PwjciOEJuLy0Hy8ilA6g0B8cEuFLLr1 sR0T+XGsDOchrkiPdXrQ3FqeE/kgTUuogircyIxtvcI338q7IoEvMtGJDZhSAOgjO3P7 CCcQ== MIME-Version: 1.0 X-Received: by 10.152.20.41 with SMTP id k9mr41119994lae.57.1409751593235; Wed, 03 Sep 2014 06:39:53 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.197.107 with HTTP; Wed, 3 Sep 2014 06:39:53 -0700 (PDT) In-Reply-To: <54070758.2050405@FreeBSD.org> References: <54070758.2050405@FreeBSD.org> Date: Wed, 3 Sep 2014 06:39:53 -0700 X-Google-Sender-Auth: bpDodc5saVkclzXN8PULa_wobQg Message-ID: Subject: Re: [Bug 193246] Bug in IPv6 multicast join(), uncovered by Jenkins From: Craig Rodrigues To: "Andrey V. Elsukov" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, bugzilla-noreply@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 13:39:56 -0000 On Wed, Sep 3, 2014 at 5:19 AM, Andrey V. Elsukov wrote: > On 03.09.2014 14:05, bugzilla-noreply@freebsd.org wrote: > > Hi, > > you said that this code works in linux. I looked in the linux kernel > source, and I think it should return EINVAL too. > net/ipv6/mcast.c:ipv6_sock_mc_join: > > 154 if (!ipv6_addr_is_multicast(addr)) > 155 return -EINVAL; The code does work in Linux. However, you need to look at the JDK source, not the Linux kernel source. In this file: http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/9b8c96f96a0f/src/solaris/native/java/net/PlainDatagramSocketImpl.c in the mcast_join_leave() function, there are two code paths: (1) Linux, (2) Solaris. It looks like on Solaris, they support IPv4-mapped multicast addresses for IPV6, and things work when they create an IPv6 socket, and then put an IPv4-mapped multicast address in it. For Linux, they have specific code paths in that function which seem to force creating an IPv4 socket. -- Craig From owner-freebsd-net@FreeBSD.ORG Wed Sep 3 13:45:57 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 082CE317; Wed, 3 Sep 2014 13:45:57 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 07F782898; Wed, 3 Sep 2014 13:45:54 +0000 (UTC) Message-ID: <54071B5A.6040303@FreeBSD.org> Date: Wed, 03 Sep 2014 17:44:58 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Craig Rodrigues Subject: Re: [Bug 193246] Bug in IPv6 multicast join(), uncovered by Jenkins References: <54070758.2050405@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 13:45:57 -0000 On 03.09.2014 17:39, Craig Rodrigues wrote: > On Wed, Sep 3, 2014 at 5:19 AM, Andrey V. Elsukov wrote: >> On 03.09.2014 14:05, bugzilla-noreply@freebsd.org wrote: >> >> Hi, >> >> you said that this code works in linux. I looked in the linux kernel >> source, and I think it should return EINVAL too. >> net/ipv6/mcast.c:ipv6_sock_mc_join: >> >> 154 if (!ipv6_addr_is_multicast(addr)) >> 155 return -EINVAL; > > > The code does work in Linux. However, you need to look at the > JDK source, not the Linux kernel source. > > In this file: > http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/9b8c96f96a0f/src/solaris/native/java/net/PlainDatagramSocketImpl.c > > in the mcast_join_leave() function, there are two code paths: (1) > Linux, (2) Solaris. > > It looks like on Solaris, they support IPv4-mapped multicast addresses for IPV6, > and things work when they create an IPv6 socket, and then put an > IPv4-mapped multicast address in it. For Linux, they have specific > code paths in that function which seem to force creating an IPv4 > socket. Yes, I have illumos-gate's code and I can confirm, that IPv4-mapped IPv6 addresses have special handling in multicast code. -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Thu Sep 4 11:58:42 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0652740 for ; Thu, 4 Sep 2014 11:58:42 +0000 (UTC) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx11.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E4D81C63 for ; Thu, 4 Sep 2014 11:58:42 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.04,465,1406617200"; d="asc'?scan'208";a="144252613" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx11-out.netapp.com with ESMTP; 04 Sep 2014 04:58:42 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 4 Sep 2014 04:58:30 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::55e3:a7dc:11bd:462%21]) with mapi id 15.00.0913.011; Thu, 4 Sep 2014 04:58:29 -0700 From: "Eggert, Lars" To: Luigi Rizzo Subject: netmap extra rings and buffers Thread-Topic: netmap extra rings and buffers Thread-Index: AQHPyDeKjIx8ly78NE+bckXSokPnmQ== Date: Thu, 4 Sep 2014 11:58:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_41B777AC-9BB5-4A01-84E0-F6B1687C916B"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 11:58:42 -0000 --Apple-Mail=_41B777AC-9BB5-4A01-84E0-F6B1687C916B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Luigi, I'm allocating extra rings and/or extra buffers via the nr_arg1/nr_arg3 = parameters for NIOCREGIF. Once I've done that, how do I actually access those rings and buffers? For extra rings, the documentation and example code don't really say = anything. For extra buffers, the documentation says "nifp->ni_bufs_head will be = the index of the first buffer" but doesn't really explain how I can find = the buffer given its index (since it's not in a ring, the NETMAP_BUF = macro doesn't seem to apply?) The part about "buffers are linked to each = other using the first uint32_t as the index" is also unclear to me. Do you have some more text or example code that shows how to use extra = rings and buffers? Thanks, Lars --Apple-Mail=_41B777AC-9BB5-4A01-84E0-F6B1687C916B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVAhT59ZcnpRveo1xAQIDwQP/cMBawktTBJKscUqjacndH/NTcG5aCMvf Q/l6qS/j2jKRPa3/JEfVf3lNfCsFgV/SYODH2UwH5Qa+Kio7Uw2QmODmCDW5taxm ObKKZgw9s7afEBBh59NYbe1/Fq+ny+14TcXKLz2GXAAmJZoUTxXFoYHweb7XMFKj R/+ewxVgSpc= =RiNX -----END PGP SIGNATURE----- --Apple-Mail=_41B777AC-9BB5-4A01-84E0-F6B1687C916B-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 4 14:27:21 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83D41731 for ; Thu, 4 Sep 2014 14:27:21 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6ABF11EDF for ; Thu, 4 Sep 2014 14:27:21 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s84ERLcY067192 for ; Thu, 4 Sep 2014 14:27:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193246] Bug in IPv6 multicast join(), uncovered by Jenkins Date: Thu, 04 Sep 2014 14:27:21 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 14:27:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193246 John Baldwin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhb@FreeBSD.org --- Comment #5 from John Baldwin --- Don't you really want an IPv4 socket here anyway? It seems rather convoluted to create an IPv6 socket so you can listen for IPv4 multicast. My guess is that the in6_mcast code doesn't handle IPv4 multicast groups, but bms@ might know. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Sep 4 15:49:28 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73140E81 for ; Thu, 4 Sep 2014 15:49:28 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 351D61BC9 for ; Thu, 4 Sep 2014 15:49:27 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 64C187300A; Thu, 4 Sep 2014 17:48:29 +0200 (CEST) Date: Thu, 4 Sep 2014 17:48:29 +0200 From: Luigi Rizzo To: "Eggert, Lars" Subject: Re: netmap extra rings and buffers Message-ID: <20140904154829.GA80780@onelab2.iet.unipi.it> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 15:49:28 -0000 On Thu, Sep 04, 2014 at 11:58:28AM +0000, Eggert, Lars wrote: > Hi Luigi, > > I'm allocating extra rings and/or extra buffers via the nr_arg1/nr_arg3 parameters for NIOCREGIF. > > Once I've done that, how do I actually access those rings and buffers? > > For extra rings, the documentation and example code don't really say anything. > > For extra buffers, the documentation says "nifp->ni_bufs_head will be the index of the first buffer" but doesn't really explain how I can find the buffer given its index (since it's not in a ring, the NETMAP_BUF macro doesn't seem to apply?) The part about "buffers are linked to each other using the first uint32_t as the index" is also unclear to me. > > Do you have some more text or example code that shows how to use extra rings and buffers? the ifield to request extra rings is only important when you want to make sure that the memory region for a VALE port has also space to host some pipes. Otherwise, for physical ports (which at the moment all share the same address space) there is not a real need to specify it. For the extra buffers, remember that NETMAP_BUF() can translate buffer indexes for any netmap buffer, even those not in a ring. All it does is grab the base address of the buffer pool from the ring, and add the buffer index times the buffer size. So you can navigate the pool of extra buffers as follows uint32_t x = nifp->ni_bufs_head; // index of first buf void *p = NETMAP_BUF(any_ring, x); // address of the first buffer x = *((uint32_t *)p); // index of the next buffer cheers luigi From owner-freebsd-net@FreeBSD.ORG Thu Sep 4 15:56:07 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D39153CC; Thu, 4 Sep 2014 15:56:07 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9D4331CEE; Thu, 4 Sep 2014 15:56:07 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 685D7B95E; Thu, 4 Sep 2014 11:56:06 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: [Bug 193246] Bug in IPv6 multicast join(), uncovered by Jenkins Date: Thu, 04 Sep 2014 10:42:59 -0400 Message-ID: <3393302.jtrfEtP2nm@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: References: <54070758.2050405@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 04 Sep 2014 11:56:06 -0400 (EDT) Cc: Craig Rodrigues , "Andrey V. Elsukov" , bugzilla-noreply@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 15:56:08 -0000 On Wednesday, September 03, 2014 06:39:53 AM Craig Rodrigues wrote: > On Wed, Sep 3, 2014 at 5:19 AM, Andrey V. Elsukov wrote: > > On 03.09.2014 14:05, bugzilla-noreply@freebsd.org wrote: > > > > Hi, > > > > you said that this code works in linux. I looked in the linux kernel > > source, and I think it should return EINVAL too. > > > > net/ipv6/mcast.c:ipv6_sock_mc_join: > > 154 if (!ipv6_addr_is_multicast(addr)) > > 155 return -EINVAL; > > The code does work in Linux. However, you need to look at the > JDK source, not the Linux kernel source. > > In this file: > http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/9b8c96f96a0f/src/solaris/nativ > e/java/net/PlainDatagramSocketImpl.c > > in the mcast_join_leave() function, there are two code paths: (1) > Linux, (2) Solaris. > > It looks like on Solaris, they support IPv4-mapped multicast addresses for > IPV6, and things work when they create an IPv6 socket, and then put an > IPv4-mapped multicast address in it. For Linux, they have specific > code paths in that function which seem to force creating an IPv4 > socket. >From looking at the source, it doesn't look like the Linux workaround (using IP_ADD_MEMBERSHIP on an AF_INET6 socket) will work on FreeBSD. I'm not sure how hard it would be to fix in6_mcast.c to support IPv4 groups. bms@ might know. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Sep 4 16:22:07 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C74DB425 for ; Thu, 4 Sep 2014 16:22:07 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AEFB9105A for ; Thu, 4 Sep 2014 16:22:07 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s84GM7cQ005698 for ; Thu, 4 Sep 2014 16:22:07 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193246] Bug in IPv6 multicast join(), uncovered by Jenkins Date: Thu, 04 Sep 2014 16:22:08 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: rodrigc@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 16:22:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193246 --- Comment #6 from Craig Rodrigues --- I'm looking at this from the perspective that 3rd party multicast code written in Java "just works" under Linux and Solaris, but fails under FreeBSD. Sure, using an IPv4 socket from the beginning would be the way to go, but now that will require pushing patches upstream to all Java software using multicast, in order to accomodate FreeBSD. It's possible, but not practical. It would be nice if the FreeBSD IPv6 stack could be modified to deal with IPv4-mapped multicast addresses for IPv6, similar to how Solaris does it. See comment from Andrey, http://lists.freebsd.org/pipermail/freebsd-net/2014-September/039686.html If that could be made to work, then no changes to upstream code would be required. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Sep 4 16:29:59 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C285CB3A for ; Thu, 4 Sep 2014 16:29:59 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A1F9B1159 for ; Thu, 4 Sep 2014 16:29:59 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s84GTx0X008386 for ; Thu, 4 Sep 2014 16:29:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193246] Bug in IPv6 multicast join(), uncovered by Jenkins Date: Thu, 04 Sep 2014 16:29:59 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: rodrigc@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 16:29:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193246 --- Comment #7 from Craig Rodrigues --- In src/sys/netinet6, I see that there is usage of a IN6_IS_ADDR_V4MAPPED() macro in other places in the code, like in udp6 and sctp6, so V4 mapped addresses are supported for other things. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Sep 4 17:50:18 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E54EDDEB; Thu, 4 Sep 2014 17:50:18 +0000 (UTC) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD7AA1D41; Thu, 4 Sep 2014 17:50:17 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id t60so10575759wes.4 for ; Thu, 04 Sep 2014 10:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Si3IZl7M/LoNDZ9xEG6SxtCuklYCDWs2JyEHPg7Udrs=; b=yLBfWcXuNsTcgnhI7iry+OVJ5MLRyYqjBMXSit4O9BZpjb4Klvvk6rLfjoJCRNz0mi 5A1opKz1a2Y2ZSGfVvuAwEMHqtmIcyy5Lj6JuSsyUizl49efPeQ5O9kvp9dHcZbnkQaZ mdf4pXIcdpVT7WDtA6SQJXvjayJ/Y7OVmMQhISPQ/7uiyGMcZoBJ6vL2lsrfLRf/wkj8 3IwTsxu+LEubrxdNjVq528uOhQvOqpXz8Rzbg5G+zuuWLbfbkwo2k+BFYLrCFTcBg9W3 Wii03S3AYdpTtnHaGQfwOsYCEdkQ94bXNrw+vcE7xedEw2MeMkI7vGZ9T0jLk1utfkJx N+Ag== MIME-Version: 1.0 X-Received: by 10.180.75.49 with SMTP id z17mr7478845wiv.80.1409853012896; Thu, 04 Sep 2014 10:50:12 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.123.164 with HTTP; Thu, 4 Sep 2014 10:50:12 -0700 (PDT) In-Reply-To: <3393302.jtrfEtP2nm@ralph.baldwin.cx> References: <54070758.2050405@FreeBSD.org> <3393302.jtrfEtP2nm@ralph.baldwin.cx> Date: Thu, 4 Sep 2014 10:50:12 -0700 X-Google-Sender-Auth: PUKMcJ_cIUCh2wieFcRnszAquq0 Message-ID: Subject: Re: [Bug 193246] Bug in IPv6 multicast join(), uncovered by Jenkins From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: Craig Rodrigues , FreeBSD Net , bugzilla-noreply@freebsd.org, "Andrey V. Elsukov" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 17:50:19 -0000 At Thu, 04 Sep 2014 10:42:59 -0400, John Baldwin wrote: > > It looks like on Solaris, they support IPv4-mapped multicast addresses for > > IPV6, and things work when they create an IPv6 socket, and then put an > > IPv4-mapped multicast address in it. For Linux, they have specific > > code paths in that function which seem to force creating an IPv4 > > socket. > > >From looking at the source, it doesn't look like the Linux workaround (using > IP_ADD_MEMBERSHIP on an AF_INET6 socket) will work on FreeBSD. I'm not sure > how hard it would be to fix in6_mcast.c to support IPv4 groups. bms@ might > know. (In my understanding) in general, BSD variants intentionally limit the support for the APIs using to that standardized in RFC3493 because of issues such as those described in http://tools.ietf.org/html/draft-cmetz-v6ops-v4mapped-api-harmful-01 (where implications with multicast API are also discussed). So I suspect it'll be generally difficult to extend the support for IPv4-mapped IPv6 addresses. As usual in the case where a deployed application relies on non-standard, non-portable API, making the decision is difficult. Personally, I'd first consider dealing it in the JDK so it'll be more portable. (Even though there are only two OSes today: FreeBSD and Linux:-) that will be helpful for other BSD variants, and also for even more minor systems that don't support the non-standard API. -- JINMEI, Tatuya From owner-freebsd-net@FreeBSD.ORG Thu Sep 4 18:16:41 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72F14883 for ; Thu, 4 Sep 2014 18:16:41 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3FEAB10C3 for ; Thu, 4 Sep 2014 18:16:41 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s84IGfkH022234 for ; Thu, 4 Sep 2014 18:16:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193246] Bug in IPv6 multicast join(), uncovered by Jenkins Date: Thu, 04 Sep 2014 18:16:41 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 18:16:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193246 John Baldwin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |In Discussion CC| |bms@FreeBSD.org --- Comment #8 from John Baldwin --- It seems to be a non-trivial amount of work. From bms@ on IRC: There's no hard and fast reasons why it couldn't be done. The code as it stands will reject that as being an API mixup (you want v4 memberships, use the v4 APIs). The tension points are the Layer 4 ingress filtering for SSM, and actually calling Layer 2 in the right way. The nasty thing about IP6-mapped is that you need to track the memberships in v6 terms, but hand-off all the work to the v4 routines to do the right thing. The easiest way to go about doing it is to deal with the ASM case first, and just punch a hole in ingress filtering if someone tries to use SSM (which is what the stack has to do anyway). I'm not going to stick around to see what happens, though. ;-) I think what this means is that in_mcast6.c is very much tied to doing MLDv6 (or whatever the v6 equivalent of IGMP is), but for these groups, you need to be somehow calling into in_mcast.c to do IGMP instead. However, I'm not sure at what level in_mcast6.c needs to call into in_mcast.c myself. I do think Bruce is your best bet for someone to ask. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Sep 4 23:14:21 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70FC8E61 for ; Thu, 4 Sep 2014 23:14:21 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3FD6813C4 for ; Thu, 4 Sep 2014 23:14:20 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 234CB139CB for ; Thu, 4 Sep 2014 20:14:51 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type:subject :subject:to:mime-version:user-agent:from:from:date:date :message-id; s=dkim; t=1409872488; x=1410736489; bh=myUpHvM1ymhG R2ahRnFsI72abqUUPwWp1gcxFwSTrnY=; b=Gb7FozNtzglboFEoNx4GRehhAgz2 LI78nLxbUbpHfO1Q0I23h9m9huQpI/sJD9q37KjMxQdBMlHI7kimqWO8V0NMNtku ZjqDBRUTpBZaaM+CkzI6GAhbUDMH+csX4satx3mMqe/RopN8a2pcYv0boDSl8DWX ULbMvLllD44thF8= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ksfs4ZFQZWM for ; Thu, 4 Sep 2014 20:14:48 -0300 (BRT) Received: from [127.0.0.1] (unknown [186.193.54.69]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id 8E61B139CA for ; Thu, 4 Sep 2014 20:14:48 -0300 (BRT) Message-ID: <5408F23C.2030309@bsdinfo.com.br> Date: Thu, 04 Sep 2014 20:14:04 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: FreeBSD Net Subject: ixgbe CRITICAL: ECC ERROR!! Please Reboot!! Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 140904-1, 04/09/2014), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 23:14:21 -0000 Hi All, I have an Intel X520-SR2and today was working when all traffic stopped. I looked in the logs and found this message: Sep 4 18:29:53 rt01 kernel: ix1: Sep 4 18:29:53 rt01 kernel: CRITICAL: ECC ERROR!! Please Reboot!! # uname -a FreeBSD rt01.xxxxx.com.br 10.0-STABLE FreeBSD 10.0-STABLE #10 r267839: Thu Jul 10 15:35:04 BRT 2014 root@rt01.xxxxx.com.br:/usr/obj/usr/src/sys/GONDIM10 amd64 # netstat -m 98324/53476/151800 mbufs in use (current/cache/total) 98301/44951/143252/1014370 mbuf clusters in use (current/cache/total/max) 98301/44897 mbuf+clusters out of packet secondary zone in use (current/cache) 0/421/421/507184 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/150276 9k jumbo clusters in use (current/cache/total/max) 0/0/0/84530 16k jumbo clusters in use (current/cache/total/max) 221183K/104955K/326138K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile Best regards, Gondim --- Este email est=E1 limpo de v=EDrus e malwares porque a prote=E7=E3o do avas= t! Antiv=EDrus est=E1 ativa. http://www.avast.com From owner-freebsd-net@FreeBSD.ORG Thu Sep 4 23:48:50 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2D714D7 for ; Thu, 4 Sep 2014 23:48:50 +0000 (UTC) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 943831814 for ; Thu, 4 Sep 2014 23:48:50 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id s7so6117730qap.8 for ; Thu, 04 Sep 2014 16:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=U30uWijb6+QY8g/JtdGVYEF7tKB0eI2ZhJFHdP6QHvc=; b=C/4Yc2bHjsN/ptyM+ZJmFk9BPLfTneMjzfnFM4HHKEHLU+RbAbGztVyadO5igg11qq uXyZW9tcYPGkQDRHUdB+CbxcFNrHZ+j+pC3/rHwLq61BYR6+7ibAVvp7ytg0tH5+S3Fc WRk72JWdU7ym98E7Z+zsQSOR+ggJIXxOM7UQCqq5Vg4CONYHbul+T5wZx8ODIkOu7rCC UXUlxIdntZXwSVV0cdmIcud+BqITnm0lvc4R2/7ibMVSFyKtFemi9GyBWnJqdJekpEpV GmiY9x9lKSbN5wlkywUumlSdpCJ8QP5UDe5EyQmX3x+5sEnvM2YlE2GxWQcMPAkseQ81 4E/Q== MIME-Version: 1.0 X-Received: by 10.229.202.199 with SMTP id ff7mr12910600qcb.9.1409874529595; Thu, 04 Sep 2014 16:48:49 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Thu, 4 Sep 2014 16:48:49 -0700 (PDT) In-Reply-To: <5408F23C.2030309@bsdinfo.com.br> References: <5408F23C.2030309@bsdinfo.com.br> Date: Thu, 4 Sep 2014 16:48:49 -0700 X-Google-Sender-Auth: Fy6Xe9MLEZcCnE78sHHV9bwNlts Message-ID: Subject: Re: ixgbe CRITICAL: ECC ERROR!! Please Reboot!! From: Adrian Chadd To: Marcelo Gondim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 23:48:50 -0000 Hi, The only time this has happened to me is because the card overheated. Can you check that? -a On 4 September 2014 16:14, Marcelo Gondim wrote: > Hi All, > > I have an Intel X520-SR2and today was working when all traffic stopped. > I looked in the logs and found this message: > > Sep 4 18:29:53 rt01 kernel: ix1: > Sep 4 18:29:53 rt01 kernel: CRITICAL: ECC ERROR!! Please Reboot!! > > # uname -a > FreeBSD rt01.xxxxx.com.br 10.0-STABLE FreeBSD 10.0-STABLE #10 r267839: Th= u > Jul 10 15:35:04 BRT 2014 > root@rt01.xxxxx.com.br:/usr/obj/usr/src/sys/GONDIM10 amd64 > > # netstat -m > 98324/53476/151800 mbufs in use (current/cache/total) > 98301/44951/143252/1014370 mbuf clusters in use (current/cache/total/max) > 98301/44897 mbuf+clusters out of packet secondary zone in use > (current/cache) > 0/421/421/507184 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/150276 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/84530 16k jumbo clusters in use (current/cache/total/max) > 221183K/104955K/326138K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > > Best regards, > > Gondim > > --- > Este email est=C3=A1 limpo de v=C3=ADrus e malwares porque a prote=C3=A7= =C3=A3o do avast! > Antiv=C3=ADrus est=C3=A1 ativa. > http://www.avast.com > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 00:25:49 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1FFAF57 for ; Fri, 5 Sep 2014 00:25:49 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BCB441BA1 for ; Fri, 5 Sep 2014 00:25:49 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s850PkaU029192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 4 Sep 2014 17:25:47 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <54090304.2020206@freebsd.org> Date: Thu, 04 Sep 2014 17:25:40 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Dustin J. Mitchell" , Marek Salwerowicz Subject: Re: bridging VLAN interfaces and STP References: <20120827094956.GA93853@server.rulingia.com> <20120901215514.GA84970@server.rulingia.com> <540625B4.6040907@wp.pl> <540645E6.2050809@wp.pl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Peter Jeremy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 00:25:50 -0000 On 9/2/14, 3:48 PM, Dustin J. Mitchell wrote: > On Tue, Sep 2, 2014 at 6:34 PM, Marek Salwerowicz wrote: >> Does the bridge without STP work for you ? > It bridges, yes. It doesn't run STP. > >> What do you actually bridge? As I see, there are 2 physical interfaces and 1 >> vlan > Correct. > >> I am wondering if the STP is really necessary for bridging vlan with wlan0 >> interface, but so far I can't figure out the answer > It's certainly possible to conceive of a situation where a forwarding > loop traverses a wireless link. look into netgraph bridging. > > Dustin > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 01:46:56 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF7C4E95 for ; Fri, 5 Sep 2014 01:46:56 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7AE8C1335 for ; Fri, 5 Sep 2014 01:46:56 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 6571A139CB for ; Thu, 4 Sep 2014 22:47:32 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:to:mime-version :user-agent:from:from:date:date:message-id; s=dkim; t= 1409881651; x=1410745652; bh=4vCDhsUFQ85bOAcJ3zqz8L5mRYRnacrbCX0 xXpYTMro=; b=lo7jTTH6elF6k4ezUbWva0B8FtwXT7r+hEKHFs47K6hJvEngFeM 6NRKr49H3yY4UBC9ArGIQg6F7iALeq4CsS8e9M00UPQFSaB/7hmgytg0IkL0Gdft l7gTj5kQLuSaFJUgoGlrG9p/MCq966qQ5gh7UHktsfNh7F60eMRfkr0Y= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tyqCq4oUtOh for ; Thu, 4 Sep 2014 22:47:31 -0300 (BRT) Received: from [192.168.10.208] (unknown [186.193.54.69]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id 54DA2139CA for ; Thu, 4 Sep 2014 22:47:31 -0300 (BRT) Message-ID: <54091607.9010100@bsdinfo.com.br> Date: Thu, 04 Sep 2014 22:46:47 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: ixgbe CRITICAL: ECC ERROR!! Please Reboot!! References: <5408F23C.2030309@bsdinfo.com.br> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 01:46:56 -0000 On 04/09/2014 20:48, Adrian Chadd wrote: > Hi, > > The only time this has happened to me is because the card overheated. > Can you check that? Hi Adrian, The room where the equipment is located is very cold but I'll check it out. Also seen at the time of the problem, a lot of dropped packets. # netstat -idn ... ix0 1500 a0:36:9f:2a:6d:ac 18446743423829095869 159 750924631703 53285910688 0 0 0 ix0 - fe80::a236:9f fe80::a236:9fff:f 0 - - 2 - - - ix1 1500 a0:36:9f:2a:6d:ae 18446743954328745465 0 119550050209 20178077451 0 0 0 ix1 - fe80::a236:9f fe80::a236:9fff:f 0 - - 1 - - - ... 119550050209 droped packets on ix1 and 750924631703 droped on ix0 Could be interesting I upgrade to10.1-PRERELEASE? Could there be a problem with the driver? Traffic on ix0: 1.4Gbps output / 600Mbps input Traffic on ix1: 1.2Gbps output PPS on ix0: 163Kpps output / 215Kpps input PPS on ix1: 131Kpps output Thanks for your help. > > > -a > > > On 4 September 2014 16:14, Marcelo Gondim wrote: >> Hi All, >> >> I have an Intel X520-SR2and today was working when all traffic stopped. >> I looked in the logs and found this message: >> >> Sep 4 18:29:53 rt01 kernel: ix1: >> Sep 4 18:29:53 rt01 kernel: CRITICAL: ECC ERROR!! Please Reboot!! >> >> # uname -a >> FreeBSD rt01.xxxxx.com.br 10.0-STABLE FreeBSD 10.0-STABLE #10 r267839: Thu >> Jul 10 15:35:04 BRT 2014 >> root@rt01.xxxxx.com.br:/usr/obj/usr/src/sys/GONDIM10 amd64 >> >> # netstat -m >> 98324/53476/151800 mbufs in use (current/cache/total) >> 98301/44951/143252/1014370 mbuf clusters in use (current/cache/total/max) >> 98301/44897 mbuf+clusters out of packet secondary zone in use >> (current/cache) >> 0/421/421/507184 4k (page size) jumbo clusters in use >> (current/cache/total/max) >> 0/0/0/150276 9k jumbo clusters in use (current/cache/total/max) >> 0/0/0/84530 16k jumbo clusters in use (current/cache/total/max) >> 221183K/104955K/326138K bytes allocated to network (current/cache/total) >> 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) >> 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) >> 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) >> 0/0/0 requests for jumbo clusters denied (4k/9k/16k) >> 0 requests for sfbufs denied >> 0 requests for sfbufs delayed >> 0 requests for I/O initiated by sendfile >> >> Best regards, >> >> Gondim >> From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 09:30:32 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADD411B4 for ; Fri, 5 Sep 2014 09:30:32 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 94FEF14C9 for ; Fri, 5 Sep 2014 09:30:32 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s859UW3E007763 for ; Fri, 5 Sep 2014 09:30:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193246] Bug in IPv6 multicast join(), uncovered by Jenkins Date: Fri, 05 Sep 2014 09:30:32 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ronald-lists@klop.ws X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 09:30:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193246 Ronald Klop changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ronald-lists@klop.ws --- Comment #9 from Ronald Klop --- Not a solution, but does it work as a workaround to add this option on the commandline to java? -Djava.net.preferIPv4Stack=true -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 12:05:10 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89BE5F6A for ; Fri, 5 Sep 2014 12:05:10 +0000 (UTC) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx11.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4CE1BA6 for ; Fri, 5 Sep 2014 12:05:09 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.04,472,1406617200"; d="asc'?scan'208";a="144600218" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx11-out.netapp.com with ESMTP; 05 Sep 2014 05:05:03 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 5 Sep 2014 05:04:55 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::55e3:a7dc:11bd:462%21]) with mapi id 15.00.0913.011; Fri, 5 Sep 2014 05:04:55 -0700 From: "Eggert, Lars" To: Luigi Rizzo Subject: Re: netmap extra rings and buffers Thread-Topic: netmap extra rings and buffers Thread-Index: AQHPyDeKjIx8ly78NE+bckXSokPnmZvxlEGAgAFT5wA= Date: Fri, 5 Sep 2014 12:04:54 +0000 Message-ID: References: <20140904154829.GA80780@onelab2.iet.unipi.it> In-Reply-To: <20140904154829.GA80780@onelab2.iet.unipi.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_D38DAF81-2472-404E-961F-DB255E0C6728"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 12:05:10 -0000 --Apple-Mail=_D38DAF81-2472-404E-961F-DB255E0C6728 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thank you! On 2014-9-4, at 17:48, Luigi Rizzo wrote: > On Thu, Sep 04, 2014 at 11:58:28AM +0000, Eggert, Lars wrote: >> Hi Luigi, >>=20 >> I'm allocating extra rings and/or extra buffers via the = nr_arg1/nr_arg3 parameters for NIOCREGIF. >>=20 >> Once I've done that, how do I actually access those rings and = buffers? >>=20 >> For extra rings, the documentation and example code don't really say = anything. >>=20 >> For extra buffers, the documentation says "nifp->ni_bufs_head will be = the index of the first buffer" but doesn't really explain how I can find = the buffer given its index (since it's not in a ring, the NETMAP_BUF = macro doesn't seem to apply?) The part about "buffers are linked to each = other using the first uint32_t as the index" is also unclear to me. >>=20 >> Do you have some more text or example code that shows how to use = extra rings and buffers? >=20 > the ifield to request extra rings is only important when you want > to make sure that the memory region for a VALE port has also > space to host some pipes. Otherwise, for physical ports (which at > the moment all share the same address space) there is not a real > need to specify it. >=20 > For the extra buffers, remember that NETMAP_BUF() can translate > buffer indexes for any netmap buffer, even those not in a ring. > All it does is grab the base address of the buffer pool from the > ring, and add the buffer index times the buffer size. >=20 > So you can navigate the pool of extra buffers as follows >=20 > uint32_t x =3D nifp->ni_bufs_head; // index of first buf >=20 > void *p =3D NETMAP_BUF(any_ring, x); // address of the first = buffer >=20 > x =3D *((uint32_t *)p); // index of the next buffer >=20 > cheers > luigi --Apple-Mail=_D38DAF81-2472-404E-961F-DB255E0C6728 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVAmm7tZcnpRveo1xAQJdvwQArdgb98zSrUuO4ZwsIM9QRAUqwNZaZUkJ RPWm6tjnUtl/xBFnTYsYSx7rxv41c/eq0gt+wjco8B0I0AMoRBuGGslZ0MAfddne epfyAQflorXAnqK0kdbsc4rTB1qtk8LOaijZBMogPTQiBnviL0NZinU10qrRowiE w0rrn322IBo= =KfOU -----END PGP SIGNATURE----- --Apple-Mail=_D38DAF81-2472-404E-961F-DB255E0C6728-- From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 14:36:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41F2D13F for ; Fri, 5 Sep 2014 14:36:00 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB5431CF0 for ; Fri, 5 Sep 2014 14:35:59 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 210CD139C8 for ; Fri, 5 Sep 2014 11:36:36 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-type:content-type:in-reply-to:references:subject :subject:to:mime-version:user-agent:from:from:date:date :message-id; s=dkim; t=1409927793; x=1410791794; bh=bwosfoB1Y3Ik lc+Y1K+8ltGnIiuAJ8SSBjFa6hrmfDQ=; b=U3o9HuhVivZWadAQZo3d8cBpjiL7 oYVpTxQHMi90hRj4ItJ2Vd69+G0P3KzJ47cKnLpz2jd4QbqzyH7CKePkQ5q6W9RZ FtNJ3jJNivmAa8m4xSZYHHWVonEPZ6tBGu7lSgz6ytFA+IdUlqD7zEJf1qH9lAq/ l9fUAFqPW8C9v8M= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQ_F6abGP8Pp for ; Fri, 5 Sep 2014 11:36:33 -0300 (BRT) Received: from [192.168.88.15] (unknown [186.193.48.8]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id E6F2E139C4 for ; Fri, 5 Sep 2014 11:36:32 -0300 (BRT) Message-ID: <5409CA44.8070203@bsdinfo.com.br> Date: Fri, 05 Sep 2014 11:35:48 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: ixgbe CRITICAL: ECC ERROR!! Please Reboot!! References: <5408F23C.2030309@bsdinfo.com.br> <54091607.9010100@bsdinfo.com.br> In-Reply-To: <54091607.9010100@bsdinfo.com.br> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 14:36:00 -0000 Hi Adrian, I confirmed with the support staff of the room where the server is, that the ambient temperature was normal. On 04/09/2014 22:46, Marcelo Gondim wrote: > On 04/09/2014 20:48, Adrian Chadd wrote: >> Hi, >> >> The only time this has happened to me is because the card overheated. >> Can you check that? > Hi Adrian, > > The room where the equipment is located is very cold but I'll check it > out. > Also seen at the time of the problem, a lot of dropped packets. > > # netstat -idn > ... > ix0 1500 a0:36:9f:2a:6d:ac 18446743423829095869 159 > 750924631703 53285910688 0 0 0 > ix0 - fe80::a236:9f fe80::a236:9fff:f 0 - - > 2 - - - > ix1 1500 a0:36:9f:2a:6d:ae 18446743954328745465 0 > 119550050209 20178077451 0 0 0 > ix1 - fe80::a236:9f fe80::a236:9fff:f 0 - - > 1 - - - > ... > > 119550050209 droped packets on ix1 and 750924631703 droped on ix0 > > Could be interesting I upgrade to10.1-PRERELEASE? > Could there be a problem with the driver? > > Traffic on ix0: 1.4Gbps output / 600Mbps input > Traffic on ix1: 1.2Gbps output > > PPS on ix0: 163Kpps output / 215Kpps input > PPS on ix1: 131Kpps output > > Thanks for your help. >> >> >> -a >> >> >> On 4 September 2014 16:14, Marcelo Gondim wrote: >>> Hi All, >>> >>> I have an Intel X520-SR2and today was working when all traffic stopped. >>> I looked in the logs and found this message: >>> >>> Sep 4 18:29:53 rt01 kernel: ix1: >>> Sep 4 18:29:53 rt01 kernel: CRITICAL: ECC ERROR!! Please Reboot!! >>> >>> # uname -a >>> FreeBSD rt01.xxxxx.com.br 10.0-STABLE FreeBSD 10.0-STABLE #10 >>> r267839: Thu >>> Jul 10 15:35:04 BRT 2014 >>> root@rt01.xxxxx.com.br:/usr/obj/usr/src/sys/GONDIM10 amd64 >>> >>> # netstat -m >>> 98324/53476/151800 mbufs in use (current/cache/total) >>> 98301/44951/143252/1014370 mbuf clusters in use >>> (current/cache/total/max) >>> 98301/44897 mbuf+clusters out of packet secondary zone in use >>> (current/cache) >>> 0/421/421/507184 4k (page size) jumbo clusters in use >>> (current/cache/total/max) >>> 0/0/0/150276 9k jumbo clusters in use (current/cache/total/max) >>> 0/0/0/84530 16k jumbo clusters in use (current/cache/total/max) >>> 221183K/104955K/326138K bytes allocated to network >>> (current/cache/total) >>> 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) >>> 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) >>> 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) >>> 0/0/0 requests for jumbo clusters denied (4k/9k/16k) >>> 0 requests for sfbufs denied >>> 0 requests for sfbufs delayed >>> 0 requests for I/O initiated by sendfile >>> >>> Best regards, >>> >>> Gondim >>> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 15:25:58 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27997C4A for ; Fri, 5 Sep 2014 15:25:58 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0E8F113C9 for ; Fri, 5 Sep 2014 15:25:58 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s85FPvhm047277 for ; Fri, 5 Sep 2014 15:25:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193246] Bug in IPv6 multicast join(), uncovered by Jenkins Date: Fri, 05 Sep 2014 15:25:58 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: rodrigc@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 15:25:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193246 --- Comment #10 from Craig Rodrigues --- Ronald, Thanks for the tip. java -Djava.net.preferIPv4Stack=true MulticastTest seems to work around the problem. I would still like to see FreeBSD fixed so that this workaround is not required. Even though it is a lot of work, I would like to see Java on FreeBSD behave out of the box, "just like Linux", without the FreeBSD community needing to push lots of patches upstream to different Java software authors. I want there to be less motivation for people to migrate from FreeBSD to Linux if they are deploying Java applications. That's why I've spent the time to analyze the problem and reporting my findings in this bug report. I find this audit trail is quite interesting. :) -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 18:37:59 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD111E47; Fri, 5 Sep 2014 18:37:59 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4121C7D; Fri, 5 Sep 2014 18:37:59 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B84EC1FE027; Fri, 5 Sep 2014 20:37:56 +0200 (CEST) Message-ID: <540A0301.9040701@selasky.org> Date: Fri, 05 Sep 2014 20:37:53 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: FreeBSD Current , "freebsd-net@freebsd.org" , Scott Long Subject: [RFC] Patch to improve TSO limitation formula in general Content-Type: multipart/mixed; boundary="------------020609020709040903060408" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 18:38:00 -0000 This is a multi-part message in MIME format. --------------020609020709040903060408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I've tested the attached patch with success and would like to have some feedback from other FreeBSD network developers. The problem is that the current TSO limitation only limits the number of bytes that can be transferred in a TSO packet and not the number of mbuf's. The current solution is to have a quick and dirty custom m_dup() in the TX path to re-allocate the mbuf chains into 4K ones to make it simple. All of this hack can be avoided if the definition of the TSO limit can be changed a bit, like shown here: /* + * Structure defining hardware TSO limits. + */ +struct if_tso_limit { + u_int raw_value[0]; /* access all fields as one */ + u_char frag_count; /* maximum number of fragments: 1..255 */ + u_char frag_size_log2; /* maximum fragment size: 2 ** (12..16) */ + u_char hdr_size_log2; /* maximum header size: 2 ** (2..8) */ + u_char reserved; /* zero */ +}; First we need to know the maximum fragment count. Typical value is 32. Second we need to know the maximum fragment size. Typical value is 4K. Last we need to know of any headers that should be subtracted from the maximum. Hence this code is running in the fast path, I would like to use "u_char" for all fields and allow copy-only access as a "u_int" as an optimization. This avoids cludges and messing with additional header files. I would like to push this patch after some more testing to -current and then to 10-stable hopefully before the coming 10-release, because the current solution is affecting performance of the Mellanox based network adapters in an unfair way. For example by setting the current TSO limit to 32KBytes which will be OK for all-2K fragments, we see a severe degradation in performance. Even though the hardware is fully capable of transmitting 16 4K mbufs. Comments and reviews are welcome! --HPS --------------020609020709040903060408 Content-Type: text/x-diff; name="tso.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tso.diff" === sys/dev/oce/oce_if.c ================================================================== --- sys/dev/oce/oce_if.c (revision 270996) +++ sys/dev/oce/oce_if.c (local) @@ -1731,7 +1731,9 @@ sc->ifp->if_baudrate = IF_Gbps(10); #if __FreeBSD_version >= 1000000 - sc->ifp->if_hw_tsomax = OCE_MAX_TSO_SIZE; + sc->ifp->if_hw_tsomax.frag_count = 29; /* 29 elements */ + sc->ifp->if_hw_tsomax.frag_size_log2 = 12; /* 4K */ + sc->ifp->if_hw_tsomax.hdr_size_log2 = 5; /* ETH+VLAN < 2**5 */ #endif ether_ifattach(sc->ifp, sc->macaddr.mac_addr); === sys/dev/oce/oce_if.h ================================================================== --- sys/dev/oce/oce_if.h (revision 270996) +++ sys/dev/oce/oce_if.h (local) @@ -152,7 +152,6 @@ #define OCE_MAX_TX_ELEMENTS 29 #define OCE_MAX_TX_DESC 1024 #define OCE_MAX_TX_SIZE 65535 -#define OCE_MAX_TSO_SIZE (65535 - ETHER_HDR_LEN) #define OCE_MAX_RX_SIZE 4096 #define OCE_MAX_RQ_POSTS 255 #define OCE_DEFAULT_PROMISCUOUS 0 === sys/dev/vmware/vmxnet3/if_vmx.c ================================================================== --- sys/dev/vmware/vmxnet3/if_vmx.c (revision 270996) +++ sys/dev/vmware/vmxnet3/if_vmx.c (local) @@ -1722,7 +1722,9 @@ ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; ifp->if_init = vmxnet3_init; ifp->if_ioctl = vmxnet3_ioctl; - ifp->if_hw_tsomax = VMXNET3_TSO_MAXSIZE; + ifp->if_hw_tsomax.frag_count = VMXNET3_TX_MAXSEGS; + ifp->if_hw_tsomax.frag_size_log2 = VMXNET3_TX_MAXSEGSHIFT; + ifp->if_hw_tsomax.hdr_size_log2 = 5; /* ETH+VLAN < 2**5 */ #ifdef VMXNET3_LEGACY_TX ifp->if_start = vmxnet3_start; === sys/dev/vmware/vmxnet3/if_vmxvar.h ================================================================== --- sys/dev/vmware/vmxnet3/if_vmxvar.h (revision 270996) +++ sys/dev/vmware/vmxnet3/if_vmxvar.h (local) @@ -277,14 +277,13 @@ */ #define VMXNET3_TX_MAXSEGS 32 #define VMXNET3_TX_MAXSIZE (VMXNET3_TX_MAXSEGS * MCLBYTES) -#define VMXNET3_TSO_MAXSIZE \ - (VMXNET3_TX_MAXSIZE - sizeof(struct ether_vlan_header)) /* * Maximum support Tx segments size. The length field in the * Tx descriptor is 14 bits. */ -#define VMXNET3_TX_MAXSEGSIZE (1 << 14) +#define VMXNET3_TX_MAXSEGSHIFT 14 +#define VMXNET3_TX_MAXSEGSIZE (1 << VMXNET3_TX_MAXSEGSHIFT) /* * The maximum number of Rx segments we accept. When LRO is enabled, === sys/dev/xen/netfront/netfront.c ================================================================== --- sys/dev/xen/netfront/netfront.c (revision 270996) +++ sys/dev/xen/netfront/netfront.c (local) @@ -134,7 +134,6 @@ * to mirror the Linux MAX_SKB_FRAGS constant. */ #define MAX_TX_REQ_FRAGS (65536 / PAGE_SIZE + 2) -#define NF_TSO_MAXBURST ((IP_MAXPACKET / PAGE_SIZE) * MCLBYTES) #define RX_COPY_THRESHOLD 256 @@ -2102,7 +2101,9 @@ ifp->if_hwassist = XN_CSUM_FEATURES; ifp->if_capabilities = IFCAP_HWCSUM; - ifp->if_hw_tsomax = NF_TSO_MAXBURST; + ifp->if_hw_tsomax.frag_count = MAX_TX_REQ_FRAGS; + ifp->if_hw_tsomax.frag_size_log2 = PAGE_SHIFT; + ifp->if_hw_tsomax.hdr_size_log2 = 5; /* ETH+VLAN < 2**5 */ ether_ifattach(ifp, np->mac); callout_init(&np->xn_stat_ch, CALLOUT_MPSAFE); === sys/net/if.c ================================================================== --- sys/net/if.c (revision 270996) +++ sys/net/if.c (local) @@ -445,6 +445,7 @@ ifp->if_index = idx; ifp->if_type = type; ifp->if_alloctype = type; + ifp->if_hw_tsomax = IF_TSO_LIMIT_DEFAULT(); if (if_com_alloc[type] != NULL) { ifp->if_l2com = if_com_alloc[type](type, ifp); if (ifp->if_l2com == NULL) { @@ -657,16 +658,6 @@ TAILQ_INSERT_HEAD(&ifp->if_addrhead, ifa, ifa_link); /* Reliably crash if used uninitialized. */ ifp->if_broadcastaddr = NULL; - -#if defined(INET) || defined(INET6) - /* Initialize to max value. */ - if (ifp->if_hw_tsomax == 0) - ifp->if_hw_tsomax = min(IP_MAXPACKET, 32 * MCLBYTES - - (ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN)); - KASSERT(ifp->if_hw_tsomax <= IP_MAXPACKET && - ifp->if_hw_tsomax >= IP_MAXPACKET / 8, - ("%s: tsomax outside of range", __func__)); -#endif } #ifdef VIMAGE else { === sys/net/if_lagg.c ================================================================== --- sys/net/if_lagg.c (revision 270996) +++ sys/net/if_lagg.c (local) @@ -445,11 +445,7 @@ struct lagg_port *lp; int cap = ~0, ena = ~0; u_long hwa = ~0UL; -#if defined(INET) || defined(INET6) - u_int hw_tsomax = IP_MAXPACKET; /* Initialize to the maximum value. */ -#else - u_int hw_tsomax = ~0; /* if_hw_tsomax is only for INET/INET6, but.. */ -#endif + struct if_tso_limit hw_tsomax = IF_TSO_LIMIT_DEFAULT(); LAGG_WLOCK_ASSERT(sc); @@ -458,10 +454,9 @@ cap &= lp->lp_ifp->if_capabilities; ena &= lp->lp_ifp->if_capenable; hwa &= lp->lp_ifp->if_hwassist; - /* Set to the minimum value of the lagg ports. */ - if (lp->lp_ifp->if_hw_tsomax < hw_tsomax && - lp->lp_ifp->if_hw_tsomax > 0) - hw_tsomax = lp->lp_ifp->if_hw_tsomax; + /* Set to the common value of the lagg ports. */ + hw_tsomax = IF_TSO_LIMIT_COMMON(&hw_tsomax, + &lp->lp_ifp->if_hw_tsomax); } cap = (cap == ~0 ? 0 : cap); ena = (ena == ~0 ? 0 : ena); @@ -470,7 +465,7 @@ if (sc->sc_ifp->if_capabilities != cap || sc->sc_ifp->if_capenable != ena || sc->sc_ifp->if_hwassist != hwa || - sc->sc_ifp->if_hw_tsomax != hw_tsomax) { + IF_TSO_LIMIT_CMP(&sc->sc_ifp->if_hw_tsomax, !=, &hw_tsomax)) { sc->sc_ifp->if_capabilities = cap; sc->sc_ifp->if_capenable = ena; sc->sc_ifp->if_hwassist = hwa; === sys/net/if_var.h ================================================================== --- sys/net/if_var.h (revision 270996) +++ sys/net/if_var.h (local) @@ -120,6 +120,36 @@ typedef uint64_t (*if_get_counter_t)(if_t, ifnet_counter); /* + * Structure defining hardware TSO limits. + */ +struct if_tso_limit { + u_int raw_value[0]; /* access all fields as one */ + u_char frag_count; /* maximum number of fragments: 1..255 */ + u_char frag_size_log2; /* maximum fragment size: 2 ** (12..16) */ + u_char hdr_size_log2; /* maximum header size: 2 ** (2..8) */ + u_char reserved; /* zero */ +}; + +#define IF_TSO_LIMIT_DEFAULT() ({ \ +struct if_tso_limit tso_temp = { \ + .frag_count = 128, \ + .frag_size_log2 = 16, \ + .hdr_size_log2 = 2, \ + .reserved = 0, \ +}; tso_temp; }) + +#define IF_TSO_LIMIT_COMMON(a,b) ({ \ +struct if_tso_limit tso_temp = { \ + .frag_count = min((a)->frag_count, (b)->frag_count), \ + .frag_size_log2 = min((a)->frag_size_log2, (b)->frag_size_log2),\ + .hdr_size_log2 = max((a)->hdr_size_log2, (b)->hdr_size_log2), \ + .reserved = 0, \ +}; tso_temp; }) + +#define IF_TSO_LIMIT_CMP(a,op,b) \ + ((a)->raw_value[0] op (b)->raw_value[0]) + +/* * Structure defining a network interface. * * Size ILP32: 592 (approx) @@ -222,10 +252,8 @@ if_get_counter_t if_get_counter; /* get counter values */ /* Stuff that's only temporary and doesn't belong here. */ - u_int if_hw_tsomax; /* tso burst length limit, the minimum - * is (IP_MAXPACKET / 8). - * XXXAO: Have to find a better place - * for it eventually. */ + struct if_tso_limit if_hw_tsomax; + /* * Old, racy and expensive statistics, should not be used in * new drivers. === sys/net/if_vlan.c ================================================================== --- sys/net/if_vlan.c (revision 270996) +++ sys/net/if_vlan.c (local) @@ -1511,8 +1511,8 @@ * propagate the hardware-assisted flag. TSO on VLANs * does not necessarily require hardware VLAN tagging. */ - if (p->if_hw_tsomax > 0) - ifp->if_hw_tsomax = p->if_hw_tsomax; + ifp->if_hw_tsomax = IF_TSO_LIMIT_COMMON(&ifp->if_hw_tsomax, + &p->if_hw_tsomax); if (p->if_capabilities & IFCAP_VLAN_HWTSO) ifp->if_capabilities |= p->if_capabilities & IFCAP_TSO; if (p->if_capenable & IFCAP_VLAN_HWTSO) { === sys/netinet/tcp_output.c ================================================================== --- sys/netinet/tcp_output.c (revision 270996) +++ sys/netinet/tcp_output.c (local) @@ -767,9 +767,70 @@ flags &= ~TH_FIN; if (tso) { + struct if_tso_limit if_hw_tsomax; + struct mbuf *mb; + u_int rem_frags; + u_int moff; + int max_len; + + /* copy TSO limit information */ + if_hw_tsomax.raw_value[0] = tp->t_tsomax; + + /* compute maximum TSO length */ + max_len = (((u_int)if_hw_tsomax.frag_count) << + if_hw_tsomax.frag_size_log2) - hdrlen - + (1 << if_hw_tsomax.hdr_size_log2); + + /* clamp maximum length value */ + if (max_len > IP_MAXPACKET) + max_len = IP_MAXPACKET; + else if (max_len < 0) + max_len = 0; + + /* get smallest length */ + if (len > (u_int)max_len) { + sendalot = 1; + len = (u_int)max_len; + } + + /* get remaining fragments */ + rem_frags = if_hw_tsomax.frag_count; + KASSERT(ipoptlen == 0, ("%s: TSO can't do IP options", __func__)); + max_len = 0; + mb = sbsndptr(&so->so_snd, off, len, &moff); + + /* now make sure the number of fragments fit too */ + while (mb != NULL && (u_int)max_len < len) { + u_int cur_length; + u_int cur_frags; + + /* + * Get length of mbuf fragment and how + * many hardware frags it would use: + */ + cur_length = (mb->m_len - moff); + cur_frags = (cur_length + + (1 << if_hw_tsomax.frag_size_log2) - 1) + >> if_hw_tsomax.frag_size_log2; + + /* Handle special case: Zero Length Mbuf */ + if (cur_frags == 0) + cur_frags = 1; + + /* Check if fragment limit will be exceeded */ + if (cur_frags >= rem_frags) { + max_len += min(cur_length, rem_frags << if_hw_tsomax.frag_size_log2); + break; + } + max_len += cur_length; + rem_frags -= cur_frags; + moff = 0; + mb = mb->m_next; + } + /* * Limit a burst to t_tsomax minus IP, * TCP and options length to keep ip->ip_len @@ -776,8 +837,8 @@ * from overflowing or exceeding the maximum * length allowed by the network interface. */ - if (len > tp->t_tsomax - hdrlen) { - len = tp->t_tsomax - hdrlen; + if (len > (u_int)max_len) { + len = (u_int)max_len; sendalot = 1; } === sys/netinet/tcp_subr.c ================================================================== --- sys/netinet/tcp_subr.c (revision 270996) +++ sys/netinet/tcp_subr.c (local) @@ -1818,7 +1818,7 @@ if (ifp->if_capenable & IFCAP_TSO4 && ifp->if_hwassist & CSUM_TSO) { cap->ifcap |= CSUM_TSO; - cap->tsomax = ifp->if_hw_tsomax; + cap->tsomax = ifp->if_hw_tsomax.raw_value[0]; } } RTFREE(sro.ro_rt); @@ -1857,7 +1857,7 @@ if (ifp->if_capenable & IFCAP_TSO6 && ifp->if_hwassist & CSUM_TSO) { cap->ifcap |= CSUM_TSO; - cap->tsomax = ifp->if_hw_tsomax; + cap->tsomax = ifp->if_hw_tsomax.raw_value[0]; } } RTFREE(sro6.ro_rt); --------------020609020709040903060408-- From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 19:49:56 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F13264C for ; Fri, 5 Sep 2014 19:49:56 +0000 (UTC) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA5191498 for ; Fri, 5 Sep 2014 19:49:55 +0000 (UTC) Received: by mail-qg0-f52.google.com with SMTP id z60so12130141qgd.25 for ; Fri, 05 Sep 2014 12:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=S0rz/Dce34R+tlx9KQQCOgchNhDd2a1BBz5MUrCQnQk=; b=ZwAj++8of1Z3V1atCRmVn1UfSxr5zk7NjKEcMqQcTgf/BP2yVXsQwEtFJftxLxBLs/ dM7vqkCC/Kta6V0M4+bIyb37ww5YkdBmjp0Y3rMdwEDe9V440BjNAKU1lbqNVJ6xR/RB lnRW91Pv/nDnFKiPta/3W3Spb8Maqe7T2NAsOWPn+1WT4j4M3vqBJmS9V4/3VOkY0bx1 Sc1aOS18hqWkLh674l8AR0+QDh7TbYYvTzMJv47+2jxZLsRJCyHaQNLv4nNCddFlXKtw 996CVpXKBPRSpEIfN9dWprRnNqOU6DCo/48TQaxT2c+irz8GuMdJySgW6yjr7KWvZq3i i7bg== MIME-Version: 1.0 X-Received: by 10.224.46.8 with SMTP id h8mr22440279qaf.6.1409946595010; Fri, 05 Sep 2014 12:49:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Fri, 5 Sep 2014 12:49:54 -0700 (PDT) In-Reply-To: <5409CA44.8070203@bsdinfo.com.br> References: <5408F23C.2030309@bsdinfo.com.br> <54091607.9010100@bsdinfo.com.br> <5409CA44.8070203@bsdinfo.com.br> Date: Fri, 5 Sep 2014 12:49:54 -0700 X-Google-Sender-Auth: CZp-jNcYcmv_zW_YnrLenjEUFhc Message-ID: Subject: Re: ixgbe CRITICAL: ECC ERROR!! Please Reboot!! From: Adrian Chadd To: Marcelo Gondim Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 19:49:56 -0000 Hi, But is the airflow in the unit sufficient? I had this problem at a previous job - the box was running fine, the room was very cold, but the internal fans in the server were set to "be very quiet". It wasn't enough to keep the ixgbe NICs happy. I had to change the fan settings to "just always run full speed". The fan temperature feedback loop was based on sensors on the CPU, _not_ on the peripherals. -a On 5 September 2014 07:35, Marcelo Gondim wrote: > Hi Adrian, > > I confirmed with the support staff of the room where the server is, that the > ambient temperature was normal. > > > On 04/09/2014 22:46, Marcelo Gondim wrote: >> >> On 04/09/2014 20:48, Adrian Chadd wrote: >>> >>> Hi, >>> >>> The only time this has happened to me is because the card overheated. >>> Can you check that? >> >> Hi Adrian, >> >> The room where the equipment is located is very cold but I'll check it >> out. >> Also seen at the time of the problem, a lot of dropped packets. >> >> # netstat -idn >> ... >> ix0 1500 a0:36:9f:2a:6d:ac 18446743423829095869 159 >> 750924631703 53285910688 0 0 0 >> ix0 - fe80::a236:9f fe80::a236:9fff:f 0 - - 2 >> - - - >> ix1 1500 a0:36:9f:2a:6d:ae 18446743954328745465 0 >> 119550050209 20178077451 0 0 0 >> ix1 - fe80::a236:9f fe80::a236:9fff:f 0 - - 1 >> - - - >> ... >> >> 119550050209 droped packets on ix1 and 750924631703 droped on ix0 >> >> Could be interesting I upgrade to10.1-PRERELEASE? >> Could there be a problem with the driver? >> >> Traffic on ix0: 1.4Gbps output / 600Mbps input >> Traffic on ix1: 1.2Gbps output >> >> PPS on ix0: 163Kpps output / 215Kpps input >> PPS on ix1: 131Kpps output >> >> Thanks for your help. >>> >>> >>> >>> -a >>> >>> >>> On 4 September 2014 16:14, Marcelo Gondim wrote: >>>> >>>> Hi All, >>>> >>>> I have an Intel X520-SR2and today was working when all traffic stopped. >>>> I looked in the logs and found this message: >>>> >>>> Sep 4 18:29:53 rt01 kernel: ix1: >>>> Sep 4 18:29:53 rt01 kernel: CRITICAL: ECC ERROR!! Please Reboot!! >>>> >>>> # uname -a >>>> FreeBSD rt01.xxxxx.com.br 10.0-STABLE FreeBSD 10.0-STABLE #10 r267839: >>>> Thu >>>> Jul 10 15:35:04 BRT 2014 >>>> root@rt01.xxxxx.com.br:/usr/obj/usr/src/sys/GONDIM10 amd64 >>>> >>>> # netstat -m >>>> 98324/53476/151800 mbufs in use (current/cache/total) >>>> 98301/44951/143252/1014370 mbuf clusters in use >>>> (current/cache/total/max) >>>> 98301/44897 mbuf+clusters out of packet secondary zone in use >>>> (current/cache) >>>> 0/421/421/507184 4k (page size) jumbo clusters in use >>>> (current/cache/total/max) >>>> 0/0/0/150276 9k jumbo clusters in use (current/cache/total/max) >>>> 0/0/0/84530 16k jumbo clusters in use (current/cache/total/max) >>>> 221183K/104955K/326138K bytes allocated to network (current/cache/total) >>>> 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) >>>> 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) >>>> 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) >>>> 0/0/0 requests for jumbo clusters denied (4k/9k/16k) >>>> 0 requests for sfbufs denied >>>> 0 requests for sfbufs delayed >>>> 0 requests for I/O initiated by sendfile >>>> >>>> Best regards, >>>> >>>> Gondim >>>> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > > -- > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 20:17:11 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF377E74 for ; Fri, 5 Sep 2014 20:17:11 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8A53218D3 for ; Fri, 5 Sep 2014 20:17:11 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id DA833139CF for ; Fri, 5 Sep 2014 17:17:47 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:to:mime-version :user-agent:from:from:date:date:message-id; s=dkim; t= 1409948267; x=1410812268; bh=KaCLbMMnVattcHMW/vzreu5Ve0XjKZ4R3g8 4hc6jXKk=; b=aUahM7DkrbhFTc65pmsL1jp2HeCLe4oi4siSX1bIE5nUem1vWXr k1ejeDzWlzxjGCH0TIf+WRGQ5/Lq7xo65TorlOluqX5V/cztsCcld0hkQBs2JG87 C8LYjs4DLcUvK7NWMHi6spY8crJcvCuJcs/7wYIlq9U3PZ9iYBJZKL+g= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a_k7NIWKKffu for ; Fri, 5 Sep 2014 17:17:47 -0300 (BRT) Received: from [192.168.88.15] (unknown [186.193.48.8]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id 99F9E139CA; Fri, 5 Sep 2014 17:17:46 -0300 (BRT) Message-ID: <540A1A3E.2040306@bsdinfo.com.br> Date: Fri, 05 Sep 2014 17:17:02 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: ixgbe CRITICAL: ECC ERROR!! Please Reboot!! References: <5408F23C.2030309@bsdinfo.com.br> <54091607.9010100@bsdinfo.com.br> <5409CA44.8070203@bsdinfo.com.br> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 20:17:11 -0000 On 05/09/2014 16:49, Adrian Chadd wrote: > Hi, > > But is the airflow in the unit sufficient? > > I had this problem at a previous job - the box was running fine, the > room was very cold, but the internal fans in the server were set to > "be very quiet". It wasn't enough to keep the ixgbe NICs happy. I had > to change the fan settings to "just always run full speed". > > The fan temperature feedback loop was based on sensors on the CPU, > _not_ on the peripherals. Hi Adrian, Ummm. I'll check it and improve internal cooling. :) She is not happy and I'm also not. rsrsrsr Cheers, > > > -a > > > On 5 September 2014 07:35, Marcelo Gondim wrote: >> Hi Adrian, >> >> I confirmed with the support staff of the room where the server is, that the >> ambient temperature was normal. >> >> >> On 04/09/2014 22:46, Marcelo Gondim wrote: >>> On 04/09/2014 20:48, Adrian Chadd wrote: >>>> Hi, >>>> >>>> The only time this has happened to me is because the card overheated. >>>> Can you check that? >>> Hi Adrian, >>> >>> The room where the equipment is located is very cold but I'll check it >>> out. >>> Also seen at the time of the problem, a lot of dropped packets. >>> >>> # netstat -idn >>> ... >>> ix0 1500 a0:36:9f:2a:6d:ac 18446743423829095869 159 >>> 750924631703 53285910688 0 0 0 >>> ix0 - fe80::a236:9f fe80::a236:9fff:f 0 - - 2 >>> - - - >>> ix1 1500 a0:36:9f:2a:6d:ae 18446743954328745465 0 >>> 119550050209 20178077451 0 0 0 >>> ix1 - fe80::a236:9f fe80::a236:9fff:f 0 - - 1 >>> - - - >>> ... >>> >>> 119550050209 droped packets on ix1 and 750924631703 droped on ix0 >>> >>> Could be interesting I upgrade to10.1-PRERELEASE? >>> Could there be a problem with the driver? >>> >>> Traffic on ix0: 1.4Gbps output / 600Mbps input >>> Traffic on ix1: 1.2Gbps output >>> >>> PPS on ix0: 163Kpps output / 215Kpps input >>> PPS on ix1: 131Kpps output >>> >>> Thanks for your help. >>>> >>>> >>>> -a >>>> >>>> >>>> On 4 September 2014 16:14, Marcelo Gondim wrote: >>>>> Hi All, >>>>> >>>>> I have an Intel X520-SR2and today was working when all traffic stopped. >>>>> I looked in the logs and found this message: >>>>> >>>>> Sep 4 18:29:53 rt01 kernel: ix1: >>>>> Sep 4 18:29:53 rt01 kernel: CRITICAL: ECC ERROR!! Please Reboot!! >>>>> >>>>> # uname -a >>>>> FreeBSD rt01.xxxxx.com.br 10.0-STABLE FreeBSD 10.0-STABLE #10 r267839: >>>>> Thu >>>>> Jul 10 15:35:04 BRT 2014 >>>>> root@rt01.xxxxx.com.br:/usr/obj/usr/src/sys/GONDIM10 amd64 >>>>> >>>>> # netstat -m >>>>> 98324/53476/151800 mbufs in use (current/cache/total) >>>>> 98301/44951/143252/1014370 mbuf clusters in use >>>>> (current/cache/total/max) >>>>> 98301/44897 mbuf+clusters out of packet secondary zone in use >>>>> (current/cache) >>>>> 0/421/421/507184 4k (page size) jumbo clusters in use >>>>> (current/cache/total/max) >>>>> 0/0/0/150276 9k jumbo clusters in use (current/cache/total/max) >>>>> 0/0/0/84530 16k jumbo clusters in use (current/cache/total/max) >>>>> 221183K/104955K/326138K bytes allocated to network (current/cache/total) >>>>> 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) >>>>> 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) >>>>> 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) >>>>> 0/0/0 requests for jumbo clusters denied (4k/9k/16k) >>>>> 0 requests for sfbufs denied >>>>> 0 requests for sfbufs delayed >>>>> 0 requests for I/O initiated by sendfile >>>>> >>>>> Best regards, >>>>> >>>>> Gondim From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 21:19:59 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A3E5203; Fri, 5 Sep 2014 21:19:59 +0000 (UTC) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 156051EBA; Fri, 5 Sep 2014 21:19:59 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id lf10so1021817pab.14 for ; Fri, 05 Sep 2014 14:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rjaOasgCmEznfIHhnkzXm+3EVP16SeM7c2lurW0ryY4=; b=dq5u+3lXvb8XTAfWPSWzr+5uJe0F/RZneCmjpSozYWTKkM5YwUZ7+JjM16pcy5LkYN 7TRGymZjnDqG+8vDb+lNHjzNPKPAyuroADnoDc8ZmssttZQXPZVdeb67z/v7/yRuv9Pd OX0SkrC4Pu0uCQ6h5zR3EmOLQ7vMlTUidQDe5EtsEoqnNpZLYDXCh+n7NyOhKU3hEb2t ISI/eMcw4jXhYGB06k+wOOvSE1IVwh6Fy1pCVWIpH0kCgCIetfq2GsNWqBzdZIQsSIyR keDfDrfKZQzSIw9V3WiY4x3+Uc2SXjx2k/1gnQLuxW0/tvXo6eBJA7BQaNp90CNIQtp5 FHdA== X-Received: by 10.70.52.199 with SMTP id v7mr25947614pdo.49.1409951998448; Fri, 05 Sep 2014 14:19:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.55.162 with HTTP; Fri, 5 Sep 2014 14:19:18 -0700 (PDT) In-Reply-To: <540A0301.9040701@selasky.org> References: <540A0301.9040701@selasky.org> From: Eric Joyner Date: Fri, 5 Sep 2014 14:19:18 -0700 Message-ID: Subject: Re: [RFC] Patch to improve TSO limitation formula in general To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , FreeBSD Current , Scott Long , Jack F Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 21:19:59 -0000 There are some concerns if we use this with devices that ixl supports: - The maximum fragment size is 16KB-1, which isn't a power of 2. - You can't get the maximum TSO size for ixl devices by multiplying the maximum number of fragments by the maximum size. Instead the number of fragments is AFAIK unlimited, but a segment can only span 8 mbufs (including the [up to 3] mbufs containing the header), and the maximum TSO size is 256KB. And one question: - Is hdr_size_log2 supposed to be the length of the L2 header? We can fit 254 L2 bytes in our hardware during a TSO, so if that's the value, I guess that's fine, barring the it-not-being-a-power-of-2 issue. With all that said, the 8 mbuf limit per segment issue is a TSO limitation that we'd like to notify the stack about, so I wonder if that could be incorporated along with this. Right now, our driver checks to see if a segment in a TSO spans more than six mbufs and then m_defrag()'s the entire chain if one exists; it's less than optimal but necessary to prevent errors. - Eric --- - Eric Joyner On Fri, Sep 5, 2014 at 11:37 AM, Hans Petter Selasky wrote: > Hi, > > I've tested the attached patch with success and would like to have some > feedback from other FreeBSD network developers. The problem is that the > current TSO limitation only limits the number of bytes that can be > transferred in a TSO packet and not the number of mbuf's. > > The current solution is to have a quick and dirty custom m_dup() in the TX > path to re-allocate the mbuf chains into 4K ones to make it simple. All of > this hack can be avoided if the definition of the TSO limit can be changed > a bit, like shown here: > > > /* > + * Structure defining hardware TSO limits. > + */ > +struct if_tso_limit { > + u_int raw_value[0]; /* access all fields as one */ > + u_char frag_count; /* maximum number of fragments: 1..255 */ > + u_char frag_size_log2; /* maximum fragment size: 2 ** (12..16) */ > + u_char hdr_size_log2; /* maximum header size: 2 ** (2..8) */ > + u_char reserved; /* zero */ > +}; > > > First we need to know the maximum fragment count. Typical value is 32. > Second we need to know the maximum fragment size. Typical value is 4K. > Last we need to know of any headers that should be subtracted from the > maximum. Hence this code is running in the fast path, I would like to use > "u_char" for all fields and allow copy-only access as a "u_int" as an > optimization. This avoids cludges and messing with additional header files. > > I would like to push this patch after some more testing to -current and > then to 10-stable hopefully before the coming 10-release, because the > current solution is affecting performance of the Mellanox based network > adapters in an unfair way. For example by setting the current TSO limit to > 32KBytes which will be OK for all-2K fragments, we see a severe degradation > in performance. Even though the hardware is fully capable of transmitting > 16 4K mbufs. > > Comments and reviews are welcome! > > --HPS > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 21:44:50 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33DE6219; Fri, 5 Sep 2014 21:44:50 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E831A1276; Fri, 5 Sep 2014 21:44:49 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 040031FE027; Fri, 5 Sep 2014 23:44:46 +0200 (CEST) Message-ID: <540A2ECB.8010502@selasky.org> Date: Fri, 05 Sep 2014 23:44:43 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Eric Joyner Subject: Re: [RFC] Patch to improve TSO limitation formula in general References: <540A0301.9040701@selasky.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , FreeBSD Current , Scott Long , Jack F Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 21:44:50 -0000 On 09/05/14 23:19, Eric Joyner wrote: > There are some concerns if we use this with devices that ixl supports: > > - The maximum fragment size is 16KB-1, which isn't a power of 2. > Hi Eric, Multiplying by powers of two are more fast, than non-powers of two. So in this case you would have to use 8KB as a maximum. > - You can't get the maximum TSO size for ixl devices by multiplying the > maximum number of fragments by the maximum size. > Instead the number of fragments is AFAIK unlimited, but a segment can only > span 8 mbufs (including the [up to 3] mbufs containing the header), and the > maximum TSO size is 256KB. > > And one question: > > - Is hdr_size_log2 supposed to be the length of the L2 header? We can fit > 254 L2 bytes in our hardware during a TSO, so if that's the value, I guess > that's fine, barring the it-not-being-a-power-of-2 issue. This is the ethernet / vlan headers. It is added with the TCP/IP-header in the end. > > With all that said, the 8 mbuf limit per segment issue is a TSO limitation > that we'd like to notify the stack about, so I wonder if that could be > incorporated along with this. Right now, our driver checks to see if a > segment in a TSO spans more than six mbufs and then m_defrag()'s the entire > chain if one exists; it's less than optimal but necessary to prevent errors. It is not impossible to move from log2 syntax to non-log2 syntax, hence the logic will be exactly the same, only that the required division and multiplication will have a bit overhead I guess. Could you make a patch on top of my patch with the changes you think are required to fully support the ixl hardware? Or propose a new patch which also serves the MLX needs? Thank you! --HPS From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 22:09:21 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2FA8B0B; Fri, 5 Sep 2014 22:09:21 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 26E741502; Fri, 5 Sep 2014 22:09:20 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8EAEEtClSDaFve/2dsb2JhbABag2BXBIJ4xgwKhnlTAYEed4QDAQEBAwEBAQEgBCcdAwsFFhIGERkCBCUBCRgOBggHBAEcBIgZCA2pcpU+AReOdgYBAQEaGRsHgnmBUwWTRIIqg3uEX5NKgWcegXghLweBAAgXIoEHAQEB X-IronPort-AV: E=Sophos;i="5.04,475,1406606400"; d="scan'208";a="151956192" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 05 Sep 2014 18:09:12 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C6D7FB406A; Fri, 5 Sep 2014 18:09:12 -0400 (EDT) Date: Fri, 5 Sep 2014 18:09:12 -0400 (EDT) From: Rick Macklem To: Hans Petter Selasky Message-ID: <1762951742.33012989.1409954952800.JavaMail.root@uoguelph.ca> In-Reply-To: <540A2ECB.8010502@selasky.org> Subject: Re: [RFC] Patch to improve TSO limitation formula in general MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_33012987_2077484506.1409954952678" X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-net@freebsd.org, Eric Joyner , FreeBSD Current , Scott Long , Jack F Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 22:09:21 -0000 ------=_Part_33012987_2077484506.1409954952678 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hans Petter Selesky wrote: > On 09/05/14 23:19, Eric Joyner wrote: > > There are some concerns if we use this with devices that ixl > > supports: > > > > - The maximum fragment size is 16KB-1, which isn't a power of 2. > > > > Hi Eric, > > Multiplying by powers of two are more fast, than non-powers of two. > So > in this case you would have to use 8KB as a maximum. > Well, I'm no architecture expert, but I really doubt the CPU delay of a non-power of 2 multiply/divide is significant related to doing smaller TSO segments. Long ago (as in 1970s) I did work on machines where shifts for power of 2 multiply/divide was preferable, but these days I doubt it is going to matter?? > > - You can't get the maximum TSO size for ixl devices by multiplying > > the > > maximum number of fragments by the maximum size. > > Instead the number of fragments is AFAIK unlimited, but a segment > > can only > > span 8 mbufs (including the [up to 3] mbufs containing the header), > > and the > > maximum TSO size is 256KB. > > > > And one question: > > > > - Is hdr_size_log2 supposed to be the length of the L2 header? We > > can fit > > 254 L2 bytes in our hardware during a TSO, so if that's the value, > > I guess > > that's fine, barring the it-not-being-a-power-of-2 issue. > > This is the ethernet / vlan headers. It is added with the > TCP/IP-header > in the end. > > > > > With all that said, the 8 mbuf limit per segment issue is a TSO > > limitation > > that we'd like to notify the stack about, so I wonder if that could > > be > > incorporated along with this. Right now, our driver checks to see > > if a > > segment in a TSO spans more than six mbufs and then m_defrag()'s > > the entire > > chain if one exists; it's less than optimal but necessary to > > prevent errors. > At this time, if there is a limit of 8 TSO segments (mbufs) in a transmit list, you will need to set: ifp->if_hw_tsomax = 8 * MCLBYTES - (ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN); - just before the call to ether_ifattach(ifp); I do have an untested patch (attached in case anyone is interested) which adds if_hw_tsomaxseg that drivers can set to their maximum number of transmit segments (mbufs) fot TSO. This value is then used by tcp_output() to generate appropriately sized TSO segments. However, I'm just working on getting a way to test this patch, so I can't say if/when it will be in head. rick > It is not impossible to move from log2 syntax to non-log2 syntax, > hence > the logic will be exactly the same, only that the required division > and > multiplication will have a bit overhead I guess. > > Could you make a patch on top of my patch with the changes you think > are > required to fully support the ixl hardware? Or propose a new patch > which > also serves the MLX needs? > > Thank you! > > --HPS > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > ------=_Part_33012987_2077484506.1409954952678 Content-Type: text/x-patch; name=tsomaxseg.patch Content-Disposition: attachment; filename=tsomaxseg.patch Content-Transfer-Encoding: base64 LS0tIGtlcm4vdWlwY19zb2NrYnVmLmMuc2F2CTIwMTQtMDEtMzAgMjA6Mjc6MTcuMDAwMDAwMDAw IC0wNTAwCisrKyBrZXJuL3VpcGNfc29ja2J1Zi5jCTIwMTQtMDEtMzAgMjI6MTI6MDguMDAwMDAw MDAwIC0wNTAwCkBAIC05NjUsNiArOTY1LDM5IEBAIHNic25kcHRyKHN0cnVjdCBzb2NrYnVmICpz YiwgdV9pbnQgb2ZmLCAKIH0KIAogLyoKKyAqIFJldHVybiB0aGUgZmlyc3QgbWJ1ZiBmb3IgdGhl IHByb3ZpZGVkIG9mZnNldC4KKyAqLworc3RydWN0IG1idWYgKgorc2JzbmRtYnVmKHN0cnVjdCBz b2NrYnVmICpzYiwgdV9pbnQgb2ZmLCBsb25nICpmaXJzdF9sZW4pCit7CisJc3RydWN0IG1idWYg Km07CisKKwlLQVNTRVJUKHNiLT5zYl9tYiAhPSBOVUxMLCAoIiVzOiBzYl9tYiBpcyBOVUxMIiwg X19mdW5jX18pKTsKKworCSpmaXJzdF9sZW4gPSAwOworCS8qCisJICogSXMgb2ZmIGJlbG93IHN0 b3JlZCBvZmZzZXQ/IEhhcHBlbnMgb24gcmV0cmFuc21pdHMuCisJICogSWYgc28sIGp1c3QgdXNl IHNiX21iLgorCSAqLworCWlmIChzYi0+c2Jfc25kcHRyID09IE5VTEwgfHwgc2ItPnNiX3NuZHB0 cm9mZiA+IG9mZikKKwkJbSA9IHNiLT5zYl9tYjsKKwllbHNlIHsKKwkJbSA9IHNiLT5zYl9zbmRw dHI7CisJCW9mZiAtPSBzYi0+c2Jfc25kcHRyb2ZmOworCX0KKwl3aGlsZSAob2ZmID4gMCAmJiBt ICE9IE5VTEwpIHsKKwkJaWYgKG9mZiA8IG0tPm1fbGVuKQorCQkJYnJlYWs7CisJCW9mZiAtPSBt LT5tX2xlbjsKKwkJbSA9IG0tPm1fbmV4dDsKKwl9CisJaWYgKG0gIT0gTlVMTCkKKwkJKmZpcnN0 X2xlbiA9IG0tPm1fbGVuIC0gb2ZmOworCisJcmV0dXJuIChtKTsKK30KKworLyoKICAqIERyb3Ag YSByZWNvcmQgb2ZmIHRoZSBmcm9udCBvZiBhIHNvY2tidWYgYW5kIG1vdmUgdGhlIG5leHQgcmVj b3JkIHRvIHRoZQogICogZnJvbnQuCiAgKi8KLS0tIHN5cy9zb2NrYnVmLmguc2F2CTIwMTQtMDEt MzAgMjA6NDI6MjguMDAwMDAwMDAwIC0wNTAwCisrKyBzeXMvc29ja2J1Zi5oCTIwMTQtMDEtMzAg MjI6MDg6NDMuMDAwMDAwMDAwIC0wNTAwCkBAIC0xNTMsNiArMTUzLDggQEAgaW50CXNicmVzZXJ2 ZV9sb2NrZWQoc3RydWN0IHNvY2tidWYgKnNiLAogCSAgICBzdHJ1Y3QgdGhyZWFkICp0ZCk7CiBz dHJ1Y3QgbWJ1ZiAqCiAJc2JzbmRwdHIoc3RydWN0IHNvY2tidWYgKnNiLCB1X2ludCBvZmYsIHVf aW50IGxlbiwgdV9pbnQgKm1vZmYpOworc3RydWN0IG1idWYgKgorCXNic25kbWJ1ZihzdHJ1Y3Qg c29ja2J1ZiAqc2IsIHVfaW50IG9mZiwgbG9uZyAqZmlyc3RfbGVuKTsKIHZvaWQJc2J0b3hzb2Nr YnVmKHN0cnVjdCBzb2NrYnVmICpzYiwgc3RydWN0IHhzb2NrYnVmICp4c2IpOwogaW50CXNid2Fp dChzdHJ1Y3Qgc29ja2J1ZiAqc2IpOwogaW50CXNibG9jayhzdHJ1Y3Qgc29ja2J1ZiAqc2IsIGlu dCBmbGFncyk7Ci0tLSBuZXRpbmV0L3RjcF9pbnB1dC5jLnNhdgkyMDE0LTAxLTMwIDE5OjM3OjUy LjAwMDAwMDAwMCAtMDUwMAorKysgbmV0aW5ldC90Y3BfaW5wdXQuYwkyMDE0LTAxLTMwIDE5OjM5 OjA3LjAwMDAwMDAwMCAtMDUwMApAQCAtMzYyNyw2ICszNjI3LDcgQEAgdGNwX21zcyhzdHJ1Y3Qg dGNwY2IgKnRwLCBpbnQgb2ZmZXIpCiAJaWYgKGNhcC5pZmNhcCAmIENTVU1fVFNPKSB7CiAJCXRw LT50X2ZsYWdzIHw9IFRGX1RTTzsKIAkJdHAtPnRfdHNvbWF4ID0gY2FwLnRzb21heDsKKwkJdHAt PnRfdHNvbWF4c2VncyA9IGNhcC50c29tYXhzZWdzOwogCX0KIH0KIAotLS0gbmV0aW5ldC90Y3Bf b3V0cHV0LmMuc2F2CTIwMTQtMDEtMzAgMTg6NTU6MTUuMDAwMDAwMDAwIC0wNTAwCisrKyBuZXRp bmV0L3RjcF9vdXRwdXQuYwkyMDE0LTAxLTMwIDIyOjE4OjU2LjAwMDAwMDAwMCAtMDUwMApAQCAt MTY2LDggKzE2Niw4IEBAIGludAogdGNwX291dHB1dChzdHJ1Y3QgdGNwY2IgKnRwKQogewogCXN0 cnVjdCBzb2NrZXQgKnNvID0gdHAtPnRfaW5wY2ItPmlucF9zb2NrZXQ7Ci0JbG9uZyBsZW4sIHJl Y3dpbiwgc2VuZHdpbjsKLQlpbnQgb2ZmLCBmbGFncywgZXJyb3IgPSAwOwkvKiBLZWVwIGNvbXBp bGVyIGhhcHB5ICovCisJbG9uZyBsZW4sIHJlY3dpbiwgc2VuZHdpbiwgdHNvX3RsZW47CisJaW50 IGNudCwgb2ZmLCBmbGFncywgZXJyb3IgPSAwOwkvKiBLZWVwIGNvbXBpbGVyIGhhcHB5ICovCiAJ c3RydWN0IG1idWYgKm07CiAJc3RydWN0IGlwICppcCA9IE5VTEw7CiAJc3RydWN0IGlwb3ZseSAq aXBvdiA9IE5VTEw7CkBAIC03ODAsNiArNzgwLDI0IEBAIHNlbmQ6CiAJCQl9CiAKIAkJCS8qCisJ CQkgKiBMaW1pdCB0aGUgbnVtYmVyIG9mIFRTTyB0cmFuc21pdCBzZWdtZW50cyAobWJ1ZnMKKwkJ CSAqIGluIG1idWYgbGlzdCkgdG8gdHAtPnRfdHNvbWF4c2Vncy4KKwkJCSAqLworCQkJY250ID0g MDsKKwkJCW0gPSBzYnNuZG1idWYoJnNvLT5zb19zbmQsIG9mZiwgJnRzb190bGVuKTsKKwkJCXdo aWxlIChtICE9IE5VTEwgJiYgY250IDwgdHAtPnRfdHNvbWF4c2VncyAmJgorCQkJICAgIHRzb190 bGVuIDwgbGVuKSB7CisJCQkJaWYgKGNudCA+IDApCisJCQkJCXRzb190bGVuICs9IG0tPm1fbGVu OworCQkJCWNudCsrOworCQkJCW0gPSBtLT5tX25leHQ7CisJCQl9CisJCQlpZiAobSAhPSBOVUxM ICYmIHRzb190bGVuIDwgbGVuKSB7CisJCQkJbGVuID0gdHNvX3RsZW47CisJCQkJc2VuZGFsb3Qg PSAxOworCQkJfQorCisJCQkvKgogCQkJICogUHJldmVudCB0aGUgbGFzdCBzZWdtZW50IGZyb20g YmVpbmcKIAkJCSAqIGZyYWN0aW9uYWwgdW5sZXNzIHRoZSBzZW5kIHNvY2tidWYgY2FuCiAJCQkg KiBiZSBlbXB0aWVkLgotLS0gbmV0aW5ldC90Y3Bfc3Vici5jLnNhdgkyMDE0LTAxLTMwIDE5OjQ0 OjM1LjAwMDAwMDAwMCAtMDUwMAorKysgbmV0aW5ldC90Y3Bfc3Vici5jCTIwMTQtMDEtMzAgMjA6 NTY6MTIuMDAwMDAwMDAwIC0wNTAwCkBAIC0xODAwLDYgKzE4MDAsMTIgQEAgdGNwX21heG10dShz dHJ1Y3QgaW5fY29ubmluZm8gKmluYywgc3RydQogCQkJICAgIGlmcC0+aWZfaHdhc3Npc3QgJiBD U1VNX1RTTykKIAkJCQljYXAtPmlmY2FwIHw9IENTVU1fVFNPOwogCQkJCWNhcC0+dHNvbWF4ID0g aWZwLT5pZl9od190c29tYXg7CisjaWZkZWYgbm90eWV0CisJCQkJY2FwLT50c29tYXhzZWdzID0g aWZwLT5pZl9od190c29tYXhzZWdzOworI2VuZGlmCisJCQkJaWYgKGNhcC0+dHNvbWF4c2VncyA9 PSAwKQorCQkJCQljYXAtPnRzb21heHNlZ3MgPQorCQkJCQkgICAgVENQVFNPX01BWF9UWF9TRUdT X0RFRkFVTFQ7CiAJCX0KIAkJUlRGUkVFKHNyby5yb19ydCk7CiAJfQotLS0gbmV0aW5ldC90Y3Bf dmFyLmguc2F2CTIwMTQtMDEtMzAgMTk6Mzk6MjIuMDAwMDAwMDAwIC0wNTAwCisrKyBuZXRpbmV0 L3RjcF92YXIuaAkyMDE0LTAxLTMwIDIwOjUyOjU3LjAwMDAwMDAwMCAtMDUwMApAQCAtMjA5LDYg KzIwOSw3IEBAIHN0cnVjdCB0Y3BjYiB7CiAJdV9pbnQJdF9rZWVwY250OwkJLyogbnVtYmVyIG9m IGtlZXBhbGl2ZXMgYmVmb3JlIGNsb3NlICovCiAKIAl1X2ludAl0X3Rzb21heDsJCS8qIHRzbyBi dXJzdCBsZW5ndGggbGltaXQgKi8KKwl1X2ludAl0X3Rzb21heHNlZ3M7CQkvKiB0c28gYnVyc3Qg c2VnbWVudCBsaW1pdCAqLwogCiAJdWludDMyX3QgdF9pc3BhcmVbOF07CQkvKiA1IFVUTywgMyBU QkQgKi8KIAl2b2lkCSp0X3BzcGFyZTJbNF07CQkvKiA0IFRCRCAqLwpAQCAtMjY4LDYgKzI2OSwx MSBAQCBzdHJ1Y3QgdGNwY2IgewogI2RlZmluZQlUQ1BPT0JfSEFWRURBVEEJMHgwMQogI2RlZmlu ZQlUQ1BPT0JfSEFEREFUQQkweDAyCiAKKy8qCisgKiBEZWZhdWx0IHZhbHVlIGZvciBUU08gbWF4 aW11bSBudW1iZXIgb2YgdHJhbnNtaXQgc2VnbWVudHMgKGNvdW50IG9mIG1idWZzKS4KKyAqLwor I2RlZmluZQlUQ1BUU09fTUFYX1RYX1NFR1NfREVGQVVMVAkzMAorCiAjaWZkZWYgVENQX1NJR05B VFVSRQogLyoKICAqIERlZmluZXMgd2hpY2ggYXJlIG5lZWRlZCBieSB0aGUgeGZvcm1fdGNwIG1v ZHVsZSBhbmQgdGNwX1tpbnxvdXRdcHV0CkBAIC0zMzMsNiArMzM5LDcgQEAgc3RydWN0IGhjX21l dHJpY3NfbGl0ZSB7CS8qIG11c3Qgc3RheSBpbgogc3RydWN0IHRjcF9pZmNhcCB7CiAJaW50CWlm Y2FwOwogCXVfaW50CXRzb21heDsKKwl1X2ludAl0c29tYXhzZWdzOwogfTsKIAogI2lmbmRlZiBf TkVUSU5FVF9JTl9QQ0JfSF8K ------=_Part_33012987_2077484506.1409954952678-- From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 22:24:58 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F7DCC4; Fri, 5 Sep 2014 22:24:58 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id E6263182C; Fri, 5 Sep 2014 22:24:57 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwEAKg3ClSDaFve/2dsb2JhbABag2BXBIJ4xhAKhnlTAYEbd4QDAQEBAwEBAQEgKyALBRYYAgINGQIpAQkmBggCBQQBGgIEiBkIDalylToBF4EsjUoGAQEbNAeCeYFTBZVug3uEX5NKgWcegXghLweBAAgXIoEHAQEB X-IronPort-AV: E=Sophos;i="5.04,476,1406606400"; d="scan'208";a="151957905" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 05 Sep 2014 18:24:56 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id D6526B4061; Fri, 5 Sep 2014 18:24:56 -0400 (EDT) Date: Fri, 5 Sep 2014 18:24:56 -0400 (EDT) From: Rick Macklem To: Hans Petter Selasky Message-ID: <575724560.33015896.1409955896874.JavaMail.root@uoguelph.ca> In-Reply-To: <540A0301.9040701@selasky.org> Subject: Re: [RFC] Patch to improve TSO limitation formula in general MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-net@freebsd.org, FreeBSD Current , Scott Long X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 22:24:58 -0000 Hans Petter Selasky wrote: > Hi, > > I've tested the attached patch with success and would like to have > some > feedback from other FreeBSD network developers. The problem is that > the > current TSO limitation only limits the number of bytes that can be > transferred in a TSO packet and not the number of mbuf's. > > The current solution is to have a quick and dirty custom m_dup() in > the > TX path to re-allocate the mbuf chains into 4K ones to make it > simple. > All of this hack can be avoided if the definition of the TSO limit > can > be changed a bit, like shown here: > > > /* > + * Structure defining hardware TSO limits. > + */ > +struct if_tso_limit { > + u_int raw_value[0]; /* access all fields as one */ > + u_char frag_count; /* maximum number of fragments: > 1..255 */ > + u_char frag_size_log2; /* maximum fragment size: 2 ** > (12..16) */ > + u_char hdr_size_log2; /* maximum header size: 2 ** (2..8) > */ > + u_char reserved; /* zero */ > +}; > > > First we need to know the maximum fragment count. Typical value is > 32. > Second we need to know the maximum fragment size. Typical value is > 4K. > Last we need to know of any headers that should be subtracted from > the > maximum. Hence this code is running in the fast path, I would like to > use "u_char" for all fields and allow copy-only access as a "u_int" > as > an optimization. This avoids cludges and messing with additional > header > files. > > I would like to push this patch after some more testing to -current > and > then to 10-stable hopefully before the coming 10-release, because the > current solution is affecting performance of the Mellanox based > network > adapters in an unfair way. For example by setting the current TSO > limit > to 32KBytes which will be OK for all-2K fragments, we see a severe > degradation in performance. Even though the hardware is fully capable > of > transmitting 16 4K mbufs. > Ok, I didn't see this until now, but I will take a look at the patch. My main comment is that I tried using a mix of 2K and 4K mbuf clusters in NFS and was able (with some effort) get the UMA allocator all messed up, where it would basically be stuck because it couldn't allocate boundary tags. As such, until this issue w.r.t. UMA is rssolved, mixing MCLBYTES and MPAGESIZE clusters is very dangerous imho. (alc@ did send me a simple patch related to this UMA problem, but I haven't been able to test it yet.) rick ps: For the M_WAITOK case, the allocator problem shows up as threads sleeping on "btallo" which happens in vmem_bt_alloc() in kern/subr_vmem.c. It may never happen on 64bit arches, but it can definitely happen on i386. > Comments and reviews are welcome! > > --HPS > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 22:43:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C13EF5AF; Fri, 5 Sep 2014 22:43:34 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 81EFC1A01; Fri, 5 Sep 2014 22:43:34 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 8E0FC1FE027; Sat, 6 Sep 2014 00:43:32 +0200 (CEST) Message-ID: <540A3C91.406@selasky.org> Date: Sat, 06 Sep 2014 00:43:29 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Rick Macklem Subject: Re: [RFC] Patch to improve TSO limitation formula in general References: <1762951742.33012989.1409954952800.JavaMail.root@uoguelph.ca> In-Reply-To: <1762951742.33012989.1409954952800.JavaMail.root@uoguelph.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Eric Joyner , FreeBSD Current , Scott Long , Jack F Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 22:43:34 -0000 On 09/06/14 00:09, Rick Macklem wrote: > Hans Petter Selesky wrote: >> On 09/05/14 23:19, Eric Joyner wrote: >>> There are some concerns if we use this with devices that ixl >>> supports: >>> >>> - The maximum fragment size is 16KB-1, which isn't a power of 2. >>> >> >> Hi Eric, >> >> Multiplying by powers of two are more fast, than non-powers of two. >> So >> in this case you would have to use 8KB as a maximum. >> > Well, I'm no architecture expert, but I really doubt the CPU delay of a > non-power of 2 multiply/divide is significant related to doing smaller > TSO segments. Long ago (as in 1970s) I did work on machines where shifts > for power of 2 multiply/divide was preferable, but these days I doubt it > is going to matter?? > Hi, You also need to patch LAGG and VLAN drivers? --HPS From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 23:21:18 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57425E5; Fri, 5 Sep 2014 23:21:18 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id A93281DD9; Fri, 5 Sep 2014 23:21:16 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwEALJEClSDaFve/2dsb2JhbABag2BXBIJ4xhsKhnlTAYEad4QEAQEEAQEBICsdAwsbEgYCAg0ZAikBCRgOBggHBAEcBIghDal3lTkBF4EsjVABAQEaNAeCeYFTBZVug3uEX5NKg30hLweBCDmBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,476,1406606400"; d="scan'208";a="153076390" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 05 Sep 2014 19:21:15 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 8C263B404B; Fri, 5 Sep 2014 19:21:15 -0400 (EDT) Date: Fri, 5 Sep 2014 19:21:15 -0400 (EDT) From: Rick Macklem To: Hans Petter Selasky Message-ID: <1527367342.33029385.1409959275542.JavaMail.root@uoguelph.ca> In-Reply-To: <540A3C91.406@selasky.org> Subject: Re: [RFC] Patch to improve TSO limitation formula in general MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-net@freebsd.org, Eric Joyner , FreeBSD Current , Scott Long , Jack F Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 23:21:18 -0000 Hans Petter Selasky wrote: > On 09/06/14 00:09, Rick Macklem wrote: > > Hans Petter Selesky wrote: > >> On 09/05/14 23:19, Eric Joyner wrote: > >>> There are some concerns if we use this with devices that ixl > >>> supports: > >>> > >>> - The maximum fragment size is 16KB-1, which isn't a power of 2. > >>> > >> > >> Hi Eric, > >> > >> Multiplying by powers of two are more fast, than non-powers of > >> two. > >> So > >> in this case you would have to use 8KB as a maximum. > >> > > Well, I'm no architecture expert, but I really doubt the CPU delay > > of a > > non-power of 2 multiply/divide is significant related to doing > > smaller > > TSO segments. Long ago (as in 1970s) I did work on machines where > > shifts > > for power of 2 multiply/divide was preferable, but these days I > > doubt it > > is going to matter?? > > > > Hi, > > You also need to patch LAGG and VLAN drivers? > Yep. I already ran into the fact that these drivers didn't pass if_hw_tsomax up and patched them for that recently. The same will be necessary for if_hw_tsomaxseg if/when it goes into head. As I said, this patch is currently completely untested and, even once I get it tested/working, there will need to be a discussion on freebsd-net@ w.r.t. whether it is appropriate for head. I will take a look at your patch around Monday. Btw, when setting if_hw_tsomax as I suggested in the first post, you will still end up doing a lot of m_defrag() calls for NFS RPC messages, but at least they will get through. rick > --HPS > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sat Sep 6 00:06:25 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64798D99; Sat, 6 Sep 2014 00:06:25 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E75D126A; Sat, 6 Sep 2014 00:06:24 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s8606OhI026138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Sep 2014 17:06:24 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s8606OOY026137; Fri, 5 Sep 2014 17:06:24 -0700 (PDT) (envelope-from jmg) Date: Fri, 5 Sep 2014 17:06:23 -0700 From: John-Mark Gurney To: Hans Petter Selasky Subject: Re: [RFC] Patch to improve TSO limitation formula in general Message-ID: <20140906000623.GQ82175@funkthat.com> Mail-Followup-To: Hans Petter Selasky , FreeBSD Current , "freebsd-net@freebsd.org" , Scott Long References: <540A0301.9040701@selasky.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <540A0301.9040701@selasky.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 05 Sep 2014 17:06:24 -0700 (PDT) Cc: "freebsd-net@freebsd.org" , FreeBSD Current , Scott Long X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 00:06:25 -0000 Hans Petter Selasky wrote this message on Fri, Sep 05, 2014 at 20:37 +0200: > I've tested the attached patch with success and would like to have some > feedback from other FreeBSD network developers. The problem is that the > current TSO limitation only limits the number of bytes that can be > transferred in a TSO packet and not the number of mbuf's. > > The current solution is to have a quick and dirty custom m_dup() in the > TX path to re-allocate the mbuf chains into 4K ones to make it simple. > All of this hack can be avoided if the definition of the TSO limit can > be changed a bit, like shown here: > > > /* > + * Structure defining hardware TSO limits. > + */ > +struct if_tso_limit { > + u_int raw_value[0]; /* access all fields as one */ > + u_char frag_count; /* maximum number of fragments: 1..255 */ > + u_char frag_size_log2; /* maximum fragment size: 2 ** (12..16) */ > + u_char hdr_size_log2; /* maximum header size: 2 ** (2..8) */ > + u_char reserved; /* zero */ > +}; Please make this a union if you really need to access the raw_value, or just drop it... Is this done to fit in the u_int t_tsomax that is in tcpcb? Also, I couldn't find code, but if the tcp connection needs to be sent out a different interface that has more restrictive tso requirements, do we properly handle this case? My quick reading of the code seems to imply that we only get the TSO requirements on connection and never update it... As these are per if, saving memory by packing them isn't really that effective these days... Per the later comments, yes, a shift MAY be faster than a full mul/div by a cycle or two, but this won't make that huge of a difference when dealing with it.. If the programmer has to use crazy macros or do the math EVERY time they use the fields, this will end up w/ less readable/maintainable code at the cost of improving performance by maybe .001%, so my vote is for u_int's instead, and convert to their sizes properly... Comments on the patch: You can drop the .reserve initalization... It is common C knowlege that unassigned members are assigned zero... The IF_TSO_LIMIT_CMP macros seems excesive... Do you ever see a need to use other operators? and if so, would they be useful? I'd just convert it to: #define IF_TSO_LIMIT_EQ(a, b) ((a)->raw_value[0] == (b)->raw_value[0]) I am a bit puzzled by this code: + /* Check if fragment limit will be exceeded */ + if (cur_frags >= rem_frags) { + max_len += min(cur_length, rem_frags << if_hw_tsomax.frag_size_log2); + break; + } specificly the max_len += line... The code seems to say if we would overrun the remaining frags (maybe you want a > instead of >=) we increase max_len... seems like if we include this frag that would put us over the limit that we should just skip it? (break w/o increasing max_len).. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Sat Sep 6 02:53:23 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0EB5F99 for ; Sat, 6 Sep 2014 02:53:23 +0000 (UTC) Received: from sdf.lonestar.org (mx.sdf.org [192.94.73.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.sdf.org", Issuer "SDF.ORG" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A8E501381 for ; Sat, 6 Sep 2014 02:53:23 +0000 (UTC) Received: from otaku.freeshell.org (IDENT:case@otaku.freeshell.org [192.94.73.9]) by sdf.lonestar.org (8.14.8/8.14.5) with ESMTP id s862qMcn010664 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO) for ; Sat, 6 Sep 2014 02:52:58 GMT Date: Sat, 6 Sep 2014 02:52:22 +0000 (UTC) From: John Case X-X-Sender: case@faeroes.freeshell.org To: freebsd-net@freebsd.org Subject: How can sshuttle be used properly with FreeBSD (and with DNS) ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 02:53:24 -0000 I would like to use sshuttle (http://github.com/apenwarr/sshuttle) on FreeBSD. I have it working for TCP connections, but it does not properly tunnel DNS requests. The documentation for sshuttle says that ipfw forward rules will not properly forward UDP packets, and so when it runs on FreeBSD, sshuttle inserts divert rules instead. The project author believes that this will work properly (inserting divert rules to tunnel UDP) but I am not having any success. BUT, I already have a divert rule (and natd running) on this system even before I run sshuttle at all - because the system won't function as a normal gateway unless I use divert/natd. I prefer to run a gateway without divert/natd, but since both sides of this gateway are non-routable IPs, I cannot do that - in order to function as a gateway with 10.x.x.x networks on both sides, I need to run natd/divert. So that means that when sshuttle inserts its own divert rules, they conflict with the existing ones, and I am not running a second natd daemon, so I think it all just falls apart. How can this be fixed ? Is anyone out there using sshuttle on FreeBSD with the --dns switch ? Here is what my ipfw.conf looks like BEFORE I run sshuttle: add 1000 divert natd ip from any to any in via xl0 add 2000 divert natd ip from any to any out via xl0 and in rc.conf: gateway_enable="yes" natd_enable="yes" natd_interface="xl0" Again, this works fine - I have a functioning internet gateway and both of the interfaces on it have non-routable IP address. Then I run sshuttle and it *also* works fine - but only for TCP. It does not tunnel UDP (dns) properly like it is supposed to, and I think the reason is that I already have diverting/natd going on and then I run sshuttle and it inserts another two divert rules into ipfw. But I am not sure wha the fix would be ... Thanks. From owner-freebsd-net@FreeBSD.ORG Sat Sep 6 03:15:47 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2B584D8 for ; Sat, 6 Sep 2014 03:15:47 +0000 (UTC) Received: from sdf.lonestar.org (mx.sdf.org [192.94.73.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.sdf.org", Issuer "SDF.ORG" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D57D71790 for ; Sat, 6 Sep 2014 03:15:47 +0000 (UTC) Received: from otaku.freeshell.org (IDENT:case@otaku.freeshell.org [192.94.73.9]) by sdf.lonestar.org (8.14.8/8.14.5) with ESMTP id s863FVKw020579 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO) for ; Sat, 6 Sep 2014 03:15:31 GMT Date: Sat, 6 Sep 2014 03:15:31 +0000 (UTC) From: John Case X-X-Sender: case@faeroes.freeshell.org To: freebsd-net@freebsd.org Subject: When to use and not use divert/natd ... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 03:15:48 -0000 Hello, For many years I would build FreeBSD firewalls and they would be very, very simple - I just set gateway_enable="yes" in rc.conf and everything just worked. However, these firewalls *always* had real, routable IPs no both sides. Both interfaces had real, routable IPs. Now I have a firewall that has two non-routable IPs for its interfaces, and is connected to a internet router with the real IP. When I try to builda very simple firewall it does not work, and I am forced to use ipdivert and natd. If I use ipdivert and natd, it works just fine. So, am I correct that I can create a simple gateway without natd/divert as long as both interfaces are real IPs, but if both interfaces are non-routable IPs, I am forced to use divert/natd ? Is that correct ? From owner-freebsd-net@FreeBSD.ORG Sat Sep 6 03:40:02 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 523CA7A9 for ; Sat, 6 Sep 2014 03:40:02 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1B95F1954 for ; Sat, 6 Sep 2014 03:40:01 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 4066C139CF for ; Sat, 6 Sep 2014 00:40:32 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:to:mime-version :user-agent:from:from:date:date:message-id; s=dkim; t= 1409974830; x=1410838831; bh=lTCDDPuuUjyxMm82q0SmEix1A+6x7rpuJDE RPqc5PRg=; b=XW9ItecLByrYcalDTCRxPwYwxBVGz1jLo5br+FlDN2GsZh/Sxab gwiwSC2jWdqtmpX3WnoUAX5huvcf8wWntR6gNyABYQutk1NZ0suxFQaS2ZITRZEn Uu3U8c6LrkglBulx6W0hyR9r/Pf0R2uh1o5+/mgiTS7WFvvhuV2vn4Rg= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xb1_iYEVPTZW for ; Sat, 6 Sep 2014 00:40:30 -0300 (BRT) Received: from [192.168.10.208] (unknown [186.193.54.69]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id 78AD7139CA; Sat, 6 Sep 2014 00:40:29 -0300 (BRT) Message-ID: <540A8200.5010404@bsdinfo.com.br> Date: Sat, 06 Sep 2014 00:39:44 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: ixgbe CRITICAL: ECC ERROR!! Please Reboot!! References: <5408F23C.2030309@bsdinfo.com.br> <54091607.9010100@bsdinfo.com.br> <5409CA44.8070203@bsdinfo.com.br> <540A1A3E.2040306@bsdinfo.com.br> In-Reply-To: <540A1A3E.2040306@bsdinfo.com.br> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 03:40:02 -0000 On 05/09/2014 17:17, Marcelo Gondim wrote: > On 05/09/2014 16:49, Adrian Chadd wrote: >> Hi, >> >> But is the airflow in the unit sufficient? >> >> I had this problem at a previous job - the box was running fine, the >> room was very cold, but the internal fans in the server were set to >> "be very quiet". It wasn't enough to keep the ixgbe NICs happy. I had >> to change the fan settings to "just always run full speed". >> >> The fan temperature feedback loop was based on sensors on the CPU, >> _not_ on the peripherals. > Hi Adrian, > > Ummm. I'll check it and improve internal cooling. :) > She is not happy and I'm also not. rsrsrsr > > Cheers, Besides the problem of heating of the network interface, I am putting some information here. Could you tell me if there is something strange or is it normal? dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.5.15 dev.ix.0.%driver: ix dev.ix.0.%location: slot=0 function=0 handle=\_SB_.PCI1.BR48.S3F0 dev.ix.0.%pnpinfo: vendor=0x8086 device=0x154d subvendor=0x8086 subdevice=0x7b11 class=0x020000 dev.ix.0.%parent: pci131 dev.ix.0.fc: 3 dev.ix.0.enable_aim: 1 dev.ix.0.advertise_speed: 0 dev.ix.0.dropped: 0 dev.ix.0.mbuf_defrag_failed: 0 dev.ix.0.watchdog_events: 0 dev.ix.0.link_irq: 121769 dev.ix.0.queue0.interrupt_rate: 5319 dev.ix.0.queue0.irqs: 7900830877 dev.ix.0.queue0.txd_head: 1037 dev.ix.0.queue0.txd_tail: 1037 dev.ix.0.queue0.tso_tx: 142 dev.ix.0.queue0.no_tx_dma_setup: 0 dev.ix.0.queue0.no_desc_avail: 0 dev.ix.0.queue0.tx_packets: 9725701450 dev.ix.0.queue0.rxd_head: 1175 dev.ix.0.queue0.rxd_tail: 1174 dev.ix.0.queue0.rx_packets: 13069276955 dev.ix.0.queue0.rx_bytes: 3391061018 dev.ix.0.queue0.rx_copies: 8574407 dev.ix.0.queue0.lro_queued: 0 dev.ix.0.queue0.lro_flushed: 0 dev.ix.0.queue1.interrupt_rate: 41666 dev.ix.0.queue1.irqs: 7681141208 dev.ix.0.queue1.txd_head: 219 dev.ix.0.queue1.txd_tail: 221 dev.ix.0.queue1.tso_tx: 57 dev.ix.0.queue1.no_tx_dma_setup: 0 dev.ix.0.queue1.no_desc_avail: 44334 dev.ix.0.queue1.tx_packets: 10196891433 dev.ix.0.queue1.rxd_head: 1988 dev.ix.0.queue1.rxd_tail: 1987 dev.ix.0.queue1.rx_packets: 13210132242 dev.ix.0.queue1.rx_bytes: 4317357059 dev.ix.0.queue1.rx_copies: 8131936 dev.ix.0.queue1.lro_queued: 0 dev.ix.0.queue1.lro_flushed: 0 dev.ix.0.queue2.interrupt_rate: 5319 dev.ix.0.queue2.irqs: 7647486080 dev.ix.0.queue2.txd_head: 761 dev.ix.0.queue2.txd_tail: 761 dev.ix.0.queue2.tso_tx: 409 dev.ix.0.queue2.no_tx_dma_setup: 0 dev.ix.0.queue2.no_desc_avail: 54207 dev.ix.0.queue2.tx_packets: 10161246425 dev.ix.0.queue2.rxd_head: 1874 dev.ix.0.queue2.rxd_tail: 1872 dev.ix.0.queue2.rx_packets: 13175551880 dev.ix.0.queue2.rx_bytes: 4472798418 dev.ix.0.queue2.rx_copies: 7488876 dev.ix.0.queue2.lro_queued: 0 dev.ix.0.queue2.lro_flushed: 0 dev.ix.0.queue3.interrupt_rate: 500000 dev.ix.0.queue3.irqs: 7641129521 dev.ix.0.queue3.txd_head: 2039 dev.ix.0.queue3.txd_tail: 2039 dev.ix.0.queue3.tso_tx: 9 dev.ix.0.queue3.no_tx_dma_setup: 0 dev.ix.0.queue3.no_desc_avail: 150346 dev.ix.0.queue3.tx_packets: 10619971896 dev.ix.0.queue3.rxd_head: 1055 dev.ix.0.queue3.rxd_tail: 1054 dev.ix.0.queue3.rx_packets: 13137835529 dev.ix.0.queue3.rx_bytes: 4063197306 dev.ix.0.queue3.rx_copies: 8188713 dev.ix.0.queue3.lro_queued: 0 dev.ix.0.queue3.lro_flushed: 0 dev.ix.0.queue4.interrupt_rate: 5319 dev.ix.0.queue4.irqs: 7439824996 dev.ix.0.queue4.txd_head: 26 dev.ix.0.queue4.txd_tail: 26 dev.ix.0.queue4.tso_tx: 553912 dev.ix.0.queue4.no_tx_dma_setup: 0 dev.ix.0.queue4.no_desc_avail: 0 dev.ix.0.queue4.tx_packets: 10658683718 dev.ix.0.queue4.rxd_head: 684 dev.ix.0.queue4.rxd_tail: 681 dev.ix.0.queue4.rx_packets: 13204786830 dev.ix.0.queue4.rx_bytes: 3700845239 dev.ix.0.queue4.rx_copies: 8193379 dev.ix.0.queue4.lro_queued: 0 dev.ix.0.queue4.lro_flushed: 0 dev.ix.0.queue5.interrupt_rate: 15151 dev.ix.0.queue5.irqs: 7456613396 dev.ix.0.queue5.txd_head: 603 dev.ix.0.queue5.txd_tail: 603 dev.ix.0.queue5.tso_tx: 17 dev.ix.0.queue5.no_tx_dma_setup: 0 dev.ix.0.queue5.no_desc_avail: 0 dev.ix.0.queue5.tx_packets: 10639139790 dev.ix.0.queue5.rxd_head: 404 dev.ix.0.queue5.rxd_tail: 403 dev.ix.0.queue5.rx_packets: 13144301293 dev.ix.0.queue5.rx_bytes: 3986784766 dev.ix.0.queue5.rx_copies: 8256195 dev.ix.0.queue5.lro_queued: 0 dev.ix.0.queue5.lro_flushed: 0 dev.ix.0.queue6.interrupt_rate: 125000 dev.ix.0.queue6.irqs: 7466940576 dev.ix.0.queue6.txd_head: 1784 dev.ix.0.queue6.txd_tail: 1784 dev.ix.0.queue6.tso_tx: 2001 dev.ix.0.queue6.no_tx_dma_setup: 0 dev.ix.0.queue6.no_desc_avail: 0 dev.ix.0.queue6.tx_packets: 9784312967 dev.ix.0.queue6.rxd_head: 395 dev.ix.0.queue6.rxd_tail: 394 dev.ix.0.queue6.rx_packets: 13103079970 dev.ix.0.queue6.rx_bytes: 3581485264 dev.ix.0.queue6.rx_copies: 7336569 dev.ix.0.queue6.lro_queued: 0 dev.ix.0.queue6.lro_flushed: 0 dev.ix.0.queue7.interrupt_rate: 5319 dev.ix.0.queue7.irqs: 7486391989 dev.ix.0.queue7.txd_head: 1549 dev.ix.0.queue7.txd_tail: 1549 dev.ix.0.queue7.tso_tx: 2052 dev.ix.0.queue7.no_tx_dma_setup: 0 dev.ix.0.queue7.no_desc_avail: 0 dev.ix.0.queue7.tx_packets: 9758335509 dev.ix.0.queue7.rxd_head: 1990 dev.ix.0.queue7.rxd_tail: 1986 dev.ix.0.queue7.rx_packets: 13141436559 dev.ix.0.queue7.rx_bytes: 3877881546 dev.ix.0.queue7.rx_copies: 8505244 dev.ix.0.queue7.lro_queued: 0 dev.ix.0.queue7.lro_flushed: 0 dev.ix.0.mac_stats.crc_errs: 159 dev.ix.0.mac_stats.ill_errs: 5 dev.ix.0.mac_stats.byte_errs: 10 dev.ix.0.mac_stats.short_discards: 0 dev.ix.0.mac_stats.local_faults: 213 dev.ix.0.mac_stats.remote_faults: 37 dev.ix.0.mac_stats.rec_len_errs: 0 dev.ix.0.mac_stats.xon_txd: 33623392288 dev.ix.0.mac_stats.xon_recvd: 0 dev.ix.0.mac_stats.xoff_txd: 110161 dev.ix.0.mac_stats.xoff_recvd: 0 dev.ix.0.mac_stats.total_octets_rcvd: 37967032023930 dev.ix.0.mac_stats.good_octets_rcvd: 37965112076546 dev.ix.0.mac_stats.total_pkts_rcvd: 105201314224 dev.ix.0.mac_stats.good_pkts_rcvd: 18446743122750685300 dev.ix.0.mac_stats.mcast_pkts_rcvd: 43835 dev.ix.0.mac_stats.bcast_pkts_rcvd: 960566 dev.ix.0.mac_stats.rx_frames_64: 454067 dev.ix.0.mac_stats.rx_frames_65_127: 75350664570 dev.ix.0.mac_stats.rx_frames_128_255: 4726321485 dev.ix.0.mac_stats.rx_frames_256_511: 2282382994 dev.ix.0.mac_stats.rx_frames_512_1023: 3293330145 dev.ix.0.mac_stats.rx_frames_1024_1522: 19541190234 dev.ix.0.mac_stats.recv_undersized: 0 dev.ix.0.mac_stats.recv_fragmented: 0 dev.ix.0.mac_stats.recv_oversized: 0 dev.ix.0.mac_stats.recv_jabberd: 4 dev.ix.0.mac_stats.management_pkts_rcvd: 0 dev.ix.0.mac_stats.management_pkts_drpd: 0 dev.ix.0.mac_stats.checksum_errs: 527716650 dev.ix.0.mac_stats.good_octets_txd: 81355567084088 dev.ix.0.mac_stats.total_pkts_txd: 81545370171 dev.ix.0.mac_stats.good_pkts_txd: 47921867720 dev.ix.0.mac_stats.bcast_pkts_txd: 298646 dev.ix.0.mac_stats.mcast_pkts_txd: 18446744040086169062 dev.ix.0.mac_stats.management_pkts_txd: 0 dev.ix.0.mac_stats.tx_frames_64: 18446744045326220993 dev.ix.0.mac_stats.tx_frames_65_127: 15629697019 dev.ix.0.mac_stats.tx_frames_128_255: 4141756940 dev.ix.0.mac_stats.tx_frames_256_511: 2195917491 dev.ix.0.mac_stats.tx_frames_512_1023: 2717769904 dev.ix.0.mac_stats.tx_frames_1024_1522: 51620056990 dev.ix.1.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.5.15 dev.ix.1.%driver: ix dev.ix.1.%location: slot=0 function=1 handle=\_SB_.PCI1.BR48.S3F1 dev.ix.1.%pnpinfo: vendor=0x8086 device=0x154d subvendor=0x8086 subdevice=0x7b11 class=0x020000 dev.ix.1.%parent: pci131 dev.ix.1.fc: 3 dev.ix.1.enable_aim: 1 dev.ix.1.advertise_speed: 0 dev.ix.1.dropped: 0 dev.ix.1.mbuf_defrag_failed: 0 dev.ix.1.watchdog_events: 0 dev.ix.1.link_irq: 46692 dev.ix.1.queue0.interrupt_rate: 15151 dev.ix.1.queue0.irqs: 2634341620 dev.ix.1.queue0.txd_head: 1101 dev.ix.1.queue0.txd_tail: 1101 dev.ix.1.queue0.tso_tx: 0 dev.ix.1.queue0.no_tx_dma_setup: 0 dev.ix.1.queue0.no_desc_avail: 4142 dev.ix.1.queue0.tx_packets: 4749431326 dev.ix.1.queue0.rxd_head: 812 dev.ix.1.queue0.rxd_tail: 811 dev.ix.1.queue0.rx_packets: 21135516 dev.ix.1.queue0.rx_bytes: 33229682 dev.ix.1.queue0.rx_copies: 119434 dev.ix.1.queue0.lro_queued: 0 dev.ix.1.queue0.lro_flushed: 0 dev.ix.1.queue1.interrupt_rate: 15151 dev.ix.1.queue1.irqs: 2616347302 dev.ix.1.queue1.txd_head: 797 dev.ix.1.queue1.txd_tail: 797 dev.ix.1.queue1.tso_tx: 0 dev.ix.1.queue1.no_tx_dma_setup: 0 dev.ix.1.queue1.no_desc_avail: 4129 dev.ix.1.queue1.tx_packets: 4730356550 dev.ix.1.queue1.rxd_head: 1345 dev.ix.1.queue1.rxd_tail: 1344 dev.ix.1.queue1.rx_packets: 20844457 dev.ix.1.queue1.rx_bytes: 35014827 dev.ix.1.queue1.rx_copies: 125167 dev.ix.1.queue1.lro_queued: 0 dev.ix.1.queue1.lro_flushed: 0 dev.ix.1.queue2.interrupt_rate: 5555 dev.ix.1.queue2.irqs: 2603166062 dev.ix.1.queue2.txd_head: 1428 dev.ix.1.queue2.txd_tail: 1432 dev.ix.1.queue2.tso_tx: 0 dev.ix.1.queue2.no_tx_dma_setup: 0 dev.ix.1.queue2.no_desc_avail: 34368 dev.ix.1.queue2.tx_packets: 4681339909 dev.ix.1.queue2.rxd_head: 1153 dev.ix.1.queue2.rxd_tail: 1152 dev.ix.1.queue2.rx_packets: 21263862 dev.ix.1.queue2.rx_bytes: 46251419 dev.ix.1.queue2.rx_copies: 125156 dev.ix.1.queue2.lro_queued: 0 dev.ix.1.queue2.lro_flushed: 0 dev.ix.1.queue3.interrupt_rate: 5319 dev.ix.1.queue3.irqs: 2658483423 dev.ix.1.queue3.txd_head: 179 dev.ix.1.queue3.txd_tail: 179 dev.ix.1.queue3.tso_tx: 0 dev.ix.1.queue3.no_tx_dma_setup: 0 dev.ix.1.queue3.no_desc_avail: 4189 dev.ix.1.queue3.tx_packets: 4811705668 dev.ix.1.queue3.rxd_head: 583 dev.ix.1.queue3.rxd_tail: 582 dev.ix.1.queue3.rx_packets: 20472051 dev.ix.1.queue3.rx_bytes: 29823943 dev.ix.1.queue3.rx_copies: 129450 dev.ix.1.queue3.lro_queued: 0 dev.ix.1.queue3.lro_flushed: 0 dev.ix.1.queue4.interrupt_rate: 5319 dev.ix.1.queue4.irqs: 2629295642 dev.ix.1.queue4.txd_head: 592 dev.ix.1.queue4.txd_tail: 594 dev.ix.1.queue4.tso_tx: 0 dev.ix.1.queue4.no_tx_dma_setup: 0 dev.ix.1.queue4.no_desc_avail: 4106 dev.ix.1.queue4.tx_packets: 4774679355 dev.ix.1.queue4.rxd_head: 259 dev.ix.1.queue4.rxd_tail: 258 dev.ix.1.queue4.rx_packets: 22561633 dev.ix.1.queue4.rx_bytes: 40196457 dev.ix.1.queue4.rx_copies: 135966 dev.ix.1.queue4.lro_queued: 0 dev.ix.1.queue4.lro_flushed: 0 dev.ix.1.queue5.interrupt_rate: 18518 dev.ix.1.queue5.irqs: 2628129098 dev.ix.1.queue5.txd_head: 1070 dev.ix.1.queue5.txd_tail: 1072 dev.ix.1.queue5.tso_tx: 0 dev.ix.1.queue5.no_tx_dma_setup: 0 dev.ix.1.queue5.no_desc_avail: 4127 dev.ix.1.queue5.tx_packets: 4750613588 dev.ix.1.queue5.rxd_head: 595 dev.ix.1.queue5.rxd_tail: 594 dev.ix.1.queue5.rx_packets: 21309940 dev.ix.1.queue5.rx_bytes: 29264004 dev.ix.1.queue5.rx_copies: 134128 dev.ix.1.queue5.lro_queued: 0 dev.ix.1.queue5.lro_flushed: 0 dev.ix.1.queue6.interrupt_rate: 125000 dev.ix.1.queue6.irqs: 2615444123 dev.ix.1.queue6.txd_head: 1008 dev.ix.1.queue6.txd_tail: 1008 dev.ix.1.queue6.tso_tx: 0 dev.ix.1.queue6.no_tx_dma_setup: 0 dev.ix.1.queue6.no_desc_avail: 4106 dev.ix.1.queue6.tx_packets: 4703519800 dev.ix.1.queue6.rxd_head: 1209 dev.ix.1.queue6.rxd_tail: 1208 dev.ix.1.queue6.rx_packets: 22783319 dev.ix.1.queue6.rx_bytes: 28091721 dev.ix.1.queue6.rx_copies: 131653 dev.ix.1.queue6.lro_queued: 0 dev.ix.1.queue6.lro_flushed: 0 dev.ix.1.queue7.interrupt_rate: 6024 dev.ix.1.queue7.irqs: 2644640254 dev.ix.1.queue7.txd_head: 1313 dev.ix.1.queue7.txd_tail: 1313 dev.ix.1.queue7.tso_tx: 0 dev.ix.1.queue7.no_tx_dma_setup: 0 dev.ix.1.queue7.no_desc_avail: 4106 dev.ix.1.queue7.tx_packets: 4824584039 dev.ix.1.queue7.rxd_head: 1463 dev.ix.1.queue7.rxd_tail: 1462 dev.ix.1.queue7.rx_packets: 21464418 dev.ix.1.queue7.rx_bytes: 38133966 dev.ix.1.queue7.rx_copies: 163180 dev.ix.1.queue7.lro_queued: 0 dev.ix.1.queue7.lro_flushed: 0 dev.ix.1.mac_stats.crc_errs: 0 dev.ix.1.mac_stats.ill_errs: 0 dev.ix.1.mac_stats.byte_errs: 0 dev.ix.1.mac_stats.short_discards: 0 dev.ix.1.mac_stats.local_faults: 0 dev.ix.1.mac_stats.remote_faults: 2 dev.ix.1.mac_stats.rec_len_errs: 0 dev.ix.1.mac_stats.xon_txd: 11207820571 dev.ix.1.mac_stats.xon_recvd: 0 dev.ix.1.mac_stats.xoff_txd: 3735958948 dev.ix.1.mac_stats.xoff_recvd: 0 dev.ix.1.mac_stats.total_octets_rcvd: 47828274751 dev.ix.1.mac_stats.good_octets_rcvd: 47225376551 dev.ix.1.mac_stats.total_pkts_rcvd: 177931572 dev.ix.1.mac_stats.good_pkts_rcvd: 18446743954331576567 dev.ix.1.mac_stats.mcast_pkts_rcvd: 7410 dev.ix.1.mac_stats.bcast_pkts_rcvd: 8907 dev.ix.1.mac_stats.rx_frames_64: 0 dev.ix.1.mac_stats.rx_frames_65_127: 134619798 dev.ix.1.mac_stats.rx_frames_128_255: 7996096 dev.ix.1.mac_stats.rx_frames_256_511: 3996945 dev.ix.1.mac_stats.rx_frames_512_1023: 5145938 dev.ix.1.mac_stats.rx_frames_1024_1522: 21331154 dev.ix.1.mac_stats.recv_undersized: 0 dev.ix.1.mac_stats.recv_fragmented: 0 dev.ix.1.mac_stats.recv_oversized: 0 dev.ix.1.mac_stats.recv_jabberd: 0 dev.ix.1.mac_stats.management_pkts_rcvd: 0 dev.ix.1.mac_stats.management_pkts_drpd: 0 dev.ix.1.mac_stats.checksum_errs: 219681 dev.ix.1.mac_stats.good_octets_txd: 38874487735713 dev.ix.1.mac_stats.total_pkts_txd: 38026147390 dev.ix.1.mac_stats.good_pkts_txd: 27377335167 dev.ix.1.mac_stats.bcast_pkts_txd: 67411 dev.ix.1.mac_stats.mcast_pkts_txd: 18446744063060778699 dev.ix.1.mac_stats.management_pkts_txd: 0 dev.ix.1.mac_stats.tx_frames_64: 18446744065500352065 dev.ix.1.mac_stats.tx_frames_65_127: 6755049420 dev.ix.1.mac_stats.tx_frames_128_255: 1914523761 dev.ix.1.mac_stats.tx_frames_256_511: 1038553757 dev.ix.1.mac_stats.tx_frames_512_1023: 1240890942 dev.ix.1.mac_stats.tx_frames_1024_1522: 24637516838 Cheers, > >> >> >> -a >> >> >> On 5 September 2014 07:35, Marcelo Gondim wrote: >>> Hi Adrian, >>> >>> I confirmed with the support staff of the room where the server is, >>> that the >>> ambient temperature was normal. >>> >>> >>> On 04/09/2014 22:46, Marcelo Gondim wrote: >>>> On 04/09/2014 20:48, Adrian Chadd wrote: >>>>> Hi, >>>>> >>>>> The only time this has happened to me is because the card overheated. >>>>> Can you check that? >>>> Hi Adrian, >>>> >>>> The room where the equipment is located is very cold but I'll check it >>>> out. >>>> Also seen at the time of the problem, a lot of dropped packets. >>>> >>>> # netstat -idn >>>> ... >>>> ix0 1500 a0:36:9f:2a:6d:ac 18446743423829095869 159 >>>> 750924631703 53285910688 0 0 0 >>>> ix0 - fe80::a236:9f fe80::a236:9fff:f 0 - - 2 >>>> - - - >>>> ix1 1500 a0:36:9f:2a:6d:ae 18446743954328745465 0 >>>> 119550050209 20178077451 0 0 0 >>>> ix1 - fe80::a236:9f fe80::a236:9fff:f 0 - - 1 >>>> - - - >>>> ... >>>> >>>> 119550050209 droped packets on ix1 and 750924631703 droped on ix0 >>>> >>>> Could be interesting I upgrade to10.1-PRERELEASE? >>>> Could there be a problem with the driver? >>>> >>>> Traffic on ix0: 1.4Gbps output / 600Mbps input >>>> Traffic on ix1: 1.2Gbps output >>>> >>>> PPS on ix0: 163Kpps output / 215Kpps input >>>> PPS on ix1: 131Kpps output >>>> >>>> Thanks for your help. >>>>> >>>>> >>>>> -a >>>>> >>>>> >>>>> On 4 September 2014 16:14, Marcelo Gondim >>>>> wrote: >>>>>> Hi All, >>>>>> >>>>>> I have an Intel X520-SR2and today was working when all traffic >>>>>> stopped. >>>>>> I looked in the logs and found this message: >>>>>> >>>>>> Sep 4 18:29:53 rt01 kernel: ix1: >>>>>> Sep 4 18:29:53 rt01 kernel: CRITICAL: ECC ERROR!! Please Reboot!! >>>>>> >>>>>> # uname -a >>>>>> FreeBSD rt01.xxxxx.com.br 10.0-STABLE FreeBSD 10.0-STABLE #10 >>>>>> r267839: >>>>>> Thu >>>>>> Jul 10 15:35:04 BRT 2014 >>>>>> root@rt01.xxxxx.com.br:/usr/obj/usr/src/sys/GONDIM10 amd64 >>>>>> >>>>>> # netstat -m >>>>>> 98324/53476/151800 mbufs in use (current/cache/total) >>>>>> 98301/44951/143252/1014370 mbuf clusters in use >>>>>> (current/cache/total/max) >>>>>> 98301/44897 mbuf+clusters out of packet secondary zone in use >>>>>> (current/cache) >>>>>> 0/421/421/507184 4k (page size) jumbo clusters in use >>>>>> (current/cache/total/max) >>>>>> 0/0/0/150276 9k jumbo clusters in use (current/cache/total/max) >>>>>> 0/0/0/84530 16k jumbo clusters in use (current/cache/total/max) >>>>>> 221183K/104955K/326138K bytes allocated to network >>>>>> (current/cache/total) >>>>>> 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) >>>>>> 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) >>>>>> 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) >>>>>> 0/0/0 requests for jumbo clusters denied (4k/9k/16k) >>>>>> 0 requests for sfbufs denied >>>>>> 0 requests for sfbufs delayed >>>>>> 0 requests for I/O initiated by sendfile >>>>>> >>>>>> Best regards, From owner-freebsd-net@FreeBSD.ORG Sat Sep 6 15:52:07 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC7CA25B for ; Sat, 6 Sep 2014 15:52:07 +0000 (UTC) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 37FD615B4 for ; Sat, 6 Sep 2014 15:52:07 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id n15so5259985lbi.19 for ; Sat, 06 Sep 2014 08:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QZ71zr8JYUSlTnT04zhKP1w66c6QLk9Tc2TGtP3RFyA=; b=OBykHmqBMhunmed88vDVc9LYStM40joqb+YLob+LydGAXXIDyeS8B5lVD7impfWSkB Uh7mDyeHJ/4xm9JwDuG7zZ5tRNJM77aH7Lt7tGE66LXB5u+iWaYDIh7ziOn6PLcu2gso bL96VltoSM47tuF+TG+uRmw/1f9+8NyzdL8ieH/Ze9dM9OzVLmz7OcoO1wpmA4ei6AeB ht4dQ6C4TKwP3uxdk5cySZGG1iBaG54H/MyKA+e1ao/u0GfvuNVhr2DJlUXNQKfolL8W mlXdXSIvjgEuSvUp5G4gsBvYwn2W1QDlHUCDIBgtR7gKf0YSvyifJK/PVyfn61G8BX5a dtqA== MIME-Version: 1.0 X-Received: by 10.112.33.74 with SMTP id p10mr17379294lbi.0.1410018724577; Sat, 06 Sep 2014 08:52:04 -0700 (PDT) Received: by 10.25.20.165 with HTTP; Sat, 6 Sep 2014 08:52:04 -0700 (PDT) In-Reply-To: References: Date: Sat, 6 Sep 2014 11:52:04 -0400 Message-ID: Subject: Re: How can sshuttle be used properly with FreeBSD (and with DNS) ? From: Ryan Stone To: John Case Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 15:52:07 -0000 I'm unable to get sshuttle to redirect DNS traffic even on a machine that doesn't have any other ipfw rules running, so I don't think that it's a conflict with your divert rules causing the problem. Unfortunately I don't have a solution to your problem. When I need to use sshuttle I run it from a Linux machine instead. From owner-freebsd-net@FreeBSD.ORG Sat Sep 6 22:46:31 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D8EBA17 for ; Sat, 6 Sep 2014 22:46:31 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 483C81EFF for ; Sat, 6 Sep 2014 22:46:31 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s86MkSUV092212 for ; Sat, 6 Sep 2014 18:46:28 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s86MkSv1092209; Sat, 6 Sep 2014 18:46:28 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21515.36548.561554.872920@hergotha.csail.mit.edu> Date: Sat, 6 Sep 2014 18:46:28 -0400 From: Garrett Wollman To: freebsd-net@freebsd.org Subject: RFC 7217 X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Sat, 06 Sep 2014 18:46:28 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, HEADER_FROM_DIFFERENT_DOMAINS autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on hergotha.csail.mit.edu X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 22:46:31 -0000 So is anyone working on an RFC 7217 ("Stable and Opaque IIDs with SLAAC") implementation for FreeBSD yet? -GAWollman