From owner-freebsd-net@FreeBSD.ORG Sun Jan 11 13:31:36 2015 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 794F5A0C for ; Sun, 11 Jan 2015 13:31:36 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 46B3C23E for ; Sun, 11 Jan 2015 13:31:33 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id 4DF1E46B58 for ; Sun, 11 Jan 2015 08:31:32 -0500 (EST) Date: Sun, 11 Jan 2015 13:31:32 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: net@FreeBSD.org Subject: Inlining struct m_hdr with struct mbuf; assertion changes Message-ID: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII 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, 11 Jan 2015 13:31:36 -0000 Dear all: As you may have spotted from recent commits to 11-CURRENT, I've been working through the mbuf allocator and mbuf consumers (protocols, device drivers) trying to reduce consumer dependence on the specifics of the mbuf layout -- i.e., using M_SIZE() instead of caller assumptions about MLEN, MHLEN, and MCLBYTES, etc. This is part of a larger project to allow more flexibility in how we implement the mbuf allocator, with a particular interest in supporting 'variable-size mbufs' -- i.e., mbufs with sizes other than MSIZE. I've been running these patches past #network on reviews.FreeBSD.org, but wanted to post this one to the mailing list explicitly due to the change affecting the layout of struct mbuf itself. You can find the review instance here to see current reviews/discussion: https://reviews.freebsd.org/D1483 The attached patch implements the following change: In order to reduce namespace collisions and make it easier to reason about and extend mbuf data-structure layout: - Change the definitions of byte arrays embedded in mbufs to be of size [0] rather than [MLEN] or [MHLEN], as we anticipate embedding mbuf headers within variable-size regions of memory in the future. In fact, we already do so within the cxgbe driver, but would now like the global mbuf allocator to support this as well. Update calculation of these constants to no longer depend on 'struct mbuf' being of size MSIZE. - Fold 'struct m_hdr' into 'struct mbuf' itself, eliminating a set of macros that aliased mh_foo field names to m_foo names such as 'm_next'. These present a particular problem as we would like to add new mbuf-header fields -- e.g., m_size -- that, if similarly named via macros, would introduce collisions with many other variable names in the kernel. - Rename 'struct m_ext' to 'struct struct_m_ext' so that we can introduce compile-time assertions without bumping into the still-extant 'm_ext' macro. - Remove the MSIZE compile-time assertion for 'struct mbuf', but add new assertions for alignment of embedded data arrays (64-bit alignment even on 32-bit platforms), and for the sizes the mbuf header, packet header, and m_ext structure.Document that these assertions exist in comments in mbuf.h. This change should not cause actual behavioural differences, but is a precursour to other mbuf-allocator work such as the introduction of variable-size mbufs. Robert Index: sys/kern/uipc_mbuf.c =================================================================== --- sys/kern/uipc_mbuf.c (revision 276911) +++ sys/kern/uipc_mbuf.c (working copy) @@ -88,11 +88,38 @@ * Ensure the correct size of various mbuf parameters. It could be off due * to compiler-induced padding and alignment artifacts. */ -CTASSERT(sizeof(struct mbuf) == MSIZE); CTASSERT(MSIZE - offsetof(struct mbuf, m_dat) == MLEN); CTASSERT(MSIZE - offsetof(struct mbuf, m_pktdat) == MHLEN); /* + * mbuf data storage should be 64-bit aligned regardless of architectural + * pointer size; check this is the case with and without a packet header. + */ +CTASSERT(offsetof(struct mbuf, m_dat) % 8 == 0); +CTASSERT(offsetof(struct mbuf, m_pktdat) % 8 == 0); + +/* + * While the specific values here don't matter too much (i.e., +/- a few + * words), we do want to ensure that changes to these values are carefully + * reasoned about and properly documented. This is especially the case as + * network-protocol and device-driver modules encode these layouts, and must + * be recompiled if the structures change. Check these values at compile time + * against the ones documented in comments in mbuf.h. + * + * NB: Possibly they should be documented there via #define's and not just + * comments. + */ +#if defined(__LP64__) +CTASSERT(offsetof(struct mbuf, m_dat) == 32); +CTASSERT(sizeof(struct pkthdr) == 56); +CTASSERT(sizeof(struct struct_m_ext) == 48); +#else +CTASSERT(offsetof(struct mbuf, m_dat) == 24); +CTASSERT(sizeof(struct pkthdr) == 48); +CTASSERT(sizeof(struct struct_m_ext) == 28); +#endif + +/* * m_get2() allocates minimum mbuf that would fit "size" argument. */ struct mbuf * Index: sys/sys/mbuf.h =================================================================== --- sys/sys/mbuf.h (revision 276911) +++ sys/sys/mbuf.h (working copy) @@ -60,9 +60,15 @@ * MLEN is data length in a normal mbuf. * MHLEN is data length in an mbuf with pktheader. * MINCLSIZE is a smallest amount of data that should be put into cluster. + * + * Compile-time assertions in uipc_mbuf.c test these values to ensure that + * they are sensible. */ -#define MLEN ((int)(MSIZE - sizeof(struct m_hdr))) -#define MHLEN ((int)(MLEN - sizeof(struct pkthdr))) +struct mbuf; +#define MHSIZE offsetof(struct mbuf, M_dat.M_databuf) +#define MPKTHSIZE offsetof(struct mbuf, M_dat.MH.MH_dat.MH_databuf) +#define MLEN ((int)(MSIZE - MHSIZE)) /* normal data len */ +#define MHLEN ((int)(MSIZE - MPKTHSIZE)) /* data len w/pkthdr */ #define MINCLSIZE (MHLEN + 1) #ifdef _KERNEL @@ -87,23 +93,6 @@ #endif /* _KERNEL */ /* - * Header present at the beginning of every mbuf. - * Size ILP32: 24 - * LP64: 32 - */ -struct m_hdr { - struct mbuf *mh_next; /* next buffer in chain */ - struct mbuf *mh_nextpkt; /* next chain in queue/record */ - caddr_t mh_data; /* location of data */ - int32_t mh_len; /* amount of data in this mbuf */ - uint32_t mh_type:8, /* type of data in this mbuf */ - mh_flags:24; /* flags; see below */ -#if !defined(__LP64__) - uint32_t mh_pad; /* pad for 64bit alignment */ -#endif -}; - -/* * Packet tag structure (see below for details). */ struct m_tag { @@ -118,6 +107,9 @@ * Record/packet header in first mbuf of chain; valid only if M_PKTHDR is set. * Size ILP32: 48 * LP64: 56 + * + * Compile-time assertions in uipc_mbuf.c test these values to ensure that + * they are correct. */ struct pkthdr { struct ifnet *rcvif; /* rcv interface */ @@ -166,8 +158,11 @@ * set. * Size ILP32: 28 * LP64: 48 + * + * Compile-time assertions in uipc_mbuf.c test these values to ensure that + * they are correct. */ -struct m_ext { +struct struct_m_ext { volatile u_int *ext_cnt; /* pointer to ref count info */ caddr_t ext_buf; /* start of buffer */ uint32_t ext_size; /* size of buffer, for ext_free */ @@ -184,24 +179,43 @@ * purposes. */ struct mbuf { - struct m_hdr m_hdr; + /* + * Header present at the beginning of every mbuf. + * + * Size ILP32: 24 + * LP64: 32 + * + * Compile-time assertions in uipc_mbuf.c test these values to ensure + * that they are correct. + */ + struct mbuf *m_next; /* next buffer in chain */ + struct mbuf *m_nextpkt; /* next chain in queue/record */ + caddr_t m_data; /* location of data */ + int32_t m_len; /* amount of data in this mbuf */ + uint32_t m_type:8, /* type of data in this mbuf */ + m_flags:24; /* flags; see below */ +#if !defined(__LP64__) + uint32_t m_pad; /* pad for 64bit alignment */ +#endif + + /* + * A set of optional headers (packet header, external storage header) + * and internal data storage. Historically, these arrays were sized + * to MHLEN (space left after a packet header) and MLEN (space left + * after only a regular mbuf header); they are now variable size in + * order to support future work on variable-size mbufs. + */ union { struct { struct pkthdr MH_pkthdr; /* M_PKTHDR set */ union { - struct m_ext MH_ext; /* M_EXT set */ - char MH_databuf[MHLEN]; + struct struct_m_ext MH_ext; /* M_EXT set */ + char MH_databuf[0]; } MH_dat; } MH; - char M_databuf[MLEN]; /* !M_PKTHDR, !M_EXT */ + char M_databuf[0]; /* !M_PKTHDR, !M_EXT */ } M_dat; }; -#define m_next m_hdr.mh_next -#define m_len m_hdr.mh_len -#define m_data m_hdr.mh_data -#define m_type m_hdr.mh_type -#define m_flags m_hdr.mh_flags -#define m_nextpkt m_hdr.mh_nextpkt #define m_pkthdr M_dat.MH.MH_pkthdr #define m_ext M_dat.MH.MH_dat.MH_ext #define m_pktdat M_dat.MH.MH_dat.MH_databuf From owner-freebsd-net@FreeBSD.ORG Sun Jan 11 22:11:09 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D55D30C for ; Sun, 11 Jan 2015 22:11:09 +0000 (UTC) Received: from smtp3.hushmail.com (smtp3a.hushmail.com [65.39.178.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.hushmail.com", Issuer "Self-signed" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4391D8B4 for ; Sun, 11 Jan 2015 22:11:08 +0000 (UTC) Received: from smtp3.hushmail.com (smtp3a.hushmail.com [65.39.178.201]) by smtp3.hushmail.com (Postfix) with SMTP id 9820CE00D5 for ; Sun, 11 Jan 2015 21:32:03 +0000 (UTC) Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32]) by smtp3.hushmail.com (Postfix) with ESMTP; Sun, 11 Jan 2015 21:32:03 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 60018E00B1; Sun, 11 Jan 2015 21:32:03 +0000 (UTC) MIME-Version: 1.0 Date: Sun, 11 Jan 2015 21:32:03 +0000 To: freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org Subject: ipv4 routing from bhyve From: williamecowell@hush.ai Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20150111213203.60018E00B1@smtp.hushmail.com> 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, 11 Jan 2015 22:11:09 -0000 Hello, I hope I can have some assistance. I am trying to get networking via wlan0 but without NAT or bridging (doesn't work on wifi unless WDS). say my my main network is 10.10.2.0/24, gateway/internet is 10.10.2.1, my ip is 10.10.2.252. I started to config my bhyve network on 172.16.32.0/24 I added a bridge interface with an ip of 172.16.32.1 enable forwarding and fastforwarding. from my understanding of the handbook chapter things should work when I type: # route add -net 172.16.32.0/24 10.10.2.252 route: writing to routing socket: File exists add net 172.16.32.0: gateway 10.10.2.252 fib 0: route already in table # # netstat -4nr Routing tables Internet: Destination Gateway Flags Netif Expire default 10.10.2.1 UGS lagg0 127.0.0.1 link#3 UH lo0 10.10.2.0/24 link#5 U lagg0 10.10.2.252 link#5 UHS lo0 172.16.32.0/24 link#4 U bridge0 172.16.32.1 link#4 UHS lo0 # bridge0: flags=8843 metric 0 mtu 1500 ether 00:bd:0f:fc:01:10 inet 172.16.32.1 netmask 0xffffff00 broadcast 172.16.32.255 nd6 options=9 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: tap0 flags=143 ifmaxaddr 0 port 6 priority 128 path cost 2000000 lagg0: flags=8843 metric 0 mtu 1500 ... inet 10.10.2.252 netmask 0xffffff00 broadcast 10.10.2.255 nd6 options=9 media: Ethernet autoselect status: active laggproto failover lagghash l2,l3,l4 laggport: alc0 flags=1 laggport: wlan0 flags=4 tap0: flags=8903 metric 0 mtu 1500 options=80000 ether 00:bd:8f:62:67:10 nd6 options=9 media: Ethernet autoselect status: no carrier wlan0: flags=8843 metric 0 mtu 1500 ... pflog0: flags=141 metric 0 mtu 33160 tap9: flags=8802 metric 0 mtu 1500 options=80000 ether 00:bd:cb:46:02:09 nd6 options=1 media: Ethernet autoselect status: no carrier tap1: flags=8802 metric 0 mtu 1500 options=80000 ether 00:bd:58:61:02:01 nd6 options=1 media: Ethernet autoselect status: no carrier Willy, PS. sorry for the x post as wasn't sure which list.. From owner-freebsd-net@FreeBSD.ORG Sun Jan 11 22:47:02 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4FEC876; Sun, 11 Jan 2015 22:47:02 +0000 (UTC) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (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 8FAA3BD5; Sun, 11 Jan 2015 22:47:01 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 3272716A403; Sun, 11 Jan 2015 23:46:53 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNsD98Uk7GBQ; Sun, 11 Jan 2015 23:46:51 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:a07a:8688:5c0:df34] (unknown [IPv6:2001:4cb8:3:1:a07a:8688:5c0:df34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 2E7B016A401; Sun, 11 Jan 2015 23:46:51 +0100 (CET) Message-ID: <54B2FD59.9000407@digiware.nl> Date: Sun, 11 Jan 2015 23:46:49 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: williamecowell@hush.ai, freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org Subject: Re: ipv4 routing from bhyve References: <20150111213203.60018E00B1@smtp.hushmail.com> In-Reply-To: <20150111213203.60018E00B1@smtp.hushmail.com> Content-Type: text/plain; charset=windows-1252 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: Sun, 11 Jan 2015 22:47:03 -0000 On 11-1-2015 22:32, williamecowell@hush.ai wrote: > Hello, I hope I can have some assistance. > > I am trying to get networking via wlan0 but without NAT or bridging (doesn't work on wifi unless WDS). > > say my my main network is 10.10.2.0/24, gateway/internet is 10.10.2.1, my ip is 10.10.2.252. > > I started to config my bhyve network on 172.16.32.0/24 > > I added a bridge interface with an ip of 172.16.32.1 > > enable forwarding and fastforwarding. from my understanding of the handbook chapter things should work when I type: > > # route add -net 172.16.32.0/24 10.10.2.252 > route: writing to routing socket: File exists > add net 172.16.32.0: gateway 10.10.2.252 fib 0: route already in table > # > > # netstat -4nr > Routing tables > > Internet: > Destination Gateway Flags Netif Expire > default 10.10.2.1 UGS lagg0 > 127.0.0.1 link#3 UH lo0 > 10.10.2.0/24 link#5 U lagg0 > 10.10.2.252 link#5 UHS lo0 > 172.16.32.0/24 link#4 U bridge0 > 172.16.32.1 link#4 UHS lo0 > # > > bridge0: flags=8843 metric 0 mtu 1500 > ether 00:bd:0f:fc:01:10 > inet 172.16.32.1 netmask 0xffffff00 broadcast 172.16.32.255 > nd6 options=9 > 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: tap0 flags=143 > ifmaxaddr 0 port 6 priority 128 path cost 2000000 > lagg0: flags=8843 metric 0 mtu 1500 > ... > inet netmask 0xffffff00 broadcast 10.10.2.255 > nd6 options=9 > media: Ethernet autoselect > status: active > laggproto failover lagghash l2,l3,l4 > laggport: alc0 flags=1 > laggport: wlan0 flags=4 > tap0: flags=8903 metric 0 mtu 1500 > options=80000 > ether 00:bd:8f:62:67:10 > nd6 options=9 > media: Ethernet autoselect > status: no carrier > wlan0: flags=8843 metric 0 mtu 1500 > ... > pflog0: flags=141 metric 0 mtu 33160 > tap9: flags=8802 metric 0 mtu 1500 > options=80000 > ether 00:bd:cb:46:02:09 > nd6 options=1 > media: Ethernet autoselect > status: no carrier > tap1: flags=8802 metric 0 mtu 1500 > options=80000 > ether 00:bd:58:61:02:01 > nd6 options=1 > media: Ethernet autoselect > status: no carrier Well one of the things of concern is the fact that your tap interfaces have: status: no carrier My connected bhyve vm's have, amongst others: status: active groups: tap Opened by PID 20763 And my bridge device tells me: bridge0: flags=8843 metric 0 mtu 1500 ether 02:76:2d:3d:9c:00 inet xxx.xxx.xxx.xxx netmask 0xff000000 broadcast 37.255.255.255 nd6 options=9 groups: bridge 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: tap651 flags=143 ifmaxaddr 0 port 11 priority 128 path cost 2000000 member: tap6 flags=143 ifmaxaddr 0 port 10 priority 128 path cost 55 member: tap14041 flags=143 ifmaxaddr 0 port 9 priority 128 path cost 2000000 member: tap13101 flags=143 ifmaxaddr 0 port 8 priority 128 path cost 2000000 member: tap12041 flags=143 ifmaxaddr 0 port 6 priority 128 path cost 2000000 member: tap13 flags=143 ifmaxaddr 0 port 4 priority 128 path cost 2000000 member: em0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 20000 So I think you first need to connect your VM's, before anything else will start to work. Like adding the tap-ifs to the bridge. And on the host itself you don't really need to add routing for the VM's because everything is actually already connected. Which is what the netstat output tells you. The routing table tells you that traffic for 172.16.32.0/24 link#4 U bridge0 is send into the the bridge0 devices, which is directly connected. And ip-nrs in that range should appear in the the arp table. And the host then knows how to get to them directly. Routing for 172.16.32.0/24, if any needed, will be required on other hosts on you network on lagg0. Unless all hosts there have 10.10.2.252 as their default route. Regards, --WjW From owner-freebsd-net@FreeBSD.ORG Sun Jan 11 22:59:53 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93E6AB06; Sun, 11 Jan 2015 22:59:53 +0000 (UTC) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 4C01DCAB; Sun, 11 Jan 2015 22:59:53 +0000 (UTC) Received: by mail-qg0-f42.google.com with SMTP id q108so15614237qgd.1; Sun, 11 Jan 2015 14:59:52 -0800 (PST) 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=jO4qqRqiAf84By1LZZ/WryI32LSxWUVSn+abzMqjUwk=; b=eK2tZAiRqw7WrSon6ZRkTqgzEFsyvJPKxBRDcafH9XAZb9iENEWc5drP6jmmGHYLFz FiqPFWi54/VmKJINIOkybThP6xSiXKk90p5ozdDsCbXYL1RyIFej44LQMWv6GvHgbVKi 71pl+cdTpObRxd9iv8H54s8xQ1U2QaRb/QsEjJiT/gaXNsf0UADFHkNykPgWAJpqQ4Qo /QpeFqCzwXibmDMW9QtUsVdyvlZAoJ7Btc9Bxb8/WL29gELgNu4sFiVtHHpUyO3YMs3O o4ixip3wUHOnGdLQGHa6ThtAhEJWA5HICzlk6WVfDGgJHNgmkWvSSIW5fKDRcIYx0OdQ INUA== MIME-Version: 1.0 X-Received: by 10.140.20.50 with SMTP id 47mr42240029qgi.61.1421017192396; Sun, 11 Jan 2015 14:59:52 -0800 (PST) Received: by 10.96.218.162 with HTTP; Sun, 11 Jan 2015 14:59:52 -0800 (PST) In-Reply-To: <20150111213203.60018E00B1@smtp.hushmail.com> References: <20150111213203.60018E00B1@smtp.hushmail.com> Date: Sun, 11 Jan 2015 14:59:52 -0800 Message-ID: Subject: Re: ipv4 routing from bhyve From: Jason Cox To: williamecowell@hush.ai Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net@freebsd.org, freebsd-virtualization@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: Sun, 11 Jan 2015 22:59:53 -0000 I am in no way an expert on bhyve (have not used it) so I am going to look at this from a pure network standpoint. A bridge is a layer 2 connection and is used to bridge two separate networks over layer 2. That means they share the same IP subnet, but have no other means of connecting together physically (note: to connect two networks with different IP Subnets IE: 10.10.1.0/24 and 172.16.32.0/24 you use a router since that is layer 3). So with an example like using VirtualHost, when you add a VM and set it to bridge, you are telling VirtualHost you want the VM to be on the same network as your physical machine. Thus from the standpoint of the rest of you network, it "looks" like it is a separate machine. It could even DHCP from your LANs DHCP server and get a LAN IP if you wanted. So your bridge needs to contain the physical interface you want to pass traffic out on (like your wlan0 or lagg0). Then you add your bhyve guests as taps to that bridge to get them access to the same physical network over the bridge. You really do not need to set an IP on the bridge interface, unless say for example you where going to bridge two physical networks together on like em0 and em1. You would assign an IP to bridge0, not em0 or em1 to be able to access/admin the server from either LAN. I hope this helps some... On Sun, Jan 11, 2015 at 1:32 PM, wrote: > Hello, I hope I can have some assistance. > > I am trying to get networking via wlan0 but without NAT or bridging > (doesn't work on wifi unless WDS). > > say my my main network is 10.10.2.0/24, gateway/internet is 10.10.2.1, my > ip is 10.10.2.252. > > I started to config my bhyve network on 172.16.32.0/24 > > I added a bridge interface with an ip of 172.16.32.1 > > enable forwarding and fastforwarding. from my understanding of the > handbook chapter things should work when I type: > > # route add -net 172.16.32.0/24 10.10.2.252 > route: writing to routing socket: File exists > add net 172.16.32.0: gateway 10.10.2.252 fib 0: route already in table > # > > # netstat -4nr > Routing tables > > Internet: > Destination Gateway Flags Netif Expire > default 10.10.2.1 UGS lagg0 > 127.0.0.1 link#3 UH lo0 > 10.10.2.0/24 link#5 U lagg0 > 10.10.2.252 link#5 UHS lo0 > 172.16.32.0/24 link#4 U bridge0 > 172.16.32.1 link#4 UHS lo0 > # > > bridge0: flags=8843 metric 0 mtu > 1500 > ether 00:bd:0f:fc:01:10 > inet 172.16.32.1 netmask 0xffffff00 broadcast 172.16.32.255 > nd6 options=9 > 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: tap0 flags=143 > ifmaxaddr 0 port 6 priority 128 path cost 2000000 > lagg0: flags=8843 metric 0 mtu 1500 > ... > inet 10.10.2.252 netmask 0xffffff00 broadcast 10.10.2.255 > nd6 options=9 > media: Ethernet autoselect > status: active > laggproto failover lagghash l2,l3,l4 > laggport: alc0 flags=1 > laggport: wlan0 flags=4 > tap0: flags=8903 metric 0 mtu 1500 > options=80000 > ether 00:bd:8f:62:67:10 > nd6 options=9 > media: Ethernet autoselect > status: no carrier > wlan0: flags=8843 metric 0 mtu 1500 > ... > pflog0: flags=141 metric 0 mtu 33160 > tap9: flags=8802 metric 0 mtu 1500 > options=80000 > ether 00:bd:cb:46:02:09 > nd6 options=1 > media: Ethernet autoselect > status: no carrier > tap1: flags=8802 metric 0 mtu 1500 > options=80000 > ether 00:bd:58:61:02:01 > nd6 options=1 > media: Ethernet autoselect > status: no carrier > > Willy, > > PS. sorry for the x post as wasn't sure which list.. > > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to " > freebsd-virtualization-unsubscribe@freebsd.org" > -- Jason Cox From owner-freebsd-net@FreeBSD.ORG Mon Jan 12 08:42:48 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 001FA6C7 for ; Mon, 12 Jan 2015 08:42:47 +0000 (UTC) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.hushmail.com", Issuer "Self-signed" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C9530A89 for ; Mon, 12 Jan 2015 08:42:47 +0000 (UTC) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by smtp2.hushmail.com (Postfix) with SMTP id A8A7DA0208 for ; Mon, 12 Jan 2015 08:11:20 +0000 (UTC) Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32]) by smtp2.hushmail.com (Postfix) with ESMTP; Mon, 12 Jan 2015 08:11:19 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id E7779E00B1; Mon, 12 Jan 2015 08:11:19 +0000 (UTC) MIME-Version: 1.0 Date: Mon, 12 Jan 2015 08:11:19 +0000 To: "Willem Jan Withagen" , freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org Subject: Re: ipv4 routing from bhyve From: williamecowell@hush.ai In-Reply-To: <54B2FD59.9000407@digiware.nl> References: <20150111213203.60018E00B1@smtp.hushmail.com> <54B2FD59.9000407@digiware.nl> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20150112081119.E7779E00B1@smtp.hushmail.com> 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, 12 Jan 2015 08:42:48 -0000 >Well one of the things of concern is the fact that your tap >interfaces >have: > status: no carrier > >My connected bhyve vm's have, amongst others: > status: active > groups: tap > Opened by PID 20763 > I had no running bhyve vms when I ran the commands. >And my bridge device tells me: >bridge0: flags=8843 metric >0 mtu >1500 > ether 02:76:2d:3d:9c:00 > inet xxx.xxx.xxx.xxx netmask 0xff000000 broadcast >37.255.255.255 > nd6 options=9 > groups: bridge > 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: tap651 >flags=143 > ifmaxaddr 0 port 11 priority 128 path cost 2000000 > member: tap6 flags=143 > ifmaxaddr 0 port 10 priority 128 path cost 55 > member: tap14041 >flags=143 > ifmaxaddr 0 port 9 priority 128 path cost 2000000 > member: tap13101 >flags=143 > ifmaxaddr 0 port 8 priority 128 path cost 2000000 > member: tap12041 >flags=143 > ifmaxaddr 0 port 6 priority 128 path cost 2000000 > member: tap13 flags=143 > ifmaxaddr 0 port 4 priority 128 path cost 2000000 > member: em0 flags=143 > ifmaxaddr 0 port 1 priority 128 path cost 20000 > > >So I think you first need to connect your VM's, before anything >else >will start to work. Like adding the tap-ifs to the bridge. > >And on the host itself you don't really need to add routing for >the VM's >because everything is actually already connected. Which is what the >netstat output tells you. The routing table tells you that traffic >for > 172.16.32.0/24 link#4 U bridge0 >is send into the the bridge0 devices, which is directly connected. >And ip-nrs in that range should appear in the the arp table. >And the host then knows how to get to them directly. > >Routing for 172.16.32.0/24, if any needed, will be required on >other >hosts on you network on lagg0. Unless all hosts there have >10.10.2.252 >as their default route. > On my gateway/router/internet connection, I added a static route via its web interface: 172.16.32.0 255.255.255.0 10.10.2.252 think maybe I am mis-understanding something. Basically, Internet connected laptop via wifi on a 10.10.2.0/24 network, laptops IP 10.10.2.252, gateway IP is 10.10.2.1. I want to put my VMs on a separate, but internet connected subnet 172.16.32.0/24 in the bhyve vms: # cat /etc/rc.conf: ifconfig_vtnet0="172.16.32.11/24" defaultrouter="172.16.32.1" # cat /etc/resolv.conf nameserver 127.0.0.1 #unbound can this sort of network config be done without NAT or a bridge, by pure routing? >Regards, >--WjW From owner-freebsd-net@FreeBSD.ORG Mon Jan 12 09:40:28 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4DD0DE8 for ; Mon, 12 Jan 2015 09:40:28 +0000 (UTC) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.hushmail.com", Issuer "Self-signed" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 30798F80 for ; Mon, 12 Jan 2015 09:40:27 +0000 (UTC) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id 3C21860295 for ; Mon, 12 Jan 2015 09:03:03 +0000 (UTC) Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32]) by smtp5.hushmail.com (Postfix) with ESMTP; Mon, 12 Jan 2015 09:03:02 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 89310E00B3; Mon, 12 Jan 2015 09:03:02 +0000 (UTC) MIME-Version: 1.0 Date: Mon, 12 Jan 2015 09:03:02 +0000 To: "Willem Jan Withagen" , freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org Subject: Re: ipv4 routing from bhyve From: williamecowell@hush.ai In-Reply-To: <20150112081119.E7779E00B1@smtp.hushmail.com> References: <20150111213203.60018E00B1@smtp.hushmail.com> <54B2FD59.9000407@digiware.nl> <20150112081119.E7779E00B1@smtp.hushmail.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20150112090302.89310E00B3@smtp.hushmail.com> 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, 12 Jan 2015 09:40:28 -0000 please ignore, for some reason autobridge wasn't picking up newly create taps From owner-freebsd-net@FreeBSD.ORG Mon Jan 12 12:43:02 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0CD60B05; Mon, 12 Jan 2015 12:43:02 +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 DFD11894; Mon, 12 Jan 2015 12:43:01 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-233-252.lns20.per1.internode.on.net [121.45.233.252]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t0CCgnh1030737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 12 Jan 2015 04:42:52 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54B3C143.70505@freebsd.org> Date: Mon, 12 Jan 2015 20:42:43 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: williamecowell@hush.ai, freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org Subject: Re: ipv4 routing from bhyve References: <20150111213203.60018E00B1@smtp.hushmail.com> In-Reply-To: <20150111213203.60018E00B1@smtp.hushmail.com> Content-Type: text/plain; charset=windows-1252; 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: Mon, 12 Jan 2015 12:43:02 -0000 On 1/12/15 5:32 AM, williamecowell@hush.ai wrote: > Hello, I hope I can have some assistance. > > I am trying to get networking via wlan0 but without NAT or bridging (doesn't work on wifi unless WDS). > > say my my main network is 10.10.2.0/24, gateway/internet is 10.10.2.1, my ip is 10.10.2.252. > > I started to config my bhyve network on 172.16.32.0/24 > > I added a bridge interface with an ip of 172.16.32.1 > > enable forwarding and fastforwarding. from my understanding of the handbook chapter things should work when I type: > > # route add -net 172.16.32.0/24 10.10.2.252 > route: writing to routing socket: File exists > add net 172.16.32.0: gateway 10.10.2.252 fib 0: route already in table > # > > # netstat -4nr > Routing tables > > Internet: > Destination Gateway Flags Netif Expire > default 10.10.2.1 UGS lagg0 > 127.0.0.1 link#3 UH lo0 > 10.10.2.0/24 link#5 U lagg0 > 10.10.2.252 link#5 UHS lo0 > 172.16.32.0/24 link#4 U bridge0 > 172.16.32.1 link#4 UHS lo0 > # > > bridge0: flags=8843 metric 0 mtu 1500 > ether 00:bd:0f:fc:01:10 > inet 172.16.32.1 netmask 0xffffff00 broadcast 172.16.32.255 > nd6 options=9 > 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: tap0 flags=143 > ifmaxaddr 0 port 6 priority 128 path cost 2000000 > lagg0: flags=8843 metric 0 mtu 1500 > ... > inet 10.10.2.252 netmask 0xffffff00 broadcast 10.10.2.255 > nd6 options=9 > media: Ethernet autoselect > status: active > laggproto failover lagghash l2,l3,l4 > laggport: alc0 flags=1 > laggport: wlan0 flags=4 > tap0: flags=8903 metric 0 mtu 1500 > options=80000 > ether 00:bd:8f:62:67:10 > nd6 options=9 > media: Ethernet autoselect > status: no carrier > wlan0: flags=8843 metric 0 mtu 1500 > ... > pflog0: flags=141 metric 0 mtu 33160 > tap9: flags=8802 metric 0 mtu 1500 > options=80000 > ether 00:bd:cb:46:02:09 > nd6 options=1 > media: Ethernet autoselect > status: no carrier > tap1: flags=8802 metric 0 mtu 1500 > options=80000 > ether 00:bd:58:61:02:01 > nd6 options=1 > media: Ethernet autoselect > status: no carrier > > Willy, > > PS. sorry for the x post as wasn't sure which list.. I may be misunderstanding something here, but are you routing or bridging? or ar eyou trying to have a virtual VM-network (using bridging) to hook VMS together, and then using routing from that to reach the outside? obviously that will require some NAT somewhere. > > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Jan 13 13:05:04 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88E06765 for ; Tue, 13 Jan 2015 13:05:04 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 6F65FBA5 for ; Tue, 13 Jan 2015 13:05:04 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0DD54o8056655 for ; Tue, 13 Jan 2015 13:05:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 188897] [dc] dc ethernet driver seems to prevent the detection of other NIC chipsets Date: Tue, 13 Jan 2015 13:05:04 +0000 X-Bugzilla-Reason: 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 Only Me X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal 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: Tue, 13 Jan 2015 13:05:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188897 John Baldwin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhb@FreeBSD.org --- Comment #5 from John Baldwin --- I would also need a verbose dmesg (so dmesg from 'boot -v') for both of your PRs. In particular, I need to see what the PCI-PCI bridge driver is doing under the hood to manage its windows. It seems odd to me that your BIOS is assigning prefetchable memory to the memory registers for these devices. One hack would be to force the re(4) driver to use its I/O bar instead of its memory bar (you can set the 'hw.re.prefer_iomap=1' tunable in loader.conf to test this). That would confirm that the issue is with the memory BAR. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Jan 13 20:58:07 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B82F7E79 for ; Tue, 13 Jan 2015 20:58:07 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 9EB17B11 for ; Tue, 13 Jan 2015 20:58: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 t0DKw7uZ091087 for ; Tue, 13 Jan 2015 20:58:07 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 172675] [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hostcache.list) race condition causing memory corruption Date: Tue, 13 Jan 2015 20:58:07 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 8.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc attachments.created 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, 13 Jan 2015 20:58:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=172675 John Baldwin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhb@FreeBSD.org --- Comment #6 from John Baldwin --- Created attachment 151584 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=151584&action=edit sbuf_hc_list.patch It is true that cache_count updates are very racy, and it might be worth fixing them to be atomic. However, those would not prevent the corruption. If the cache grew during the sysctl even with the atomic ops you could still overflow the buffer. I started out by adding explicit checks of 'p - buf >= bufsize' to break out of the loop. However, the sbuf(9) API already provides a nice way to handle variable output into a fixed size buffer while handling overflow correctly, etc. I've attached a patch which takes this route and converts the sysctl to use an sbuf instead. Please test. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Jan 13 21:14:05 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D5173E2 for ; Tue, 13 Jan 2015 21:14:05 +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 E85B3CF3 for ; Tue, 13 Jan 2015 21:14:04 +0000 (UTC) Received: from new-host-2.home (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3A8A2B945; Tue, 13 Jan 2015 16:14:03 -0500 (EST) Message-ID: <54B58A98.1020402@FreeBSD.org> Date: Tue, 13 Jan 2015 16:14:00 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Mike Tancsa , Paul Thornton , freebsd-net@freebsd.org Subject: Re: Issue with forwarding when creates new interface [was USB Tethering and forwarding] References: <1419680989.938234917.k6otv1bh@frv34.fwdcdn.com> <1420288398.485039365.so6mgquw@frv34.fwdcdn.com> <54A7FA6C.8030603@prt.org> <54A82FA0.3090704@sentex.net> In-Reply-To: <54A82FA0.3090704@sentex.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 13 Jan 2015 16:14:03 -0500 (EST) 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, 13 Jan 2015 21:14:05 -0000 On 1/3/15 1:06 PM, Mike Tancsa wrote: > On 1/3/2015 9:19 AM, Paul Thornton wrote: >> Hi, >> >> I can also replicate this behaviour on 10.1-RELEASE by simply creating >> an additional vlan interface. It affects IPv4 and IPv6 forwarding. > > Strange, I dont see that on RELENG_10 > > 0{marble}# ifconfig em2 up > 0{marble}# ifconfig em2.3 create 1.1.1.2/24 > 0{marble}# sysctl -a | grep forwarding > net.inet.ip.forwarding: 1 > net.inet.ip.fastforwarding: 0 > net.inet6.ip6.forwarding: 0 > 0{marble}# ifconfig vlan4 create 2.2.2.2 vlan 4 vlandev em2 > 0{marble}# sysctl -a | grep forwarding > net.inet.ip.forwarding: 1 > net.inet.ip.fastforwarding: 0 > net.inet6.ip6.forwarding: 0 > 0{marble}# > > do you set forwarding via just /etc/sysctl.conf or in /etc/rc.conf via > ipv6_gateway_enable and gateway_enable. I seem to recall some discussion > about there being a difference. Perhaps devd is calling something that > then fiddles with the setting ignoring whats in sysctl.conf ? Yes, devd is running /etc/rc.d/netif start which probably checks gateway_enable and sets the sysctl based on that overriding what it in sysctl.conf. Just set gateway_enable=YES in rc.conf instead. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jan 13 21:23:05 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DC8C5EF for ; Tue, 13 Jan 2015 21:23:05 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 152A0DE6 for ; Tue, 13 Jan 2015 21:23:05 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0DLN4WR003120 for ; Tue, 13 Jan 2015 21:23:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196501] [em] Intel 82573 nic built on my pdsbm-ln2 1U server and only one port will work. Date: Tue, 13 Jan 2015 21:23:04 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: New 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: Tue, 13 Jan 2015 21:23:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196501 John Baldwin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhb@FreeBSD.org --- Comment #5 from John Baldwin --- Try setting 'hint.agp.0.disabled=1' in loader.conf. agp0 allocates a page of address space that causes a trickle down effect where em0 and em1 have to allocate different BARs. That said, em0/1 should be able to cope with the alternate BARs, though it may be that em0 doesn't work because em1's bridge is still decoding those addresses when em0 tries to probe. I bet that if we forced em0 to reattach it would actually work ok (e.g using my devctl thing that isn't in the tree yet). Ultimately this is a PCI bus bug, not an em(4) issue. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Jan 13 23:21:14 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64350D67 for ; Tue, 13 Jan 2015 23:21:14 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 4B33DCF5 for ; Tue, 13 Jan 2015 23:21:14 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0DNLEa1054101 for ; Tue, 13 Jan 2015 23:21:14 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196698] Add infiniband support to arp(8) so arp -da will work Date: Tue, 13 Jan 2015 23:21:14 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to 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: Tue, 13 Jan 2015 23:21:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196698 Garrett Cooper,425-314-3911 changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org CC| |benno@FreeBSD.org, | |hselasky@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Jan 14 05:38:03 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 852A16E4 for ; Wed, 14 Jan 2015 05:38:03 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 6D6CB8E9 for ; Wed, 14 Jan 2015 05:38: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 t0E5c325007687 for ; Wed, 14 Jan 2015 05:38:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196698] Add infiniband support to arp(8) so arp -da will work Date: Wed, 14 Jan 2015 05:38:03 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: hselasky@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: hselasky@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: Wed, 14 Jan 2015 05:38:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196698 Hans Petter Selasky changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |hselasky@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Jan 14 09:08:09 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25E155D1 for ; Wed, 14 Jan 2015 09:08:09 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 0CDD38C for ; Wed, 14 Jan 2015 09:08:09 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0E988t6062070 for ; Wed, 14 Jan 2015 09:08:08 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196501] [em] Intel 82573 nic built on my pdsbm-ln2 1U server and only one port will work. Date: Wed, 14 Jan 2015 09:08:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: topper727@yahoo.com X-Bugzilla-Status: New 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, 14 Jan 2015 09:08:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196501 --- Comment #6 from Mark --- hint.agp.0.disabled=1 in my loader.conf has resolved the problem. It is funny how only in freebsd you have to do this but every other system is fine with both nic's -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Jan 14 09:43:07 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B88A2E8E for ; Wed, 14 Jan 2015 09:43:07 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 9F34667B for ; Wed, 14 Jan 2015 09:43: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 t0E9h7XK084965 for ; Wed, 14 Jan 2015 09:43:07 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196501] [em] Intel 82573 nic built on my pdsbm-ln2 1U server and only one port will work. Date: Wed, 14 Jan 2015 09:43:07 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: topper727@yahoo.com X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution 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, 14 Jan 2015 09:43:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196501 Mark changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Jan 14 13:50:00 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1CF285F; Wed, 14 Jan 2015 13:50:00 +0000 (UTC) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2a01:4f8:201:2327:144:76:253:226]) (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 9F43328C; Wed, 14 Jan 2015 13:50:00 +0000 (UTC) Received: from [IPv6:2a01:3a0:a:90:9d71:3530:2767:97f0] (unknown [IPv6:2a01:3a0:a:90:9d71:3530:2767:97f0]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id 2C2433090D4; Wed, 14 Jan 2015 13:49:58 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail.tyknet.dk 2C2433090D4 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1421243398; bh=7vJZXob4kuA6ST5tk4D8lI0+H06wpJf1lxxI1rSuSzU=; h=Date:From:To:Subject; b=oGFNME5uxi0AcImsJltBNvDpvaouz5joASYZHW+dIC5eHbjhDgUuNPW8v0zVqLVgq 4dlsZ9SDMQ+NvAzfd97toNtXgUrIXzg57cfKTQkiYUeV+Hjh/+2X0ZA41jVVA1NMRm QO7UebwAJxjhC8iJ0T8NtMywZ6j8pNo7uj+7vRSXmjoSvY6H818IV9KjWORk9B+c0J y9C31VVCdJRFmbtBMLQ1hz9gl6OTUnpjVELBhkopXalzhm6HxGLygIb/pMCkyR1ngV N0cQtW+BGv9LaC8hVg7bRW/p7qtjmqnQVrEFdamJ2bQ3TRqX4CxliFmaUefdnYdQ7r 81CsE96GT9LSA== Message-ID: <54B67405.4010203@gibfest.dk> Date: Wed, 14 Jan 2015 14:49:57 +0100 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org, hrs@freebsd.org Subject: timeout option in ping6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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, 14 Jan 2015 13:50:01 -0000 Hello list, Can we please get a timeout option for ping6? There is a PR open for this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183787 There is also a patch for ping6 by hrs@ in this other PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=151023 I was hoping that someone(tm) would take the patch or something similar and commit it :) Thanks! /Thomas Steen Rasmussen From owner-freebsd-net@FreeBSD.ORG Wed Jan 14 13:51:59 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C199923 for ; Wed, 14 Jan 2015 13:51:59 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 03093360 for ; Wed, 14 Jan 2015 13:51: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 t0EDpwdi003179 for ; Wed, 14 Jan 2015 13:51:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196501] [em] Intel 82573 nic built on my pdsbm-ln2 1U server and only one port will work. Date: Wed, 14 Jan 2015 13:51:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: Closed 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, 14 Jan 2015 13:51:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196501 --- Comment #7 from John Baldwin --- It is a workaround. The real issue is a PCI bus issue that I hope to ultimately resolve via other means. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Jan 14 23:37:56 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D67BF7A9; Wed, 14 Jan 2015 23:37:56 +0000 (UTC) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (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 8B14B18A; Wed, 14 Jan 2015 23:37:56 +0000 (UTC) Received: by mail-qg0-f51.google.com with SMTP id i50so9470390qgf.10; Wed, 14 Jan 2015 15:37:55 -0800 (PST) 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=O/s9EUQrpdwTtAFp2fycJ6X/zJzXTOup2JtGiB87HLk=; b=oIQmLdPOOm/Xn3kS2jiPC6FwJrk4Ip1IC20NmbLfjtBFbhwh5nAyo/fhdOBjfktqN/ JS6EmRnutCauN/7xmzRTO/IM/GvvRL+tU+6NSSHtSmEtIoqF3fT8ayPah1vhJTEHxnIf Dj8aRhL/B15g9pCVkEbi9nRVLN55ji9eh/tUkGvHqst4xAq3nesIt+AX5FZ5i+aQPjwn ztUGT3bdc9XN7qMTz8SqSdcs3LshDHWpZ35xViSgL/i0NN7nn9t8qecumwzTuPYz9AZv iD7hB9KUb0sGQRu1Ri0s8Eeo++pRjs6FjYcRjhr00D8NsWnGaokJmtQrC+USAR6M1qoh BWDw== MIME-Version: 1.0 X-Received: by 10.229.50.135 with SMTP id z7mr11642872qcf.21.1421278675722; Wed, 14 Jan 2015 15:37:55 -0800 (PST) Received: by 10.96.73.69 with HTTP; Wed, 14 Jan 2015 15:37:55 -0800 (PST) In-Reply-To: References: <1364308780.51602.YahooMailClassic@web31809.mail.mud.yahoo.com> <02416974-D249-4432-9CE6-6093CA9FCCD7@netapp.com> Date: Wed, 14 Jan 2015 15:37:55 -0800 Message-ID: Subject: Re: ntpd bind() failure: Can't assign requested address From: hiren panchasara To: Hajimu UMEMOTO Content-Type: text/plain; charset=UTF-8 Cc: "" , "Eggert, Lars" , "schrodinger@konundrum.org" , "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, 14 Jan 2015 23:37:56 -0000 On Thu, Jan 8, 2015 at 9:48 AM, hiren panchasara wrote: [skip] > Btw, do you mind opening a phabricator review request so we can get a > closure on this? Thanks for the patch ume@. I've committed it to -head and will mfc in a week. https://reviews.freebsd.org/D1527 https://svnweb.freebsd.org/base?view=revision&revision=277202 Cheers, Hiren From owner-freebsd-net@FreeBSD.ORG Thu Jan 15 16:34:45 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9BCE877 for ; Thu, 15 Jan 2015 16:34:45 +0000 (UTC) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx142.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7366EB66 for ; Thu, 15 Jan 2015 16:34:44 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.09,404,1418112000"; d="scan'208";a="11958508" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx142-out.netapp.com with ESMTP; 15 Jan 2015 08:29:34 -0800 Received: from HIOEXCMBX02-PRD.hq.netapp.com (10.122.105.35) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 15 Jan 2015 08:29:34 -0800 Received: from HIOEXCMBX02-PRD.hq.netapp.com ([::1]) by hioexcmbx02-prd.hq.netapp.com ([fe80::906c:fcf4:e0a8:9f81%21]) with mapi id 15.00.0995.031; Thu, 15 Jan 2015 08:29:34 -0800 From: "Quattlebaum, Ryan" To: "freebsd-net@freebsd.org" Subject: Accessing socket APIs soon after accept Thread-Topic: Accessing socket APIs soon after accept Thread-Index: AQHQMN+s1D+Mgs6QWka0EkIfHwtzNg== Date: Thu, 15 Jan 2015 16:29:34 +0000 Message-ID: <1421339375968.94209@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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, 15 Jan 2015 16:34:45 -0000 Is there anything preventing applications from calling functions e.g. getso= ckname() right after accept()? Or is there a recommended pattern that appli= cations should use to ensure they get correct data? We recently upgraded to= a new version of Apache and are seeing uninitialized data coming back from= a few of these calls.=0A= =0A= Thanks,=0A= =0A= Ryan Quattlebaum=0A= Software Developer, NetApp, Inc.= From owner-freebsd-net@FreeBSD.ORG Thu Jan 15 18:20:09 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F09F976 for ; Thu, 15 Jan 2015 18:20:09 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (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 A856AABF for ; Thu, 15 Jan 2015 18:20:08 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id l15so37003948wiw.2 for ; Thu, 15 Jan 2015 10:20:07 -0800 (PST) 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=SYJBbt2iN3BpC5HA8IGnZ3/xrfggobbwJWDzQ0C1hIg=; b=Gq/mQQeBnXgl61zCPtnA3JyIyjLCXvrHbAMjlzkc1Zs+c6oNDqkuQcWxKOuUD69f/U 0M4wVpDJYMEbnoJnhFek2Nl91hbJWlVdG/KVR+pjINZtHo5gArXGaIU00j9sVkZ3Wv7l l/PkMvzpdRF6y48haxZp98dgLJWmORLx9KlklhZF7SmP4FzNFHWXj5zUXeCN4+LzKB88 qLqSrmw5M4mNqr2+IFzmrh37OK4WboqQT4oSBNpg7q6RdCfDTkRB4ZWbGQLAXyTblzhT C4gnSnmnFmLqdF7GkIYiByq0y6qo4uWkTjSK+A8gy2nIdZMIaHA2nfoCOftEWSrbFUAg LzkA== MIME-Version: 1.0 X-Received: by 10.194.5.37 with SMTP id p5mr21493173wjp.20.1421346006917; Thu, 15 Jan 2015 10:20:06 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Thu, 15 Jan 2015 10:20:06 -0800 (PST) In-Reply-To: <1421339375968.94209@netapp.com> References: <1421339375968.94209@netapp.com> Date: Thu, 15 Jan 2015 10:20:06 -0800 X-Google-Sender-Auth: Juhfb_BJshD8sF5eJ7O7rTR5CZk Message-ID: Subject: Re: Accessing socket APIs soon after accept From: Adrian Chadd To: "Quattlebaum, Ryan" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Thu, 15 Jan 2015 18:20:09 -0000 On 15 January 2015 at 08:29, Quattlebaum, Ryan wrote: > Is there anything preventing applications from calling functions e.g. get= sockname() right after accept()? Or is there a recommended pattern that app= lications should use to ensure they get correct data? We recently upgraded = to a new version of Apache and are seeing uninitialized data coming back fr= om a few of these calls. I'm under the impression that once you get the FD from accept(), it should be fully formed and ready. Which version of FreeBSD/apache is it? can you come up with a test case that shows that it's happening? -adrian > Thanks, > > Ryan Quattlebaum > Software Developer, NetApp, Inc. > _______________________________________________ > 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 Thu Jan 15 23:29:50 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73862FF1 for ; Thu, 15 Jan 2015 23:29:50 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 59E31107 for ; Thu, 15 Jan 2015 23:29:50 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0FNToCp025444 for ; Thu, 15 Jan 2015 23:29:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196788] Log rotation non-existent for opensm; opensm expects SIGUSR1, not SIGHUP Date: Thu, 15 Jan 2015 23:29:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: Thu, 15 Jan 2015 23:29:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196788 Garrett Cooper,425-314-3911 changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Jan 16 08:04:30 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F3431F5; Fri, 16 Jan 2015 08:04:30 +0000 (UTC) Received: from forward3l.mail.yandex.net (forward3l.mail.yandex.net [IPv6:2a02:6b8:0:1819::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ED07CA44; Fri, 16 Jan 2015 08:04:29 +0000 (UTC) Received: from smtp12.mail.yandex.net (smtp12.mail.yandex.net [95.108.131.191]) by forward3l.mail.yandex.net (Yandex) with ESMTP id 2035A150136A; Fri, 16 Jan 2015 11:04:18 +0300 (MSK) Received: from smtp12.mail.yandex.net (localhost [127.0.0.1]) by smtp12.mail.yandex.net (Yandex) with ESMTP id 90DF016A16AF; Fri, 16 Jan 2015 11:04:17 +0300 (MSK) Received: from unknown (unknown [2a02:6b8:0:81f::114]) by smtp12.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 2GIs16rE2U-4GmO1gFW; Fri, 16 Jan 2015 11:04:16 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1421395456; bh=mj5LsUvIBooQMKnb1egJbQPhR3yLRaxHsHn9jgyaYLg=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=dEJ0E0guCXA7xFy8Pjl4+Xtjp9j2A+EcsVu6jEU+c/xjnMdG8Z7YA9jlDRr8fntyJ uh50O/Y8SFyvjRsPz79auAm7fO/dgLQEjZ6uHXof7KgagiN9C77sxGkJBqAPf3hTJp 4/Mg/GVsq8P9QM9NaYoScXSiskPlVqGtSSjVjHss= Authentication-Results: smtp12.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <54B8C5CE.7080903@yandex.ru> Date: Fri, 16 Jan 2015 11:03:26 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Thomas Steen Rasmussen , freebsd-net@freebsd.org, hrs@freebsd.org Subject: Re: timeout option in ping6 References: <54B67405.4010203@gibfest.dk> In-Reply-To: <54B67405.4010203@gibfest.dk> Content-Type: text/plain; charset=windows-1252 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, 16 Jan 2015 08:04:30 -0000 On 14.01.2015 16:49, Thomas Steen Rasmussen wrote: > Hello list, > > Can we please get a timeout option for ping6? > > There is a PR open for this: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183787 > > There is also a patch for ping6 by hrs@ in this other PR: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=151023 > > I was hoping that someone(tm) would take the patch or something similar > and commit it :) ping6 already has -x and -X options: -x waittime Time in milliseconds to wait for a reply for each packet sent. If a reply arrives later, the packet is not printed as replied, but considered as replied when calculating statistics. -X timeout Specify a timeout, in seconds, before ping exits regardless of how many packets have been received. -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Fri Jan 16 09:25:20 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F076771 for ; Fri, 16 Jan 2015 09:25:20 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 16C4E30A for ; Fri, 16 Jan 2015 09:25:20 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0G9PJDB006179 for ; Fri, 16 Jan 2015 09:25:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196788] Log rotation non-existent for opensm; opensm expects SIGUSR1, not SIGHUP Date: Fri, 16 Jan 2015 09:25:20 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: hselasky@FreeBSD.org X-Bugzilla-Status: New 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, 16 Jan 2015 09:25:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196788 --- Comment #1 from Hans Petter Selasky --- Don't forget to add "MFC after" to the commit. syslogd is a bit outside my area and I think someone else needs to comment on that. --HPS -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Jan 16 09:46:05 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F307DDF6; Fri, 16 Jan 2015 09:46:04 +0000 (UTC) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2a01:4f8:201:2327:144:76:253:226]) (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 AE86E794; Fri, 16 Jan 2015 09:46:04 +0000 (UTC) Received: from [IPv6:2a01:3a0:a:15::2] (unknown [IPv6:2a01:3a0:a:15::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id 60A7B30D145; Fri, 16 Jan 2015 09:45:53 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail.tyknet.dk 60A7B30D145 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1421401553; bh=SsqNj3Ud8t41SmQscOc41JQOqvP7oRvsdflgKS0DH8I=; h=Date:From:To:Subject:References:In-Reply-To; b=KBOgV2OpHdTQ8HHQyn4gVQr0+9xV3M426BWkzQJTtUvITuMYw0rJntgVFV8TXkbeJ mXGFx7Y4HKVXbmLswt7YuoiacAiwOLOb6Y8wORk1UzO0WYJ2h6qUv9QLysyBV8mYQo YGASFAbOAVSz6h3ZNMdf8ZsdpbXrDhdy7aF+YmVkb2H6385mu9wr69ysk68MWUQVZR kf5/qhfzyaI6OlIn6Y8hxPMBFZUHEgkIB5RGU+i6pUR3wnErqm87q8mprT5XFzVYuN KrU6KMt/bFIot2YPR1TlUnh8WBkW92edcQJjjr+f146gobyP4NQRonKQ63z2nxO5sB 1/lLq1QxHWNsw== Message-ID: <54B8DDD0.2040507@gibfest.dk> Date: Fri, 16 Jan 2015 10:45:52 +0100 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" , freebsd-net@freebsd.org, hrs@freebsd.org Subject: Re: timeout option in ping6 References: <54B67405.4010203@gibfest.dk> <54B8C5CE.7080903@yandex.ru> In-Reply-To: <54B8C5CE.7080903@yandex.ru> Content-Type: text/plain; charset=windows-1252 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, 16 Jan 2015 09:46:05 -0000 On 16-01-2015 09:03, Andrey V. Elsukov wrote: > On 14.01.2015 16:49, Thomas Steen Rasmussen wrote: >> Hello list, >> >> Can we please get a timeout option for ping6? >> >> There is a PR open for this: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183787 >> >> There is also a patch for ping6 by hrs@ in this other PR: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=151023 >> >> I was hoping that someone(tm) would take the patch or something similar >> and commit it :) > > ping6 already has -x and -X options: > > -x waittime > Time in milliseconds to wait for a reply for each packet sent. > If a reply arrives later, the packet is not printed as replied, > but considered as replied when calculating statistics. > > -X timeout > Specify a timeout, in seconds, before ping exits regardless of > how many packets have been received. > Hello, So it does! On head at least. I didn't notice that, but thats great! :) 10-stable and 9-stable are not so lucky though. Any chance of this commit http://svnweb.freebsd.org/base?view=revision&revision=273211 getting an MFC? Thanks :) /Thomas From owner-freebsd-net@FreeBSD.ORG Fri Jan 16 17:28:16 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1392DECD; Fri, 16 Jan 2015 17:28:16 +0000 (UTC) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx144.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BD941A4; Fri, 16 Jan 2015 17:28:15 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.09,412,1418112000"; d="scan'208";a="12792706" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx144-out.netapp.com with ESMTP; 16 Jan 2015 09:07:29 -0800 Received: from HIOEXCMBX02-PRD.hq.netapp.com (10.122.105.35) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 16 Jan 2015 09:07:29 -0800 Received: from HIOEXCMBX02-PRD.hq.netapp.com ([::1]) by hioexcmbx02-prd.hq.netapp.com ([fe80::906c:fcf4:e0a8:9f81%21]) with mapi id 15.00.0995.031; Fri, 16 Jan 2015 09:07:29 -0800 From: "Quattlebaum, Ryan" To: Adrian Chadd Subject: RE: Accessing socket APIs soon after accept Thread-Topic: Accessing socket APIs soon after accept Thread-Index: AQHQMN+s1D+Mgs6QWka0EkIfHwtzNpzCBCMAgAD35iE= Date: Fri, 16 Jan 2015 17:07:28 +0000 Message-ID: <1421428048190.48193@netapp.com> References: <1421339375968.94209@netapp.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Fri, 16 Jan 2015 17:28:16 -0000 Hi, Adrian. Thanks for taking a look at this.=0A= =0A= We're using FreeBSD 8.2 and httpd-2.4.10 with arp-1.5.1 and apr-util-1.5.4.= =0A= =0A= The problem we're seeing is pretty intermittent, so I hope this test case c= an shine a little bit of light on the = problem. We tried debugging this on our own by adding calls to getsockname(= ) right after the accept call (in srclib/apr/network_io/unix/sockets.c: apr= _socket_accept()) and logging the output. That's where we saw invalid data.= =0A= =0A= I took a look at the source code for the TCP syncache module and the accept= syscall. It looks like the new child socket is available for the applicati= on to accept after the call to sonewconn returns, but the address informati= on isn't set until further down in the function. Wouldn't this open a windo= w where an application could accept on a socket that the syncache code isn'= t done configuring?=0A= =0A= - Ryan Quattlebaum=0A= ________________________________________=0A= From: adrian.chadd@gmail.com on behalf of Adrian C= hadd =0A= Sent: Thursday, January 15, 2015 1:20 PM=0A= To: Quattlebaum, Ryan=0A= Cc: freebsd-net@freebsd.org=0A= Subject: Re: Accessing socket APIs soon after accept=0A= =0A= On 15 January 2015 at 08:29, Quattlebaum, Ryan=0A= wrote:=0A= > Is there anything preventing applications from calling functions e.g. get= sockname() right after accept()? Or is there a recommended pattern that app= lications should use to ensure they get correct data? We recently upgraded = to a new version of Apache and are seeing uninitialized data coming back fr= om a few of these calls.=0A= =0A= I'm under the impression that once you get the FD from accept(), it=0A= should be fully formed and ready.=0A= =0A= Which version of FreeBSD/apache is it? can you come up with a test=0A= case that shows that it's happening?=0A= =0A= =0A= =0A= -adrian=0A= =0A= > Thanks,=0A= >=0A= > Ryan Quattlebaum=0A= > Software Developer, NetApp, Inc.=0A= > _______________________________________________=0A= > freebsd-net@freebsd.org mailing list=0A= > http://lists.freebsd.org/mailman/listinfo/freebsd-net=0A= > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"= From owner-freebsd-net@FreeBSD.ORG Fri Jan 16 18:39:37 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80F57E31 for ; Fri, 16 Jan 2015 18:39:37 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 252BFC47 for ; Fri, 16 Jan 2015 18:39:37 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id n3so3990562wiv.3 for ; Fri, 16 Jan 2015 10:39:35 -0800 (PST) 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=qhKJql5junt38mHnRPU+6re5CE4pnhm17bgUE0K9AhE=; b=p/vjctq5TGURc9wl00/eif/0pFoMla30RdtJ0kpIJ7tuvrPTtQIWq4N68RUDlafsXG YS2IroWDMsmQ1gzryMie6p420nPxn3azJBMK00zwiH1+t+a9WjR8/JfM5IzF+oJ/J1dk S16vbeKYNr0d2ZUDZ07g3fM9g730GWjNyUm/f/cI47DfsVCvJrv+x12rv/RVaEv7FtA4 pp/wgA1tOgLFcHtaZD+FdsZUrVDKrWVwRBTmXSJiYdZO2p166RtSCRJnLpQgKLJUmt1m RoiNI/trzelX+VjQIqxHCcLfwdDo8vSCOTBt+dQltyWGqcoW+bq5B41DyDtEjCdTWbSr 9a8g== MIME-Version: 1.0 X-Received: by 10.180.7.198 with SMTP id l6mr9054618wia.26.1421433575515; Fri, 16 Jan 2015 10:39:35 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Fri, 16 Jan 2015 10:39:35 -0800 (PST) In-Reply-To: <1421428048190.48193@netapp.com> References: <1421339375968.94209@netapp.com> <1421428048190.48193@netapp.com> Date: Fri, 16 Jan 2015 10:39:35 -0800 X-Google-Sender-Auth: izRaKHfnggjxjRr8UZ1K07GOeQg Message-ID: Subject: Re: Accessing socket APIs soon after accept From: Adrian Chadd To: "Quattlebaum, Ryan" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Fri, 16 Jan 2015 18:39:37 -0000 Oh, I've no idea about -8. If that's what the code does then yeah, that seems wrong. Is it like that in -10 or -11 ? -adrian On 16 January 2015 at 09:07, Quattlebaum, Ryan wrote: > Hi, Adrian. Thanks for taking a look at this. > > We're using FreeBSD 8.2 and httpd-2.4.10 with arp-1.5.1 and apr-util-1.5.= 4. > > The problem we're seeing is pretty intermittent, so I hope this test case= can shine a little bit of light on th= e problem. We tried debugging this on our own by adding calls to getsocknam= e() right after the accept call (in srclib/apr/network_io/unix/sockets.c: a= pr_socket_accept()) and logging the output. That's where we saw invalid dat= a. > > I took a look at the source code for the TCP syncache module and the acce= pt syscall. It looks like the new child socket is available for the applica= tion to accept after the call to sonewconn returns, but the address informa= tion isn't set until further down in the function. Wouldn't this open a win= dow where an application could accept on a socket that the syncache code is= n't done configuring? > > - Ryan Quattlebaum > ________________________________________ > From: adrian.chadd@gmail.com on behalf of Adrian= Chadd > Sent: Thursday, January 15, 2015 1:20 PM > To: Quattlebaum, Ryan > Cc: freebsd-net@freebsd.org > Subject: Re: Accessing socket APIs soon after accept > > On 15 January 2015 at 08:29, Quattlebaum, Ryan > wrote: >> Is there anything preventing applications from calling functions e.g. ge= tsockname() right after accept()? Or is there a recommended pattern that ap= plications should use to ensure they get correct data? We recently upgraded= to a new version of Apache and are seeing uninitialized data coming back f= rom a few of these calls. > > I'm under the impression that once you get the FD from accept(), it > should be fully formed and ready. > > Which version of FreeBSD/apache is it? can you come up with a test > case that shows that it's happening? > > > > -adrian > >> Thanks, >> >> Ryan Quattlebaum >> Software Developer, NetApp, Inc. >> _______________________________________________ >> 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 Jan 16 18:46:03 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2690F33A; Fri, 16 Jan 2015 18:46:03 +0000 (UTC) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx144.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E9937D44; Fri, 16 Jan 2015 18:46:01 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.09,412,1418112000"; d="scan'208";a="12832173" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx144-out.netapp.com with ESMTP; 16 Jan 2015 10:40:51 -0800 Received: from HIOEXCMBX02-PRD.hq.netapp.com (10.122.105.35) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 16 Jan 2015 10:40:50 -0800 Received: from HIOEXCMBX02-PRD.hq.netapp.com ([::1]) by hioexcmbx02-prd.hq.netapp.com ([fe80::906c:fcf4:e0a8:9f81%21]) with mapi id 15.00.0995.031; Fri, 16 Jan 2015 10:40:50 -0800 From: "Quattlebaum, Ryan" To: Adrian Chadd Subject: RE: Accessing socket APIs soon after accept Thread-Topic: Accessing socket APIs soon after accept Thread-Index: AQHQMN+s1D+Mgs6QWka0EkIfHwtzNpzCBCMAgAD35iGAAJ/ggP//efwy Date: Fri, 16 Jan 2015 18:40:50 +0000 Message-ID: <1421433650372.44369@netapp.com> References: <1421339375968.94209@netapp.com> <1421428048190.48193@netapp.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Fri, 16 Jan 2015 18:46:03 -0000 I haven't checked head of line. I'll go take a look. We are in the process = of moving to 9.x, so I'll check that as well.=0A= =0A= Thanks for the help!=0A= Ryan=0A= ________________________________________=0A= From: adrian.chadd@gmail.com on behalf of Adrian C= hadd =0A= Sent: Friday, January 16, 2015 1:39 PM=0A= To: Quattlebaum, Ryan=0A= Cc: freebsd-net@freebsd.org=0A= Subject: Re: Accessing socket APIs soon after accept=0A= =0A= Oh, I've no idea about -8. If that's what the code does then yeah,=0A= that seems wrong. Is it like that in -10 or -11 ?=0A= =0A= =0A= =0A= -adrian=0A= =0A= =0A= On 16 January 2015 at 09:07, Quattlebaum, Ryan=0A= wrote:=0A= > Hi, Adrian. Thanks for taking a look at this.=0A= >=0A= > We're using FreeBSD 8.2 and httpd-2.4.10 with arp-1.5.1 and apr-util-1.5.= 4.=0A= >=0A= > The problem we're seeing is pretty intermittent, so I hope this test case= can shine a little bit of light on th= e problem. We tried debugging this on our own by adding calls to getsocknam= e() right after the accept call (in srclib/apr/network_io/unix/sockets.c: a= pr_socket_accept()) and logging the output. That's where we saw invalid dat= a.=0A= >=0A= > I took a look at the source code for the TCP syncache module and the acce= pt syscall. It looks like the new child socket is available for the applica= tion to accept after the call to sonewconn returns, but the address informa= tion isn't set until further down in the function. Wouldn't this open a win= dow where an application could accept on a socket that the syncache code is= n't done configuring?=0A= >=0A= > - Ryan Quattlebaum=0A= > ________________________________________=0A= > From: adrian.chadd@gmail.com on behalf of Adrian= Chadd =0A= > Sent: Thursday, January 15, 2015 1:20 PM=0A= > To: Quattlebaum, Ryan=0A= > Cc: freebsd-net@freebsd.org=0A= > Subject: Re: Accessing socket APIs soon after accept=0A= >=0A= > On 15 January 2015 at 08:29, Quattlebaum, Ryan=0A= > wrote:=0A= >> Is there anything preventing applications from calling functions e.g. ge= tsockname() right after accept()? Or is there a recommended pattern that ap= plications should use to ensure they get correct data? We recently upgraded= to a new version of Apache and are seeing uninitialized data coming back f= rom a few of these calls.=0A= >=0A= > I'm under the impression that once you get the FD from accept(), it=0A= > should be fully formed and ready.=0A= >=0A= > Which version of FreeBSD/apache is it? can you come up with a test=0A= > case that shows that it's happening?=0A= >=0A= >=0A= >=0A= > -adrian=0A= >=0A= >> Thanks,=0A= >>=0A= >> Ryan Quattlebaum=0A= >> Software Developer, NetApp, Inc.=0A= >> _______________________________________________=0A= >> freebsd-net@freebsd.org mailing list=0A= >> http://lists.freebsd.org/mailman/listinfo/freebsd-net=0A= >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"= =0A= From owner-freebsd-net@FreeBSD.ORG Sat Jan 17 19:21:59 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BD98CF0; Sat, 17 Jan 2015 19:21:59 +0000 (UTC) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (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 03B52E1D; Sat, 17 Jan 2015 19:21:59 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id k14so25633010wgh.2; Sat, 17 Jan 2015 11:21:57 -0800 (PST) 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=UrmnHTBTLREU6EdHEXGSDq7IazMT13gaHFH6D7SDTxE=; b=CaMsWcdGoz3hHIeQCXOjE9ibO76FKaKAa+qSAjyYyjuYaW6dc3xil3Nq7j+Ln0+ct+ p8EQneMLHYSlTH4GUCIQGG3k0P2qVK2wDJ3Xj14lJaps9zd75k2U/kfh7+SFQ9aEg+Y1 vsht6JFPCIUYCZ6iofpRrfWJXGCoI7b0fkuz+LV0qV/mmGyCA9yhyI05ahEmIIyyzwd1 TPD5zzGXIlZ+fqYsvw0T4DYHCsVdhAhSG7pgE5HBLPshYxr5OXYt9SeE1ej1Ou956hzf NSwMsLo6xFBWyruYOPRFTxddY72oBqQ7iju45UAalbKpZDZx4lVEyLBOGjo8UCs83sWo XH4w== MIME-Version: 1.0 X-Received: by 10.180.73.143 with SMTP id l15mr18534214wiv.24.1421522517364; Sat, 17 Jan 2015 11:21:57 -0800 (PST) Received: by 10.216.37.68 with HTTP; Sat, 17 Jan 2015 11:21:57 -0800 (PST) In-Reply-To: <6335518.Tis0CbBHTO@ralph.baldwin.cx> References: <1410203348.1343.1.camel@bruno> <6335518.Tis0CbBHTO@ralph.baldwin.cx> Date: Sat, 17 Jan 2015 12:21:57 -0700 Message-ID: Subject: Re: ixgbe(4) spin lock held too long From: Jason Wolfe To: John Baldwin , freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 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, 17 Jan 2015 19:21:59 -0000 On Mon, Dec 15, 2014 at 9:23 AM, John Baldwin wrote: > On Wednesday, December 10, 2014 12:47:02 PM Jason Wolfe wrote: >> John, >> >> So apparently the concurrent timer scheduling was not fixed, though it >> does seem rarer. We had about 2 weeks of stability, then last night >> we had a crash on a machine with the 4 KTR options listed in the prior >> email. I'm not sure if this is relevant, but the only request for the >> tcp lock that was 'blocked' in the ktrdump (38k entries) happened just >> before the persist timer was armed: >> >> 37898 3 23540056055651738 KTRGRAPH group:"thread", id:"swi4: clock >> tid 100012", state:"spinning", attributes: lockname:"tcp" >> 34794 0 23540056027080726 KTRGRAPH group:"thread", id:"irq278: >> ix0:que 0 tid 100059", state:"blocked", attributes: prio:8, >> wmesg:"(null)", lockname:"tcp" > > I was hoping to see when the rexmit timer was scheduled, but it isn't > mentioned at all in the ktrdump (granted, it only covers ~125 milliseconds). > The line at 37897 is the only one that mentions a timer for this connection. > The dump doesn't include when either timer was scheduled. One thing that you > can tell from the schedgraph (and from above) is that some other thread was > accessing this connection's TCB at the same time as the persist timer spun for > 2 microseconds on the lock before it was able to run, so something did frob > the state just before this ran. However, all the threads that were running at > the time were either idle or in the process of switching out. > >> 32909 1 23540056008857406 KTRGRAPH group:"thread", id:"swi4: clock >> tid 100010", state:"spinning", attributes: lockname:"tcp" >> 29394 4 23540055974204380 KTRGRAPH group:"thread", id:"irq282: >> ix0:que 4 tid 100067", state:"spinning", attributes: lockname:"tcp" >> 29390 1 23540055974198218 KTRGRAPH group:"thread", id:"irq279: >> ix0:que 1 tid 100061", state:"spinning", attributes: lockname:"tcp" >> 7130 0 23540055791854144 KTRGRAPH group:"thread", id:"irq278: >> ix0:que 0 tid 100059", state:"spinning", attributes: lockname:"tcp" >> 5558 5 23540055779687890 KTRGRAPH group:"thread", id:"squid tid >> 100207", state:"spinning", attributes: lockname:"tcp" >> 5306 1 23540055776901006 KTRGRAPH group:"thread", id:"irq279: >> ix0:que 1 tid 100061", state:"spinning", attributes: lockname:"tcp" >> >> panic: tcp_setpersist: retransmit pending >> >> (kgdb) bt >> #0 doadump (textdump=1) at pcpu.h:219 >> #1 0xffffffff806fcb11 in kern_reboot (howto=260) at >> /usr/src/sys/kern/kern_shutdown.c:452 >> #2 0xffffffff806fce74 in panic (fmt=) at >> /usr/src/sys/kern/kern_shutdown.c:759 >> #3 0xffffffff8084c853 in tcp_setpersist (tp=) at >> /usr/src/sys/netinet/tcp_output.c:1718 >> #4 0xffffffff80854856 in tcp_timer_persist (xtp=0xfffff8003e58e800) >> at /usr/src/sys/netinet/tcp_timer.c:518 >> #5 0xffffffff8070faeb in softclock_call_cc (c=0xfffff8003e58eac0, >> cc=0xffffffff8126ce00, direct=0) >> at /usr/src/sys/kern/kern_timeout.c:682 >> #6 0xffffffff8070feb4 in softclock (arg=) at >> /usr/src/sys/kern/kern_timeout.c:810 >> >> Jason >> >> On Tue, Dec 2, 2014 at 1:18 PM, Jason Wolfe wrote: >> > So we've resolved some of our other issues, including the concurrent >> > retrans/persist timer scheduling we saw with >> > net.inet.tcp.per_cpu_timers on. Seems it may have been fixed by >> > disabling flowdirector in ixgbe as Adriann mentioned. Running on >> > 10.1-STABLE from 11/20 (kern.osreldate: 1001502), we are still seeing >> > the spinlock held too long panic though. I have a kernel compiled >> > with these options, and we hit it: >> > >> > options KTR >> > options KTR_COMPILE=(KTR_CALLOUT|KTR_SCHED) >> > options KTR_MASK=(KTR_CALLOUT|KTR_SCHED) >> > options KTR_ENTRIES=131072 >> > >> > I had to grab the last 30000 to see actions other than the statclock >> > entries on the ix queues, if you look at the last 2500 lines or so you >> > can see the last callouts happening. > > I did look at the > ktrdump via schedgraph and it is definitely true that several threads are all > blocked on the callout lock: > > 62185 5 19987364517280198 KTRGRAPH group:"thread", id:"pagedaemon tid > 100096", state:"spinning", attributes: lockname:"callout" > 62184 2 19987364505968920 KTRGRAPH group:"thread", id:"irq280: ix0:que 2 > tid 100063", state:"spinning", attributes: lockname:"callout" > 62178 4 19987364504400868 KTRGRAPH group:"thread", id:"irq282: ix0:que 4 > tid 100067", state:"spinning", attributes: lockname:"callout" > 62172 1 19987364504141702 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 > tid 100061", state:"spinning", attributes: lockname:"callout" > 62166 3 19987364503806636 KTRGRAPH group:"thread", id:"irq281: ix0:que 3 > tid 100065", state:"spinning", attributes: lockname:"callout" > > In fact, the only CPU not spinning on this lock is CPU 0. According to > ktrdump, it was running the idle thread. That said, the ktrdump also claims > that these threads started running callouts (ones that timeout sleeps > like msleep(..., hz)) (which is odd because it didn't log a "running" event > when it got the lock): > > 65919 1 19987382901783634 callout 0xffffffff81253030 finished > 65917 1 19987382901782106 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 > tid 100061", point:"wokeup", attributes: linkedto:"swapper tid 100000" > 65915 1 19987382901775874 callout 0xffffffff81253030 func > 0xffffffff8073f9e0 arg 0xffffffff81252ca0 > 64142 1 19987373824962362 callout 0xfffff801e5394850 finished > 64140 1 19987373824961286 KTRGRAPH group:"thread", id:"irq279: ix0:que 1 > tid 100061", point:"wokeup", attributes: linkedto:"sendmail tid 100167" > 64138 1 19987373824960070 callout 0xfffff801e5394850 func > 0xffffffff8073f9e0 arg 0xfffff801e53944c0 > 62721 4 19987366581196864 callout 0xfffff80022426850 finished > 62719 4 19987366581189888 KTRGRAPH group:"thread", id:"irq282: ix0:que 4 > tid 100067", point:"wokeup", attributes: linkedto:"named tid 100158" > 62717 4 19987366581189192 callout 0xfffff80022426850 func > 0xffffffff8073f9e0 arg 0xfffff800224264c0 > 62680 2 19987366404396696 callout 0xfffff800220add10 finished > ... > > So these aren't TCP timers, but td_slpcallout timers. Those are already > scheduled on multiple CPUs. Maybe we can try moving those all to zero > instead: > > Index: subr_sleepqueue.c > =================================================================== > --- subr_sleepqueue.c (revision 275806) > +++ subr_sleepqueue.c (working copy) > @@ -382,8 +382,8 @@ sleepq_set_timeout_sbt(void *wchan, sbintime_t sbt > MPASS(TD_ON_SLEEPQ(td)); > MPASS(td->td_sleepqueue == NULL); > MPASS(wchan != NULL); > - callout_reset_sbt_on(&td->td_slpcallout, sbt, pr, > - sleepq_timeout, td, PCPU_GET(cpuid), flags | C_DIRECT_EXEC); > + callout_reset_sbt(&td->td_slpcallout, sbt, pr, > + sleepq_timeout, td, flags | C_DIRECT_EXEC); > } > > /* > > > -- > John Baldwin Just to round this thread out for anyone that comes around hunting for similar problems.. it was found to be an issues in the td_slpcallout timers. HPS later came to the same conclusions based on some issues he was having, and produced a patch that went into current a few days ago: https://svnweb.freebsd.org/base?view=revision&revision=277213 Thanks to both for the time/work. Jason