From owner-freebsd-net@FreeBSD.ORG Sun Mar 11 02:01:53 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 460D0106566C for ; Sun, 11 Mar 2012 02:01:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0A4488FC08 for ; Sun, 11 Mar 2012 02:01:52 +0000 (UTC) Received: by dald2 with SMTP id d2so3691526dal.13 for ; Sat, 10 Mar 2012 18:01:52 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1tY9bC3GIfDZ9E+8ljMze31gkiLZyeSinsT/PHKQJQ0=; b=Ftei6N+1XvaIC5t3yc8Pnnnstm4//heDbvL5JlvfCuK5HUV3Kc/iv0jf3U/qmJ0GCK l4z1Q/OXCgt6/sVdGFDFPNCMZmWBFVU78aqJMeJrB8SoBylUQiaBGCxmu/zPVLzhAu7Q x1QGfO0McyNpE2HsmePgpIuJEIuovVgOzaVXmAa8vqCCVJNIl1Ck297zExrXIwMTaX+Z AoLgxL0WBfFyWuty2DXgO3d997+JAdUHH1/BpyvHMTXtim1pBpuJkLrHYB9cTSP81AQV FJpTE2KCm3m52jJ/naUsBGfz9qu2C0+6GY+o5ol997hZgOcOQrBJfplFW/HKh67lTkCJ FesA== MIME-Version: 1.0 Received: by 10.68.191.168 with SMTP id gz8mr12341910pbc.37.1331431312637; Sat, 10 Mar 2012 18:01:52 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Sat, 10 Mar 2012 18:01:52 -0800 (PST) In-Reply-To: <4F5B2E0E.10201@gmail.com> References: <4F5B2E0E.10201@gmail.com> Date: Sat, 10 Mar 2012 18:01:52 -0800 X-Google-Sender-Auth: msQaDDIhuZn36q5V5_MzQiZoUHM Message-ID: From: Adrian Chadd To: Hooman Fazaeli Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Jason Wolfe Subject: Re: Intel 82574L interface wedging - em7.3.2/8.2-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 02:01:53 -0000 On 10 March 2012 02:33, Hooman Fazaeli wrote: > Dear Jason > > With a link_irq of 4, I still guess your problem is snd_buf filling up > during > a temporary link_loss (see: > http://lists.freebsd.org/pipermail/freebsd-net/2011-November/030424.html). > > I use a patched version of e1000 which addresses this issue and > works good for me but it is based on 7.2.3 and I have just tested in > on 7.3-RELEASE. Are you able to post the patch here? Maybe Jack can look at what's going on and apply it to the latest intel ethernet driver. Adrian From owner-freebsd-net@FreeBSD.ORG Sun Mar 11 06:50:13 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B61A0106564A for ; Sun, 11 Mar 2012 06:50:13 +0000 (UTC) (envelope-from bagadeh@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 691FB8FC18 for ; Sun, 11 Mar 2012 06:50:13 +0000 (UTC) Received: by vcmm1 with SMTP id m1so3700327vcm.13 for ; Sat, 10 Mar 2012 22:50:12 -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=Rqc8Sv1RnextNeEmFlcmAq/mIQlugNL0aoXpDikwGEg=; b=Q7wXg8Tl3zvVUJvh5/TLOpi/o2uQAFXdnz4VkccgK/weRuZyChYsggdcppuXTw/u0i ygu1Ub3mVX31zhT0Rikpvrtngsw855isKDxvzUuS1+gpFVc8nrJc6bI0taJPWhjmuGOt tpjDQ7eyeLKHB1S3iuecd4WvPyD5CWbAtqX8XWBbLB7MnSW2CRdqyZ+lOrvJw5scBpiA FFPFUpU+yN14Ji8uNOlNonYYaEOxnduk/Uyfp81F9cfmT4cjKdBwgOdXiu2oZnDDrkZM nJk9Qfj1DRlQbUuj+pu/DtSlQJmADqgqts7rmS807yZYUJsKg8NYGIuvfPOoQiy7636f 4kcA== MIME-Version: 1.0 Received: by 10.52.90.178 with SMTP id bx18mr11308223vdb.123.1331448612807; Sat, 10 Mar 2012 22:50:12 -0800 (PST) Received: by 10.220.133.77 with HTTP; Sat, 10 Mar 2012 22:50:12 -0800 (PST) In-Reply-To: <20120306074655.GA71641@server.vk2pj.dyndns.org> References: <20120305084359.GA56606@server.vk2pj.dyndns.org> <20120305222811.GA64183@server.vk2pj.dyndns.org> <20120306074655.GA71641@server.vk2pj.dyndns.org> Date: Sun, 11 Mar 2012 10:20:12 +0330 Message-ID: From: h bagade To: Peter Jeremy Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net Subject: Re: problem with vlan interfaces tagging/untagging in a simulated switch box X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 06:50:13 -0000 let me explain my problem with this type of topology when I want to simulate a switch like cisco eth1 -+ --- bridge1 --- vlan9 --+-- eth0 --- trunk0 | eth2 -+ --- bridge2 --- vlan8 --+ On 3/6/12, Peter Jeremy wrote: > On 2012-Mar-06 09:15:57 +0330, h bagade wrote: >>On 3/6/12, Peter Jeremy wrote: >>> The following example diagram shows 3 distinct packet flows: >>> - packets tagged 5 in trunk1 and 6 in trunk0 >>> - packets tagged 7 in trunk1 and 9 in trunk0 >>> - packets tagged 8 in trunk0 and 10 in trunk2 >>> >>> +-- vlan5 --- bridge1 --- vlan6 --+ >>> | | >>> trunk1 --- eth1 -+- vlan7 --- bridge2 --- vlan9 --+-- eth0 --- trunk0 >>> | >>> bridge3 --- vlan8 --+ >>> | >>> trunk2 -- eth2 --- vlan10 >>> >>I've described the function of Cisco switches in vlan >>tagging/untagging. > > Real switches typically have everything tagged internally, with the > native VLAN tags added/removed at the ingress/egress ports. This > simplifies the internal switch logic (at the expense of meaning that > tags have to be consistent across all trunks). > > FreeBSD works differently. Packets are _untagged_ internally and you > need a separate bridge(4) device for each broadcast domain (vlan). > >> In your topology, packets should be tagged when >>recieved on real interfaces to be send out to vlan interfaces. > > Packets are never tagged by real interfaces and always have tags > added/removed by vlan devices. > >> It >>would be fine when two trunks are communicating because on both side >>packets are tagged. But as I mentioned before, Cisco switches receive >>packets on an interface untagged and then sending packets tagged out >>of trunk port, based on which interface it receives, > > You can connect a physical interface (ethX) directly to a bridge device > to access untagged packets. Note that I'm not sure whether it is safe > to access the native VLAN in a trunk in this way. > > To continue the above example, > ifconfig bridge1 addm eth3 > would result in packets arriving on eth3 leaving tagged as vlan 5 in > trunk1, vlan 6 in trunk0 and vice versa. > > -- > Peter Jeremy > From owner-freebsd-net@FreeBSD.ORG Sun Mar 11 07:42:12 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4D89106564A for ; Sun, 11 Mar 2012 07:42:12 +0000 (UTC) (envelope-from bagadeh@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 86FB38FC16 for ; Sun, 11 Mar 2012 07:42:12 +0000 (UTC) Received: by vcmm1 with SMTP id m1so3723803vcm.13 for ; Sat, 10 Mar 2012 23:42:11 -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=xFjbI6m34KfjK5xTlHy+XLlYSSfb54qksDFiehm1J1M=; b=pR22YMxnWU+VzXHATFmGnj8ezl+X5TbJ2M2pGgzvtF7rS7I3lIYNJ6a9hcmyjTUIfs klxdXbFPjZ5/C3z0KdQF9BFdHD/TIJ82O372GNh4rBv4gGfCWkHqqa1xJQHStWHTBDg1 m9HvsQhGrncD20RrvJ0CP3D71xzdM39P/bxVC3oCGoSY8P+ATgBmZFOEXkx+tC7wqu/y M1eWhmJu1ocnpipBww+kg6yG+NWmdVqBvqB4iB/qw+FLsJwwpQpXSPBjBpALEGB5NSeP Ke95v1t+LzQcLNJ1u3CKTTnM7Wh4qXG3j7i8mMR3cup6djn+uO85QQVPJcebYQfqyPul CZKg== MIME-Version: 1.0 Received: by 10.52.90.178 with SMTP id bx18mr11386095vdb.123.1331451731839; Sat, 10 Mar 2012 23:42:11 -0800 (PST) Received: by 10.220.133.77 with HTTP; Sat, 10 Mar 2012 23:42:11 -0800 (PST) In-Reply-To: References: <20120305084359.GA56606@server.vk2pj.dyndns.org> <20120305222811.GA64183@server.vk2pj.dyndns.org> <20120306074655.GA71641@server.vk2pj.dyndns.org> Date: Sun, 11 Mar 2012 11:12:11 +0330 Message-ID: From: h bagade To: Peter Jeremy Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net Subject: Re: problem with vlan interfaces tagging/untagging in a simulated switch box X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 07:42:12 -0000 Sorry my last post was sent out suddenly by pressing a key, I don't yet know even which one! the compelete post is written down here. let me explain my problem with this type of topology when I want to simulate a switch like cisco eth0 -+ | eth1 -+ --- bridge1 --- vlan9 --+-- eth4 ----- outside of switch | | eth2 -+ --- bridge2 --- vlan8 --+ | | eth3 -+ ------------ bridge3 -----------+ In above example, eth0 and eth1 are vlan9 ports which means that traffic coming from these ports are sent out eth4(trunk port) with vlan9 tag. the same for eth2 which is vlan8 port. eth3 is the port with vlan id equal to native vlan on eth4. the native vlans are those vlans which would not tag across trunk port, so traffic comes from eth3 pass the trunk port(eth4) untagged. the scenario works fine without eth3! it means that when eth3 is excluded from the topology, the other ports are tagged the proper vlan tag when going through eth4. As eth3 is added the all traffic receives on eth4 are passed to eth3 with out cheching vlan tags! this is due to bridge between eth3 and eth4! but I don't know how to correct the scenario that eth3 packets to be not tagged through eth4 without disturbing the function of other parts! I would be very glad if someone help me on this important problem I've encountered. On 3/11/12, h bagade wrote: > let me explain my problem with this type of topology when I want to > simulate a switch like cisco > > > > eth1 -+ --- bridge1 --- vlan9 --+-- eth0 --- trunk0 > | > eth2 -+ --- bridge2 --- vlan8 --+ > > On 3/6/12, Peter Jeremy wrote: >> On 2012-Mar-06 09:15:57 +0330, h bagade wrote: >>>On 3/6/12, Peter Jeremy wrote: >>>> The following example diagram shows 3 distinct packet flows: >>>> - packets tagged 5 in trunk1 and 6 in trunk0 >>>> - packets tagged 7 in trunk1 and 9 in trunk0 >>>> - packets tagged 8 in trunk0 and 10 in trunk2 >>>> >>>> +-- vlan5 --- bridge1 --- vlan6 --+ >>>> | | >>>> trunk1 --- eth1 -+- vlan7 --- bridge2 --- vlan9 --+-- eth0 --- trunk0 >>>> | >>>> bridge3 --- vlan8 --+ >>>> | >>>> trunk2 -- eth2 --- vlan10 >>>> >>>I've described the function of Cisco switches in vlan >>>tagging/untagging. >> >> Real switches typically have everything tagged internally, with the >> native VLAN tags added/removed at the ingress/egress ports. This >> simplifies the internal switch logic (at the expense of meaning that >> tags have to be consistent across all trunks). >> >> FreeBSD works differently. Packets are _untagged_ internally and you >> need a separate bridge(4) device for each broadcast domain (vlan). >> >>> In your topology, packets should be tagged when >>>recieved on real interfaces to be send out to vlan interfaces. >> >> Packets are never tagged by real interfaces and always have tags >> added/removed by vlan devices. >> >>> It >>>would be fine when two trunks are communicating because on both side >>>packets are tagged. But as I mentioned before, Cisco switches receive >>>packets on an interface untagged and then sending packets tagged out >>>of trunk port, based on which interface it receives, >> >> You can connect a physical interface (ethX) directly to a bridge device >> to access untagged packets. Note that I'm not sure whether it is safe >> to access the native VLAN in a trunk in this way. >> >> To continue the above example, >> ifconfig bridge1 addm eth3 >> would result in packets arriving on eth3 leaving tagged as vlan 5 in >> trunk1, vlan 6 in trunk0 and vice versa. >> >> -- >> Peter Jeremy >> > From owner-freebsd-net@FreeBSD.ORG Sun Mar 11 07:47:22 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A8B6106566C; Sun, 11 Mar 2012 07:47:22 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id C2EE08FC08; Sun, 11 Mar 2012 07:47:21 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so1773964wib.13 for ; Sat, 10 Mar 2012 23:47:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0Nj5Gl9oQTjesHUCBfmLpbYfMDtUuqexM1R0WhRJEKU=; b=I/SGSHQEv1QwkWH2Qb6hWiROIKnaDX1Ll+UOuejBjOlUzbFLJrt+LIJMvaDXNqEUFf 8oiXIKuyfCHUFlf6IT1FG3MvE6efOBsQvnC6LeFBtPG5Uj6qwN7lFHHQTVXxNJt6yDk8 I+fs+oEebhJ9mEgKqczxMnoG/3viaHpu003c1eK9Ak27CYorEC1yL/CDWqRLOwXGVsYU fnMq0ScCwknnPtUJi2k373/9b9MQaj2uvkGcYZd+JIQHOLXAY5Ig+9A56b64u4Wooiu9 PKq6B0mCuRdn+7Wv3uoYHezwP1B4v/O6Exw06Q493kosuXMlzwxwyJLgevRSAST9N42A Rf5Q== Received: by 10.180.99.100 with SMTP id ep4mr17883367wib.7.1331452035136; Sat, 10 Mar 2012 23:47:15 -0800 (PST) Received: from [127.0.0.1] ([213.217.59.99]) by mx.google.com with ESMTPS id w10sm38457687wiy.3.2012.03.10.23.47.13 (version=SSLv3 cipher=OTHER); Sat, 10 Mar 2012 23:47:14 -0800 (PST) Message-ID: <4F5C587B.6010004@gmail.com> Date: Sun, 11 Mar 2012 11:17:07 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Adrian Chadd References: <4F5B2E0E.10201@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Jason Wolfe Subject: Re: Intel 82574L interface wedging - em7.3.2/8.2-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 07:47:22 -0000 On 3/11/2012 5:31 AM, Adrian Chadd wrote: > Are you able to post the patch here? > Maybe Jack can look at what's going on and apply it to the latest > intel ethernet driver. > > > Adrian > Below is the patch for if_em.c (7.2.3). It simply checks driver's queue status when the link state changes (inactive -> active) and start transmit task if queue(s) are not empty. It also contains stuff I have added to compile on 7 plus some code for test and diagnostics. Hope it helps. --- if_em.c.orig 2011-10-27 14:47:20.000000000 +0330 +++ if_em.c 2011-11-19 16:11:54.000000000 +0330 @@ -85,6 +85,14 @@ #include "e1000_82571.h" #include "if_em.h" +#if !defined(DISABLE_FIXUPS) && __FreeBSD_version < 800000 +static __inline int +pci_find_cap(device_t dev, int capability, int *capreg) +{ + return (PCI_FIND_EXTCAP(device_get_parent(dev), dev, capability, capreg)); +} +#endif + /********************************************************************* * Set this to one to display debug statistics *********************************************************************/ @@ -93,7 +101,11 @@ /********************************************************************* * Driver version: *********************************************************************/ +#ifdef PKG_VERSION +char em_driver_version[] = "version 7.2.3 (ifdrivers-" PKG_VERSION ")"; +#else char em_driver_version[] = "7.2.3"; +#endif /********************************************************************* * PCI Device ID Table @@ -293,6 +305,11 @@ static poll_handler_t em_poll; #endif /* POLLING */ +#ifndef DISABLE_FIXUPS +static int em_sysctl_snd_ifq_len(SYSCTL_HANDLER_ARGS); +static int em_sysctl_snd_ifq_drv_len(SYSCTL_HANDLER_ARGS); +#endif + /********************************************************************* * FreeBSD Device Interface Entry Points *********************************************************************/ @@ -399,6 +416,23 @@ /* Global used in WOL setup with multiport cards */ static int global_quad_port_a = 0; +#ifndef DISABLE_FIXUPS +static int enable_hang_fixup = 1; +TUNABLE_INT("hw.em.enable_hang_fixup", &enable_hang_fixup); +SYSCTL_INT(_hw_em, OID_AUTO, enable_hang_fixup, CTLFLAG_RW, &enable_hang_fixup, 0, + "Enable rx/tx hang fixup"); + +static int em_regard_tx_link_status = 1; +TUNABLE_INT("hw.em.regard_tx_link_status", &em_regard_tx_link_status); +SYSCTL_INT(_hw_em, OID_AUTO, regard_tx_link_status, CTLFLAG_RW, &em_regard_tx_link_status, 0, + "Regard tx link status"); + +static int link_master_slave = e1000_ms_hw_default; +TUNABLE_INT("hw.em.link_master_slave", &link_master_slave); +SYSCTL_INT(_hw_em, OID_AUTO, link_master_slave, CTLFLAG_RW, &link_master_slave, + 0, "Link negotiation master/slave type"); +#endif + /********************************************************************* * Device identification routine * @@ -411,7 +445,11 @@ static int em_probe(device_t dev) { +#ifdef PKG_VERSION + char adapter_name[sizeof(em_driver_version) + 60]; +#else char adapter_name[60]; +#endif u16 pci_vendor_id = 0; u16 pci_device_id = 0; u16 pci_subvendor_id = 0; @@ -864,7 +902,11 @@ int err = 0, enq = 0; if ((ifp->if_drv_flags & (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) != +#ifndef DISABLE_FIXUPS IFF_DRV_RUNNING || adapter->link_active == 0) { +#else + IFF_DRV_RUNNING || (em_regard_tx_link_status && !adapter->link_active)) { +#endif if (m != NULL) err = drbr_enqueue(ifp, txr->br, m); return (err); @@ -962,9 +1004,17 @@ if ((ifp->if_drv_flags & (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) != IFF_DRV_RUNNING) return; +#ifdef _TEST + if (adapter->forced_link_status == 0) + return; +#endif +#ifdef DISABLE_FIXUPS if (!adapter->link_active) +#else + if (em_regard_tx_link_status && !adapter->link_active) return; +#endif while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { /* Call cleanup if number of TX descriptors low */ @@ -977,6 +1027,17 @@ IFQ_DRV_DEQUEUE(&ifp->if_snd, m_head); if (m_head == NULL) break; +#ifdef _TEST + if (adapter->forced_xmit_error == ENOMEM) { + ifp->if_drv_flags |= IFF_DRV_OACTIVE; + IFQ_DRV_PREPEND(&ifp->if_snd, m_head); + break; + } else if (adapter->forced_xmit_error != 0) { + m_freem(m_head); + m_head = NULL; + break; + } else +#endif /* * Encapsulation can modify our pointer, and or make it * NULL on failure. In that event, we can't requeue. @@ -1141,6 +1202,10 @@ adapter->hw.phy.reset_disable = FALSE; /* Check SOL/IDER usage */ EM_CORE_LOCK(adapter); +#ifndef DISABLE_FIXUPS + if (adapter->hw.phy.media_type == e1000_media_type_copper) + adapter->hw.phy.ms_type = link_master_slave; +#endif if (e1000_check_reset_block(&adapter->hw)) { EM_CORE_UNLOCK(adapter); device_printf(adapter->dev, "Media change is" @@ -1283,7 +1348,9 @@ INIT_DEBUGOUT1("em_init: pba=%dK",pba); E1000_WRITE_REG(&adapter->hw, E1000_PBA, pba); - +#ifndef DISABLE_FIXUPS + device_printf(adapter->dev, "%dK rx packet buffer\n", (int)pba); +#endif /* Get the latest mac address, User can use a LAA */ bcopy(IF_LLADDR(adapter->ifp), adapter->hw.mac.addr, ETHER_ADDR_LEN); @@ -1395,6 +1462,10 @@ /* Don't reset the phy next time init gets called */ adapter->hw.phy.reset_disable = TRUE; +#ifdef _TEST + adapter->forced_link_status = -1; + adapter->forced_xmit_error = 0; +#endif } static void @@ -1414,7 +1485,11 @@ * Legacy polling routine: note this only works with single queue * *********************************************************************/ +#if !defined(DISABLE_FIXUPS) && __FreeBSD_version < 800000 +static void +#else static int +#endif em_poll(struct ifnet *ifp, enum poll_cmd cmd, int count) { struct adapter *adapter = ifp->if_softc; @@ -1426,7 +1501,11 @@ EM_CORE_LOCK(adapter); if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) { EM_CORE_UNLOCK(adapter); +#if !defined(DISABLE_FIXUPS) && __FreeBSD_version < 800000 + return; +#else return (0); +#endif } if (cmd == POLL_AND_CHECK_STATUS) { @@ -1452,8 +1531,11 @@ em_start_locked(ifp, txr); #endif EM_TX_UNLOCK(txr); - +#if !defined(DISABLE_FIXUPS) && __FreeBSD_version < 800000 + return; +#else return (rx_done); +#endif } #endif /* DEVICE_POLLING */ @@ -1525,7 +1607,11 @@ em_start_locked(ifp, txr); #endif EM_TX_UNLOCK(txr); +#ifdef DISABLE_FIXUPS if (more || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) { +#else + if (more) { +#endif taskqueue_enqueue(adapter->tq, &adapter->que_task); return; } @@ -1652,6 +1738,29 @@ EM_CORE_LOCK(adapter); callout_stop(&adapter->timer); em_update_link_status(adapter); +#ifndef DISABLE_FIXUPS + /* + * Kick off transmission if link has become active and tx + * queues are not empty. + */ + if (adapter->link_active && adapter->msix > 1) { +# ifdef EM_MULTIQUEUE + for (int i = 0; i < adapter->num_queues; i++) { + struct tx_ring = adapter->tx_rings + i; + if (!drbr_empty(ifp, txr->br)) { + ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; + taskqueue_enqueue(txr->tq, &txr->tx_task); + } + } +# else + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { + struct tx_ring *txr = adapter->tx_rings; + ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; + taskqueue_enqueue(txr->tq, &txr->tx_task); + } + } +# endif +#endif callout_reset(&adapter->timer, hz, em_local_timer, adapter); E1000_WRITE_REG(&adapter->hw, E1000_IMS, EM_MSIX_LINK | E1000_IMS_LSC); @@ -2212,7 +2321,41 @@ if ((adapter->hw.mac.type == e1000_82571) && e1000_get_laa_state_82571(&adapter->hw)) e1000_rar_set(&adapter->hw, adapter->hw.mac.addr, 0); +#ifdef _TEST + adapter->local_timer_runs++; +#endif +#ifndef DISABLE_FIXUPS + if (enable_hang_fixup) { + struct ifnet *ifp = adapter->ifp; + struct ifaltq *ifsnd = &ifp->if_snd; + for (int i = 0; i < adapter->num_queues; i++) { + struct rx_ring *rxr = adapter->rx_rings + i; + struct tx_ring *txr = adapter->tx_rings + i; + bool rxhung = FALSE; + if (rxr->next_to_check == rxr->next_to_refresh) { + rxhung = TRUE; + adapter->rx_hangs++; + if (adapter->msix > 1) + taskqueue_enqueue(rxr->tq, + &rxr->rx_task); + else + taskqueue_enqueue(adapter->tq, + &adapter->que_task); + } + if (ifsnd->ifq_len * 2 >= ifsnd->ifq_maxlen) { + adapter->tx_hangs++; + ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; + if (adapter->msix > 1) + taskqueue_enqueue(txr->tq, + &txr->tx_task); + else if (!rxhung) + taskqueue_enqueue(adapter->tq, + &adapter->que_task); + } + } + } +#endif /* Mask to use in the irq trigger */ if (adapter->msix_mem) trigger = rxr->ims; /* RX for 82574 */ @@ -2311,6 +2454,9 @@ ((adapter->link_duplex == FULL_DUPLEX) ? "Full Duplex" : "Half Duplex")); adapter->link_active = 1; +#ifndef DISABLE_FIXUPS + adapter->link_toggles++; +#endif adapter->smartspeed = 0; ifp->if_baudrate = adapter->link_speed * 1000000; if_link_state_change(ifp, LINK_STATE_UP); @@ -2320,6 +2466,9 @@ if (bootverbose) device_printf(dev, "Link is Down\n"); adapter->link_active = 0; +#ifndef DISABLE_FIXUPS + adapter->link_toggles++; +#endif /* Link down, disable watchdog */ for (int i = 0; i < adapter->num_queues; i++, txr++) txr->queue_status = EM_QUEUE_IDLE; @@ -3766,7 +3915,7 @@ * If we have a minimum free, clear IFF_DRV_OACTIVE * to tell the stack that it is OK to send packets. */ - if (txr->tx_avail > EM_MAX_SCATTER) + if (txr->tx_avail >= EM_MAX_SCATTER) ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; /* Disable watchdog if all clean */ @@ -5131,7 +5280,36 @@ SYSCTL_ADD_ULONG(ctx, child, OID_AUTO, "watchdog_timeouts", CTLFLAG_RD, &adapter->watchdog_events, "Watchdog timeouts"); - +#ifndef DISABLE_FIXUPS + SYSCTL_ADD_ULONG(ctx, child, OID_AUTO, "link_toggles", + CTLFLAG_RD, &adapter->link_toggles, + "Number of link status changes"); + SYSCTL_ADD_ULONG(ctx, child, OID_AUTO, "rx_hangs", + CTLFLAG_RD, &adapter->rx_hangs, + "Number of rx hangs"); + SYSCTL_ADD_ULONG(ctx, child, OID_AUTO, "tx_hangs", + CTLFLAG_RD, &adapter->tx_hangs, + "Number of tx hangs"); + SYSCTL_ADD_PROC(ctx, child, OID_AUTO, "snd_ifq_len", + CTLTYPE_INT | CTLFLAG_RD, adapter->ifp, + sizeof(adapter->ifp), em_sysctl_snd_ifq_len, "I", + "if_snd queue length"); + SYSCTL_ADD_PROC(ctx, child, OID_AUTO, "snd_ifq_drv_len", + CTLTYPE_INT | CTLFLAG_RD, adapter->ifp, + sizeof(adapter->ifp), em_sysctl_snd_ifq_drv_len, "I", + "if_snd drv queue length"); +#endif +#ifdef _TEST + SYSCTL_ADD_ULONG(ctx, child, OID_AUTO, "local_timer_runs", + CTLFLAG_RD, &adapter->local_timer_runs, + "Local timer runs"); + SYSCTL_ADD_INT(ctx, child, OID_AUTO, "forced_link_status", + CTLFLAG_RW|CTLTYPE_INT, &adapter->forced_link_status, + 0, "Forced link status"); + SYSCTL_ADD_INT(ctx, child, OID_AUTO, "forced_xmit_error", + CTLFLAG_RW|CTLTYPE_INT, &adapter->forced_xmit_error, + 0, "Forced xmit error"); +#endif SYSCTL_ADD_PROC(ctx, child, OID_AUTO, "device_control", CTLTYPE_UINT | CTLFLAG_RD, adapter, E1000_CTRL, em_sysctl_reg_handler, "IU", @@ -5553,4 +5731,42 @@ rxr->rx_discarded); device_printf(dev, "RX Next to Check = %d\n", rxr->next_to_check); device_printf(dev, "RX Next to Refresh = %d\n", rxr->next_to_refresh); +#ifndef DISABLE_FIXUPS + device_printf(dev, "Link state: %s\n", + adapter->link_active? "active": "inactive"); +#endif +} + +#ifndef DISABLE_FIXUPS +static int +em_sysctl_snd_ifq_len(SYSCTL_HANDLER_ARGS) +{ + int error; + int v; + struct ifnet *ifp = ((struct ifnet *)oidp->oid_arg1); + + if (ifp == NULL) + return 0; + v = _IF_QLEN(&ifp->if_snd); + error = sysctl_handle_int(oidp, &v, 0, req); + if (error || !req->newptr) + return error; + return 0; } + +static int +em_sysctl_snd_ifq_drv_len(SYSCTL_HANDLER_ARGS) +{ + int error; + int v; + struct ifnet *ifp = ((struct ifnet *)oidp->oid_arg1); + + if (ifp == NULL) + return 0; + v = ifp->if_snd.ifq_drv_len; + error = sysctl_handle_int(oidp, &v, 0, req); + if (error || !req->newptr) + return error; + return 0; +} +#endif From owner-freebsd-net@FreeBSD.ORG Sun Mar 11 09:06:38 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3987510656D2 for ; Sun, 11 Mar 2012 09:06:38 +0000 (UTC) (envelope-from bagadeh@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id EECB78FC1C for ; Sun, 11 Mar 2012 09:06:37 +0000 (UTC) Received: by vcmm1 with SMTP id m1so3764543vcm.13 for ; Sun, 11 Mar 2012 01:06:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Mrw0THeaW+EueNIzTs6NYujx0Yc8B7ONLYJtRjDmWRk=; b=gybvxYa7XTU23b0J7mi6M516MxmcnxVSKKtgfg0GuUCJxBlxIFOOXSSQ7TzBRGam6V PgLLU5cE8BKTkBQxFm/CpqsOS+1mJeJdDyze86p1tpQaNB6ZkKGoyzQDN6e4ykrSKZpF XxwScDybjCk82yqFhFACjVft6Val/EF5/DBeYfYJAkqHe44GqKALe0HGBSgyJL8kRqOM gwtDDq22zC/Vi3ohfqF+xlIJxqKGqPz40tIuTL3KPiTlMHE0UVpY8h387+JKOWSO8t9k Qblqb7tQE8/IolqH0ct2Cvv8FJOHoSb43AEmp7hSukGbD3AE9YARS3CFDuYowy/HkYZJ XWZA== MIME-Version: 1.0 Received: by 10.52.88.103 with SMTP id bf7mr11750039vdb.72.1331456797344; Sun, 11 Mar 2012 01:06:37 -0800 (PST) Received: by 10.220.133.77 with HTTP; Sun, 11 Mar 2012 01:06:36 -0800 (PST) Date: Sun, 11 Mar 2012 12:36:36 +0330 Message-ID: From: h bagade To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1 Subject: STP on netgraph bridge node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 09:06:38 -0000 Hi all, Is there any way to add STP and RSTP protocols to bridge node on netgraph? Should I implement it on the node or it has done before? From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 00:42:21 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52231106566B; Mon, 12 Mar 2012 00:42:21 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 25EFA8FC1D; Mon, 12 Mar 2012 00:42:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2C0gLq6064982; Mon, 12 Mar 2012 00:42:21 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2C0gLGx064978; Mon, 12 Mar 2012 00:42:21 GMT (envelope-from linimon) Date: Mon, 12 Mar 2012 00:42:21 GMT Message-Id: <201203120042.q2C0gLGx064978@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/165903: mbuf leak X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 00:42:21 -0000 Synopsis: mbuf leak Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Mar 12 00:41:50 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=165903 From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 01:03:06 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 054381065672; Mon, 12 Mar 2012 01:03:06 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CB2968FC17; Mon, 12 Mar 2012 01:03:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2C135K4083484; Mon, 12 Mar 2012 01:03:05 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2C135aB083480; Mon, 12 Mar 2012 01:03:05 GMT (envelope-from linimon) Date: Mon, 12 Mar 2012 01:03:05 GMT Message-Id: <201203120103.q2C135aB083480@freefall.freebsd.org> To: leschnik@gmail.com, linimon@FreeBSD.org, gnats-admin@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/165955: [lagg]: Lagg failover does not announce the failover to switch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 01:03:06 -0000 Old Synopsis: Fwd: Lagg failover does not announce the failover to switch New Synopsis: [lagg]: Lagg failover does not announce the failover to switch State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Mon Mar 12 01:01:59 UTC 2012 State-Changed-Why: Misfiled followup to kern/156226; content migrated. Responsible-Changed-From-To: gnats-admin->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Mar 12 01:01:59 UTC 2012 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=165955 From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 01:06:21 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BFA1106564A; Mon, 12 Mar 2012 01:06:21 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1D5D98FC1A; Mon, 12 Mar 2012 01:06:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2C16KkN084048; Mon, 12 Mar 2012 01:06:21 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2C16KGj084044; Mon, 12 Mar 2012 01:06:20 GMT (envelope-from linimon) Date: Mon, 12 Mar 2012 01:06:20 GMT Message-Id: <201203120106.q2C16KGj084044@freefall.freebsd.org> To: kes-kes@yandex.ru, linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/165562: [request] add support for Intel i350 in FreeBSD 7.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 01:06:21 -0000 Old Synopsis: no support for Intel i350 in FreeBSD 7.4 New Synopsis: [request] add support for Intel i350 in FreeBSD 7.4 State-Changed-From-To: open->suspended State-Changed-By: linimon State-Changed-When: Mon Mar 12 01:05:17 UTC 2012 State-Changed-Why: mark suspended awaiting patches. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Mar 12 01:05:17 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=165562 From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 05:19:13 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44FDF106564A for ; Mon, 12 Mar 2012 05:19:13 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 149BB8FC0A for ; Mon, 12 Mar 2012 05:19:12 +0000 (UTC) Received: by dald2 with SMTP id d2so5158237dal.13 for ; Sun, 11 Mar 2012 22:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=3/quzGmWoBKFSSLRyfiGtZV2wBSSYAN4x6zR/Ui7gzs=; b=w7OMRBLdWaBrCNNRzjyV3GhHIrZs6lbTsWzz88sfEJXEuXvTL0ldQ2Qu0n0Z0v9YHP ByxMuDcM9iDJ8jJVGJTAwW5sF2KCy0dG4as6qToMpB0dvocLdvS1njZ7H1KHC8vTFv8y 5xSYC5i9mv6ISqLbh2VfXYGFCXtYOBXu93mvkD0zkqWwq83itltk9kJrv6oT3yP08Bm2 tnwCQSut77MgG/hMFGdtpLZw5xijdfMdShL4oYYQU8RnDH3NgWJXa9PLG89uS9hdlWxv rJj521YYVISsT+RG5FqtEbUkIQLm3scvTlUCgMg0kbbJwPOOt6K8l36iBQSn4ZEEc9u5 PGDg== Received: by 10.68.242.197 with SMTP id ws5mr17835496pbc.84.1331529552675; Sun, 11 Mar 2012 22:19:12 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id r9sm2812726pbi.53.2012.03.11.22.19.10 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Mar 2012 22:19:12 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 12 Mar 2012 14:19:07 -0700 From: YongHyeon PYUN Date: Mon, 12 Mar 2012 14:19:07 -0700 To: Andreas Longwitz Message-ID: <20120312211907.GC3671@michelle.cdnetworks.com> References: <4F594856.3030303@incore.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F594856.3030303@incore.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Intel 82550 Pro/100 Ethernet and Microcode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 05:19:13 -0000 On Fri, Mar 09, 2012 at 01:01:26AM +0100, Andreas Longwitz wrote: > Hi, > > recently I installed FreeBSD 8.2 Stable on some older machines with > Intel 82550 and 82550C and found that the loading of microcode with the > parameter link0 in the ifconfig command did not work anymore. The reason > for this is the commit r223608 for if_fxp.c with the comment: > > Disable microcode loading for 82550 and 82550C controllers. Loading > the microcode caused SCB timeouts. > > I do not agree with this motivation and try to explain why. > > Without loading the microcode on 82550(C) there is a problem with > mount_nfs -U server:/bigdisk /mnt > cp /mnt/bigfile bigfile > > NFS with UDP works with 8 KB blocks and the cp hangs after some seconds > and you see SCB messages on the console. The reason is the TCO bug of > the hardware mentioned in rcvbundl.h. This old hardware bug disappears > after loading the microcode. > > All my hardware run without problems in FreeBSD 4.11, loading of > microcode is done by the function fxp_load_ucode(). Later there was > trouble with the loading of microcode, see kern/103332 and kern/118909. > I have posted my solution for the problem to kern/103332 but > unfortunately this PR is not online anymore and so I repeat my > considerations here. > > The difference of the function fxp_load_ucode() of FreeBSD 4.11 and > later versions is that this function in 4.11 has an own private memory > buffer for construction of the microcode message. In later versions > fxp_load_ucode() must use a memory buffer that is shared with other > parts of the driver and these other parts of the driver have problems if > the shared memory buffer was used by fxp_load_ucode() before. Thats the > reason for "Loading microcode caused SCB timeouts". > > Therefore my proposal is to revert r223608 and to clean the used shared > buffer at the end of the function fxp_load_ucode(). The following patch > works for me for years now: > > --- if_fxp.c.orig 2012-01-26 12:43:09.000000000 +0100 > +++ if_fxp.c 2012-03-08 23:41:32.000000000 +0100 > @@ -3085,6 +3081,7 @@ > sc->tunable_int_delay, > uc->bundle_max_offset == 0 ? 0 : sc->tunable_bundle_max); > sc->flags |= FXP_FLAG_UCODE; > + bzero(cbp, (uc->length + 2) * sizeof(uint32_t)); > } Unfortunately this still does not make any difference on i82550C controller(still spews SCB timeouts). By chance, do you have original i82550? Show me the output of 'pciconf -l'. From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 07:26:32 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6841B1065676; Mon, 12 Mar 2012 07:26:32 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3B62B8FC19; Mon, 12 Mar 2012 07:26:32 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2C7QWA6039335; Mon, 12 Mar 2012 07:26:32 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2C7QWoZ039331; Mon, 12 Mar 2012 07:26:32 GMT (envelope-from linimon) Date: Mon, 12 Mar 2012 07:26:32 GMT Message-Id: <201203120726.q2C7QWoZ039331@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/165622: [ndis][panic][patch] Unregistered use of FPU in kernel on amd64 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 07:26:32 -0000 Synopsis: [ndis][panic][patch] Unregistered use of FPU in kernel on amd64 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Mar 12 07:26:21 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=165622 From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 11:07:17 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA937106566C for ; Mon, 12 Mar 2012 11:07:17 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A82078FC19 for ; Mon, 12 Mar 2012 11:07:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2CB7H9J072412 for ; Mon, 12 Mar 2012 11:07:17 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2CB7HWq072410 for freebsd-net@FreeBSD.org; Mon, 12 Mar 2012 11:07:17 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 Mar 2012 11:07:17 GMT Message-Id: <201203121107.q2CB7HWq072410@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 11:07:17 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/165903 net mbuf leak o kern/165879 net [tcp] Syncache syncache.count overflow o kern/165863 net [panic] [netinet] [patch] in_lltable_prefix_free() rac o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o bin/165413 net [netgraph]: ngctl(8) does not work as advertised o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164569 net [msk] [hang] msk network driver cause freeze in FreeBS o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164400 net [ipsec] immediate crash after the start of ipsec proce o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162509 net [re] [panic] Kernel panic may be related to if_re.c (r o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161381 net [re] RTL8169SC - re0: PHY write failed o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160420 net [msk] phy write timeout on HP 5310m o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159795 net [tcp] excessive duplicate ACKs and TCP session freezes o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157429 net [re] Realtek RTL8169 doesn't work with re(4) o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 397 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 14:50:04 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2196A106566C for ; Mon, 12 Mar 2012 14:50:04 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id CED618FC1A for ; Mon, 12 Mar 2012 14:50:03 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 5D6145CFC2; Mon, 12 Mar 2012 15:41:11 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id OG6MknjZTZ-5; Mon, 12 Mar 2012 15:41:09 +0100 (CET) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 6F0095CFBC; Mon, 12 Mar 2012 15:40:55 +0100 (CET) Received: from bsdlo.incore (bsdlo.incore [192.168.0.84]) by mail.incore (Postfix) with ESMTP id 68D6E450AA; Mon, 12 Mar 2012 15:40:55 +0100 (CET) Message-ID: <4F5E0AF7.30302@incore.de> Date: Mon, 12 Mar 2012 15:40:55 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4F594856.3030303@incore.de> <20120312211907.GC3671@michelle.cdnetworks.com> In-Reply-To: <20120312211907.GC3671@michelle.cdnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Intel 82550 Pro/100 Ethernet and Microcode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 14:50:04 -0000 > Unfortunately this still does not make any difference on i82550C > controller(still spews SCB timeouts). By chance, do you have > original i82550? Show me the output of 'pciconf -l'. fxp0@pci0:0:3:0: class=0x020000 card=0x340f8086 chip=0x12298086 rev=0x0d hdr=0x00 fxp1@pci0:0:4:0: class=0x020000 card=0x340f8086 chip=0x12298086 rev=0x0d hdr=0x00 fxp2@pci0:1:9:0: class=0x020000 card=0x10408086 chip=0x12298086 rev=0x0c hdr=0x00 >From if_fxpreg.h: #define FXP_REV_82550 12 #define FXP_REV_82550_C 13 /* 82550 C stepping */ Therefore I think fxp0/fxp1 are 82550C (on motherboard) and fxp2 is original 82550. I have several servers with this constellation and saw SCB timeouts only one time during the last 6 month while debugging with wireshark: fwvpn kernel: fxp0: promiscuous mode enabled fwvpn kernel: fxp0: Microcode loaded, int_delay: 1000 usec bundle_max: 6 fwvpn kernel: fxp0: SCB timeout: 0x80 0x20 0x90 0x1 fwvpn last message repeated 5 times Regards, Andreas Longwitz From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 15:05:27 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE8131065670 for ; Mon, 12 Mar 2012 15:05:27 +0000 (UTC) (envelope-from prvs=1418b75531=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 715748FC08 for ; Mon, 12 Mar 2012 15:05:26 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Mon, 12 Mar 2012 15:05:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50018592972.msg for ; Mon, 12 Mar 2012 15:05:17 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1418b75531=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <18969B34B4EE402986389D5022DCCB35@multiplay.co.uk> From: "Steven Hartland" To: Date: Mon, 12 Mar 2012 15:05:12 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: ixgbe interface micro stalls / slow responses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 15:05:28 -0000 We've got a machine where with an ix interface on 8.2-RELEASE which is seeing intermittent slow responses. It shows as stalls on the console and is visible as high pings on an mtr from a local machine e.g. Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. X.X.X.X 0.0% 181 0.1 117.7 0.1 2665. 314.8 We've tried updating from 2.3.10 release driver + alias fix to 2.4.5 (the latest from 8.3) but still the behavour is the same. If we do a trace to an igb on the same machine everything is clean. Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 10.10.10.64 0.0% 136 0.1 0.2 0.1 12.5 1.1 We are seeing "RX Descriptors exceed system mbuf max, using default instead!" on boot with the latest driver but the fix listed in the readme has no effect, as in sysctl.conf we have kern.ipc.nmbclusters=524288 kern.ipc.nmbjumbop=262144 Nothing looks out of the ordinary by there's definitely a problem there somewhere, any ideas? Detailed info which may be use below. >From dmeg:- ix0: port 0x2000-0x201f mem 0xd8400000-0xd847ffff,0xd8480000-0xd8483fff irq 52 at device 0.0 on pci5 ix0: Using MSIX interrupts with 9 vectors ix0: RX Descriptors exceed system mbuf max, using default instead! ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: Ethernet address: 00:1b:21:7e:2e:8c ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 pciconf -v -l ix0@pci0:5:0:0: class=0x020000 card=0x00068086 chip=0x10fb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet sysctl dev.ix dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5 dev.ix.0.%driver: ix dev.ix.0.%location: slot=0 function=0 dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 subdevice=0x0006 class=0x020000 dev.ix.0.%parent: pci5 dev.ix.0.fc: 3 dev.ix.0.advertise_gig: 0 dev.ix.0.enable_aim: 1 dev.ix.0.advertise_speed: 0 dev.ix.0.rx_processing_limit: 128 dev.ix.0.dropped: 0 dev.ix.0.mbuf_defrag_failed: 0 dev.ix.0.no_tx_dma_setup: 0 dev.ix.0.watchdog_events: 0 dev.ix.0.tso_tx: 174470 dev.ix.0.link_irq: 3 dev.ix.0.queue0.interrupt_rate: 1000000 dev.ix.0.queue0.txd_head: 59 dev.ix.0.queue0.txd_tail: 59 dev.ix.0.queue0.no_desc_avail: 0 dev.ix.0.queue0.tx_packets: 38913 dev.ix.0.queue0.rxd_head: 384 dev.ix.0.queue0.rxd_tail: 383 dev.ix.0.queue0.rx_packets: 54982 dev.ix.0.queue0.rx_bytes: 36197485 dev.ix.0.queue0.lro_queued: 0 dev.ix.0.queue0.lro_flushed: 0 dev.ix.0.queue1.interrupt_rate: 1000000 dev.ix.0.queue1.txd_head: 1417 dev.ix.0.queue1.txd_tail: 1417 dev.ix.0.queue1.no_desc_avail: 0 dev.ix.0.queue1.tx_packets: 51196 dev.ix.0.queue1.rxd_head: 445 dev.ix.0.queue1.rxd_tail: 444 dev.ix.0.queue1.rx_packets: 70841 dev.ix.0.queue1.rx_bytes: 26319740 dev.ix.0.queue1.lro_queued: 0 dev.ix.0.queue1.lro_flushed: 0 dev.ix.0.queue2.interrupt_rate: 20408 dev.ix.0.queue2.txd_head: 194 dev.ix.0.queue2.txd_tail: 194 dev.ix.0.queue2.no_desc_avail: 0 dev.ix.0.queue2.tx_packets: 45102 dev.ix.0.queue2.rxd_head: 696 dev.ix.0.queue2.rxd_tail: 695 dev.ix.0.queue2.rx_packets: 65107 dev.ix.0.queue2.rx_bytes: 49222403 dev.ix.0.queue2.lro_queued: 0 dev.ix.0.queue2.lro_flushed: 0 dev.ix.0.queue3.interrupt_rate: 200000 dev.ix.0.queue3.txd_head: 1605 dev.ix.0.queue3.txd_tail: 1605 dev.ix.0.queue3.no_desc_avail: 0 dev.ix.0.queue3.tx_packets: 77375 dev.ix.0.queue3.rxd_head: 79 dev.ix.0.queue3.rxd_tail: 78 dev.ix.0.queue3.rx_packets: 109498 dev.ix.0.queue3.rx_bytes: 109951775 dev.ix.0.queue3.lro_queued: 0 dev.ix.0.queue3.lro_flushed: 0 dev.ix.0.queue4.interrupt_rate: 10526 dev.ix.0.queue4.txd_head: 1624 dev.ix.0.queue4.txd_tail: 1624 dev.ix.0.queue4.no_desc_avail: 0 dev.ix.0.queue4.tx_packets: 39497 dev.ix.0.queue4.rxd_head: 480 dev.ix.0.queue4.rxd_tail: 479 dev.ix.0.queue4.rx_packets: 51998 dev.ix.0.queue4.rx_bytes: 21965859 dev.ix.0.queue4.lro_queued: 0 dev.ix.0.queue4.lro_flushed: 0 dev.ix.0.queue5.interrupt_rate: 1000000 dev.ix.0.queue5.txd_head: 1613 dev.ix.0.queue5.txd_tail: 1613 dev.ix.0.queue5.no_desc_avail: 0 dev.ix.0.queue5.tx_packets: 69860 dev.ix.0.queue5.rxd_head: 846 dev.ix.0.queue5.rxd_tail: 845 dev.ix.0.queue5.rx_packets: 81331 dev.ix.0.queue5.rx_bytes: 32429926 dev.ix.0.queue5.lro_queued: 0 dev.ix.0.queue5.lro_flushed: 0 dev.ix.0.queue6.interrupt_rate: 142857 dev.ix.0.queue6.txd_head: 1482 dev.ix.0.queue6.txd_tail: 1484 dev.ix.0.queue6.no_desc_avail: 0 dev.ix.0.queue6.tx_packets: 45878 dev.ix.0.queue6.rxd_head: 355 dev.ix.0.queue6.rxd_tail: 354 dev.ix.0.queue6.rx_packets: 62211 dev.ix.0.queue6.rx_bytes: 27653559 dev.ix.0.queue6.lro_queued: 0 dev.ix.0.queue6.lro_flushed: 0 dev.ix.0.queue7.interrupt_rate: 5347 dev.ix.0.queue7.txd_head: 603 dev.ix.0.queue7.txd_tail: 603 dev.ix.0.queue7.no_desc_avail: 0 dev.ix.0.queue7.tx_packets: 61997 dev.ix.0.queue7.rxd_head: 826 dev.ix.0.queue7.rxd_tail: 825 dev.ix.0.queue7.rx_packets: 83460 dev.ix.0.queue7.rx_bytes: 50183116 dev.ix.0.queue7.lro_queued: 0 dev.ix.0.queue7.lro_flushed: 0 dev.ix.0.mac_stats.crc_errs: 0 dev.ix.0.mac_stats.ill_errs: 0 dev.ix.0.mac_stats.byte_errs: 0 dev.ix.0.mac_stats.short_discards: 0 dev.ix.0.mac_stats.local_faults: 3 dev.ix.0.mac_stats.remote_faults: 1 dev.ix.0.mac_stats.rec_len_errs: 0 dev.ix.0.mac_stats.link_xon_txd: 0 dev.ix.0.mac_stats.link_xon_rcvd: 0 dev.ix.0.mac_stats.link_xoff_txd: 0 dev.ix.0.mac_stats.link_xoff_rcvd: 0 dev.ix.0.mac_stats.total_octets_rcvd: 360072702 dev.ix.0.mac_stats.good_octets_rcvd: 359999778 dev.ix.0.mac_stats.total_pkts_rcvd: 637428 dev.ix.0.mac_stats.good_pkts_rcvd: 636321 dev.ix.0.mac_stats.mcast_pkts_rcvd: 35 dev.ix.0.mac_stats.bcast_pkts_rcvd: 1411 dev.ix.0.mac_stats.rx_frames_64: 222251 dev.ix.0.mac_stats.rx_frames_65_127: 159044 dev.ix.0.mac_stats.rx_frames_128_255: 15139 dev.ix.0.mac_stats.rx_frames_256_511: 13885 dev.ix.0.mac_stats.rx_frames_512_1023: 21283 dev.ix.0.mac_stats.rx_frames_1024_1522: 204719 dev.ix.0.mac_stats.recv_undersized: 0 dev.ix.0.mac_stats.recv_fragmented: 0 dev.ix.0.mac_stats.recv_oversized: 0 dev.ix.0.mac_stats.recv_jabberd: 0 dev.ix.0.mac_stats.management_pkts_rcvd: 0 dev.ix.0.mac_stats.management_pkts_drpd: 0 dev.ix.0.mac_stats.checksum_errs: 0 dev.ix.0.mac_stats.good_octets_txd: 882467530 dev.ix.0.mac_stats.total_pkts_txd: 816387 dev.ix.0.mac_stats.good_pkts_txd: 816387 dev.ix.0.mac_stats.bcast_pkts_txd: 36 dev.ix.0.mac_stats.mcast_pkts_txd: 0 dev.ix.0.mac_stats.management_pkts_txd: 0 dev.ix.0.mac_stats.tx_frames_64: 21509 dev.ix.0.mac_stats.tx_frames_65_127: 168051 dev.ix.0.mac_stats.tx_frames_128_255: 19184 dev.ix.0.mac_stats.tx_frames_256_511: 22775 dev.ix.0.mac_stats.tx_frames_512_1023: 24222 dev.ix.0.mac_stats.tx_frames_1024_1522: 560646 dev.ix.0.mac_stats.fc_crc: 0 dev.ix.0.mac_stats.fc_last: 0 dev.ix.0.mac_stats.fc_drpd: 0 dev.ix.0.mac_stats.fc_pkts_rcvd: 0 dev.ix.0.mac_stats.fc_pkts_txd: 0 dev.ix.0.mac_stats.fc_dword_rcvd: 0 dev.ix.0.mac_stats.fc_dword_txd: 0 vmstat -i interrupt total rate irq1: atkbd0 1 0 irq6: fdc0 1 0 irq14: ata0 35 0 irq20: uhci0 1 0 irq23: ehci0 41 0 irq66: arcmsr0 66431 74 cpu0: timer 1773313 1999 irq256: ix0:que 0 99591 112 irq257: ix0:que 1 109526 123 irq258: ix0:que 2 97963 110 irq259: ix0:que 3 220346 248 irq260: ix0:que 4 85912 96 irq261: ix0:que 5 155002 174 irq262: ix0:que 6 99027 111 irq263: ix0:que 7 124176 139 irq264: ix0:link 3 0 irq270: igb1:que 0 312 0 irq271: igb1:que 1 2 0 irq274: igb1:link 2 0 cpu7: timer 1765259 1990 cpu6: timer 1765259 1990 cpu4: timer 1765260 1990 cpu5: timer 1765260 1990 cpu1: timer 1765259 1990 cpu2: timer 1765259 1990 cpu3: timer 1765260 1990 Total 15188501 17123 netstat -m 13479/5091/18570 mbufs in use (current/cache/total) 12327/4319/16646/524288 mbuf clusters in use (current/cache/total/max) 12285/1667 mbuf+clusters out of packet secondary zone in use (current/cache) 6/506/512/262144 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 28047K/11934K/39982K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 1257 requests for I/O initiated by sendfile 0 calls to protocol drain routines netstat -i Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll ix0 1500 00:1b:21:7e:2e:8c 1307940 0 0 1708291 0 0 ix0 1500 X.X.X.0 ixhost 26195 - - 1601162 - - igb0* 1500 00:30:48:c5:31:02 0 0 0 0 0 0 igb1 1500 00:30:48:c5:31:03 741 0 0 721 0 0 igb1 1500 10.10.10.0 10.10.10.64 679 - - 718 - - lo0 16384 6824 0 0 6824 0 0 lo0 16384 fe80:4::1 fe80:4::1 0 - - 0 - - lo0 16384 localhost ::1 0 - - 0 - - lo0 16384 your-net localhost 26 - - 6824 - - A ping from the cisco 6509 its connected to:- Sending 1000, 100-byte ICMP Echos to 85.236.96.64, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!! Success rate is 99 percent (996/1000), round-trip min/avg/max = 1/1/208 ms Config on the cisco end:- TenGigabitEthernet9/2 is up, line protocol is up (connected) Hardware is C6k 10000Mb 802.3, address is 001e.1323.f325 (bia 001e.1323.f325) Description: ixhost (10Gbps) MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 10Gb/s input flow-control is on, output flow-control is on ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output 46w5d, output hang never Last clearing of "show interface" counters never Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 12204000 bits/sec, 1351 packets/sec 5 minute output rate 4998000 bits/sec, 1007 packets/sec 78180252111 packets input, 92996518599740 bytes, 0 no buffer Received 314449 broadcasts (0 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 51832915763 packets output, 24954526878125 bytes, 0 underruns 0 output errors, 0 collisions, 3 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out systat 1 :if /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10 Load Average | Interface Traffic Peak Total lo0 in 0.953 KB/s 1.916 KB/s 2.669 MB out 0.953 KB/s 1.916 KB/s 2.669 MB igb1 in 0.063 KB/s 0.128 KB/s 85.663 KB out 0.142 KB/s 0.269 KB/s 203.177 KB ix0 in 215.019 KB/s 679.274 KB/s 1000.871 MB out 755.770 KB/s 1.113 MB/s 2.447 GB Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 15:30:14 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F65E1065673 for ; Mon, 12 Mar 2012 15:30:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2D7398FC0A for ; Mon, 12 Mar 2012 15:30:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2CFUEPs019698 for ; Mon, 12 Mar 2012 15:30:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2CFUDjR019695; Mon, 12 Mar 2012 15:30:13 GMT (envelope-from gnats) Date: Mon, 12 Mar 2012 15:30:13 GMT Message-Id: <201203121530.q2CFUDjR019695@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Vladislav Movchan Cc: Subject: Re: kern/165622: [ndis][panic][patch] Unregistered use of FPU in kernel on amd64 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vladislav Movchan List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 15:30:14 -0000 The following reply was made to PR kern/165622; it has been noted by GNATS. From: Vladislav Movchan To: bug-followup@FreeBSD.org, vladislav.movchan@gmail.com Cc: Subject: Re: kern/165622: [ndis][panic][patch] Unregistered use of FPU in kernel on amd64 Date: Mon, 12 Mar 2012 17:20:53 +0200 --e89a8f6465adbf936e04bb0d4973 Content-Type: text/plain; charset=ISO-8859-1 I've reimplemented original patch to maintain cache of fpu_kern_ctx elements to reduce amount of allocations/deallocations done via fpu_kern_alloc_ctx/fpu_kern_free_ctx. It is complex to measure performance gain of this change due to deadlock in ndis code (what makes it complex or impossible to stress-test), but when the same change was tested with https://github.com/NDISulator/ it allowed to get about 10% higher bandwidth with 1Gbps NIC (which was CPU bound). --e89a8f6465adbf936e04bb0d4973 Content-Type: text/plain; charset=US-ASCII; name="fpu_patch2.txt" Content-Disposition: attachment; filename="fpu_patch2.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gzpnl7720 SW5kZXg6IC91c3Ivc3JjL3N5cy9jb21wYXQvbmRpcy9wZV92YXIuaAo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSAv dXNyL3NyYy9zeXMvY29tcGF0L25kaXMvcGVfdmFyLmgJKHJldmlzaW9uIDIzMjM3OSkKKysrIC91 c3Ivc3JjL3N5cy9jb21wYXQvbmRpcy9wZV92YXIuaAkod29ya2luZyBjb3B5KQpAQCAtNDYwLDIy ICs0NjAsMzAgQEAKIGV4dGVybiB1aW50NjRfdCB4ODZfNjRfY2FsbDYodm9pZCAqLCB1aW50NjRf dCwgdWludDY0X3QsIHVpbnQ2NF90LCB1aW50NjRfdCwKIAl1aW50NjRfdCwgdWludDY0X3QpOwog Cit1aW50NjRfdCBfeDg2XzY0X2NhbGwxKHZvaWQgKiwgdWludDY0X3QpOwordWludDY0X3QgX3g4 Nl82NF9jYWxsMih2b2lkICosIHVpbnQ2NF90LCB1aW50NjRfdCk7Cit1aW50NjRfdCBfeDg2XzY0 X2NhbGwzKHZvaWQgKiwgdWludDY0X3QsIHVpbnQ2NF90LCB1aW50NjRfdCk7Cit1aW50NjRfdCBf eDg2XzY0X2NhbGw0KHZvaWQgKiwgdWludDY0X3QsIHVpbnQ2NF90LCB1aW50NjRfdCwgdWludDY0 X3QpOwordWludDY0X3QgX3g4Nl82NF9jYWxsNSh2b2lkICosIHVpbnQ2NF90LCB1aW50NjRfdCwg dWludDY0X3QsIHVpbnQ2NF90LAorICAgIHVpbnQ2NF90KTsKK3VpbnQ2NF90IF94ODZfNjRfY2Fs bDYodm9pZCAqLCB1aW50NjRfdCwgdWludDY0X3QsIHVpbnQ2NF90LCB1aW50NjRfdCwKKyAgICB1 aW50NjRfdCwgdWludDY0X3QpOwogCiAjZGVmaW5lCU1TQ0FMTDEoZm4sIGEpCQkJCQkJXAotCXg4 Nl82NF9jYWxsMSgoZm4pLCAodWludDY0X3QpKGEpKQorCV94ODZfNjRfY2FsbDEoKGZuKSwgKHVp bnQ2NF90KShhKSkKICNkZWZpbmUJTVNDQUxMMihmbiwgYSwgYikJCQkJCVwKLQl4ODZfNjRfY2Fs bDIoKGZuKSwgKHVpbnQ2NF90KShhKSwgKHVpbnQ2NF90KShiKSkKKwlfeDg2XzY0X2NhbGwyKChm biksICh1aW50NjRfdCkoYSksICh1aW50NjRfdCkoYikpCiAjZGVmaW5lCU1TQ0FMTDMoZm4sIGEs IGIsIGMpCQkJCQlcCi0JeDg2XzY0X2NhbGwzKChmbiksICh1aW50NjRfdCkoYSksICh1aW50NjRf dCkoYiksCQlcCisJX3g4Nl82NF9jYWxsMygoZm4pLCAodWludDY0X3QpKGEpLCAodWludDY0X3Qp KGIpLAkJXAogCSh1aW50NjRfdCkoYykpCiAjZGVmaW5lCU1TQ0FMTDQoZm4sIGEsIGIsIGMsIGQp CQkJCQlcCi0JeDg2XzY0X2NhbGw0KChmbiksICh1aW50NjRfdCkoYSksICh1aW50NjRfdCkoYiks CQlcCisJX3g4Nl82NF9jYWxsNCgoZm4pLCAodWludDY0X3QpKGEpLCAodWludDY0X3QpKGIpLAkJ XAogCSh1aW50NjRfdCkoYyksICh1aW50NjRfdCkoZCkpCiAjZGVmaW5lCU1TQ0FMTDUoZm4sIGEs IGIsIGMsIGQsIGUpCQkJCVwKLQl4ODZfNjRfY2FsbDUoKGZuKSwgKHVpbnQ2NF90KShhKSwgKHVp bnQ2NF90KShiKSwJCVwKKwlfeDg2XzY0X2NhbGw1KChmbiksICh1aW50NjRfdCkoYSksICh1aW50 NjRfdCkoYiksCQlcCiAJKHVpbnQ2NF90KShjKSwgKHVpbnQ2NF90KShkKSwgKHVpbnQ2NF90KShl KSkKICNkZWZpbmUJTVNDQUxMNihmbiwgYSwgYiwgYywgZCwgZSwgZikJCQkJXAotCXg4Nl82NF9j YWxsNigoZm4pLCAodWludDY0X3QpKGEpLCAodWludDY0X3QpKGIpLAkJXAorCV94ODZfNjRfY2Fs bDYoKGZuKSwgKHVpbnQ2NF90KShhKSwgKHVpbnQ2NF90KShiKSwJCVwKIAkodWludDY0X3QpKGMp LCAodWludDY0X3QpKGQpLCAodWludDY0X3QpKGUpLCAodWludDY0X3QpKGYpKQogCiAjZW5kaWYg LyogX19hbWQ2NF9fICovCkluZGV4OiAvdXNyL3NyYy9zeXMvY29tcGF0L25kaXMva2Vybl93aW5k cnYuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSAvdXNyL3NyYy9zeXMvY29tcGF0L25kaXMva2Vybl93aW5kcnYu YwkocmV2aXNpb24gMjMyMzc5KQorKysgL3Vzci9zcmMvc3lzL2NvbXBhdC9uZGlzL2tlcm5fd2lu ZHJ2LmMJKHdvcmtpbmcgY29weSkKQEAgLTU2LDYgKzU2LDEwIEBACiAjaW5jbHVkZSA8bWFjaGlu ZS9zZWdtZW50cy5oPgogI2VuZGlmCiAKKyNpZmRlZiBfX2FtZDY0X18KKyNpbmNsdWRlIDxtYWNo aW5lL2ZwdS5oPgorI2VuZGlmCisKICNpbmNsdWRlIDxkZXYvdXNiL3VzYi5oPgogCiAjaW5jbHVk ZSA8Y29tcGF0L25kaXMvcGVfdmFyLmg+CkBAIC02Niw2ICs3MCwxNiBAQAogI2luY2x1ZGUgPGNv bXBhdC9uZGlzL2hhbF92YXIuaD4KICNpbmNsdWRlIDxjb21wYXQvbmRpcy91c2JkX3Zhci5oPgog CisjaWZkZWYgX19hbWQ2NF9fCitzdHJ1Y3QgZnB1X2NjX2VudCB7CisJY2hhcgkJdXNlZDsKKwlz dHJ1Y3QgZnB1X2tlcm5fY3R4ICpjdHg7CisJU0xJU1RfRU5UUlkoZnB1X2NjX2VudCkgbGluazsK K307CitzdGF0aWMgU0xJU1RfSEVBRChmcHVfY3R4X2NhY2hlLCBmcHVfY2NfZW50KSBmcHVfY2Nf aGVhZDsKK3N0YXRpYyBzdHJ1Y3QgbXR4IGZwdV9jYWNoZV9tdHg7CisjZW5kaWYKKwogc3RhdGlj IHN0cnVjdCBtdHggZHJ2ZGJfbXR4Owogc3RhdGljIFNUQUlMUV9IRUFEKGRydmRiLCBkcnZkYl9l bnQpIGRydmRiX2hlYWQ7CiAKQEAgLTk2LDYgKzExMCwxMSBAQAogCW10eF9pbml0KCZkcnZkYl9t dHgsICJXaW5kb3dzIGRyaXZlciBEQiBsb2NrIiwKIAkgICAgIldpbmRvd3MgaW50ZXJuYWwgbG9j ayIsIE1UWF9ERUYpOwogCisjaWZkZWYgX19hbWQ2NF9fCisJU0xJU1RfSU5JVCgmZnB1X2NjX2hl YWQpOworCW10eF9pbml0KCZmcHVfY2FjaGVfbXR4LCAiZnB1IGNvbnRleHQgY2FjaGUgbG9jayIs IE5VTEwsIE1UWF9ERUYpOworI2VuZGlmCisKIAkvKgogCSAqIFBDSSBhbmQgcGNjYXJkIGRldmlj ZXMgZG9uJ3QgbmVlZCB0byB1c2UgSVJQcyB0bwogCSAqIGludGVyYWN0IHdpdGggdGhlaXIgYnVz IGRyaXZlcnMgKHVzdWFsbHkpLCBzbyBvdXIKQEAgLTEzMCw2ICsxNDksOSBAQAogd2luZHJ2X2xp YmZpbmkodm9pZCkKIHsKIAlzdHJ1Y3QgZHJ2ZGJfZW50CSpkOworI2lmZGVmIF9fYW1kNjRfXwor CXN0cnVjdCBmcHVfY2NfZW50ICplbnQ7CisjZW5kaWYKIAogCW10eF9sb2NrKCZkcnZkYl9tdHgp OyAKIAl3aGlsZShTVEFJTFFfRklSU1QoJmRydmRiX2hlYWQpICE9IE5VTEwpIHsKQEAgLTE0OCw2 ICsxNzAsMTUgQEAKIAlzbXBfcmVuZGV6dm91cyhOVUxMLCB4ODZfb2xkbGR0LCBOVUxMLCBOVUxM KTsKIAlFeEZyZWVQb29sKG15X3RpZHMpOwogI2VuZGlmCisjaWZkZWYgX19hbWQ2NF9fCisJd2hp bGUgKChlbnQgPSBTTElTVF9GSVJTVCgmZnB1X2NjX2hlYWQpKSAhPSBOVUxMKSB7CisJCVNMSVNU X1JFTU9WRV9IRUFEKCZmcHVfY2NfaGVhZCwgbGluayk7CisJCWZwdV9rZXJuX2ZyZWVfY3R4KGVu dC0+Y3R4KTsKKwkJZnJlZShlbnQsIE1fREVWQlVGKTsKKwl9CisKKwltdHhfZGVzdHJveSgmZnB1 X2NhY2hlX210eCk7CisjZW5kaWYKIAlyZXR1cm4gKDApOwogfQogCkBAIC01NzMsNiArNjA0LDE0 MSBAQAogCXJldHVybiAoMCk7CiB9CiAKK3N0YXRpYyBzdHJ1Y3QgZnB1X2NjX2VudCAqCityZXF1 ZXN0X2ZwdV9jY19lbnQodm9pZCkKK3sKKwlzdHJ1Y3QgZnB1X2NjX2VudCAqZW50OworCisJbXR4 X2xvY2soJmZwdV9jYWNoZV9tdHgpOworCVNMSVNUX0ZPUkVBQ0goZW50LCAmZnB1X2NjX2hlYWQs IGxpbmspIHsKKwkJaWYoZW50LT51c2VkID09IDApIHsKKwkJCWVudC0+dXNlZCA9IDE7CisJCQlt dHhfdW5sb2NrKCZmcHVfY2FjaGVfbXR4KTsKKwkJCXJldHVybiAoZW50KTsKKwkJfQorCX0KKwlt dHhfdW5sb2NrKCZmcHVfY2FjaGVfbXR4KTsKKworCWlmICgoZW50ID0gbWFsbG9jKHNpemVvZihz dHJ1Y3QgZnB1X2NjX2VudCksIE1fREVWQlVGLCBNX05PV0FJVCB8CisJICAgIE1fWkVSTykpICE9 IE5VTEwpIHsKKwkJZW50LT5jdHggPSBmcHVfa2Vybl9hbGxvY19jdHgoRlBVX0tFUk5fTk9STUFM IHwKKwkJICAgIEZQVV9LRVJOX05PV0FJVCk7CisJCWlmIChlbnQtPmN0eCAhPSBOVUxMKSB7CisJ CQllbnQtPnVzZWQgPSAxOworCQkJbXR4X2xvY2soJmZwdV9jYWNoZV9tdHgpOworCQkJU0xJU1Rf SU5TRVJUX0hFQUQoJmZwdV9jY19oZWFkLCBlbnQsIGxpbmspOworCQkJbXR4X3VubG9jaygmZnB1 X2NhY2hlX210eCk7CisJCX0gZWxzZQorCQkJZnJlZShlbnQsIE1fREVWQlVGKTsKKwl9CisKKwly ZXR1cm4gKGVudCk7Cit9CisKK3N0YXRpYyB2b2lkCityZWxlYXNlX2ZwdV9jY19lbnQoc3RydWN0 IGZwdV9jY19lbnQgKmVudCkKK3sKKworCWVudC0+dXNlZCA9IDA7Cit9CisKK3VpbnQ2NF90Citf eDg2XzY0X2NhbGwxKHZvaWQgKmZuLCB1aW50NjRfdCBhKQoreworCXN0cnVjdCBmcHVfY2NfZW50 ICplbnQ7CisJdWludDY0X3QgcmV0OworCisJaWYgKChlbnQgPSByZXF1ZXN0X2ZwdV9jY19lbnQo KSkgPT0gTlVMTCkKKwkJcmV0dXJuIChFTk9NRU0pOworCWZwdV9rZXJuX2VudGVyKGN1cnRocmVh ZCwgZW50LT5jdHgsIEZQVV9LRVJOX05PUk1BTCk7CisJcmV0ID0geDg2XzY0X2NhbGwxKGZuLCBh KTsKKwlmcHVfa2Vybl9sZWF2ZShjdXJ0aHJlYWQsIGVudC0+Y3R4KTsKKwlyZWxlYXNlX2ZwdV9j Y19lbnQoZW50KTsKKworCXJldHVybiAocmV0KTsKK30KKwordWludDY0X3QKK194ODZfNjRfY2Fs bDIodm9pZCAqZm4sIHVpbnQ2NF90IGEsIHVpbnQ2NF90IGIpCit7CisJc3RydWN0IGZwdV9jY19l bnQgKmVudDsKKwl1aW50NjRfdCByZXQ7CisKKwlpZiAoKGVudCA9IHJlcXVlc3RfZnB1X2NjX2Vu dCgpKSA9PSBOVUxMKQorCQlyZXR1cm4gKEVOT01FTSk7CisJZnB1X2tlcm5fZW50ZXIoY3VydGhy ZWFkLCBlbnQtPmN0eCwgRlBVX0tFUk5fTk9STUFMKTsKKwlyZXQgPSB4ODZfNjRfY2FsbDIoZm4s IGEsIGIpOworCWZwdV9rZXJuX2xlYXZlKGN1cnRocmVhZCwgZW50LT5jdHgpOworCXJlbGVhc2Vf ZnB1X2NjX2VudChlbnQpOworCisJcmV0dXJuIChyZXQpOworfQorCit1aW50NjRfdAorX3g4Nl82 NF9jYWxsMyh2b2lkICpmbiwgdWludDY0X3QgYSwgdWludDY0X3QgYiwgdWludDY0X3QgYykKK3sK KwlzdHJ1Y3QgZnB1X2NjX2VudCAqZW50OworCXVpbnQ2NF90IHJldDsKKworCWlmICgoZW50ID0g cmVxdWVzdF9mcHVfY2NfZW50KCkpID09IE5VTEwpCisJCXJldHVybiAoRU5PTUVNKTsKKwlmcHVf a2Vybl9lbnRlcihjdXJ0aHJlYWQsIGVudC0+Y3R4LCBGUFVfS0VSTl9OT1JNQUwpOworCXJldCA9 IHg4Nl82NF9jYWxsMyhmbiwgYSwgYiwgYyk7CisJZnB1X2tlcm5fbGVhdmUoY3VydGhyZWFkLCBl bnQtPmN0eCk7CisJcmVsZWFzZV9mcHVfY2NfZW50KGVudCk7CisKKwlyZXR1cm4gKHJldCk7Cit9 CisKK3VpbnQ2NF90CitfeDg2XzY0X2NhbGw0KHZvaWQgKmZuLCB1aW50NjRfdCBhLCB1aW50NjRf dCBiLCB1aW50NjRfdCBjLCB1aW50NjRfdCBkKQoreworCXN0cnVjdCBmcHVfY2NfZW50ICplbnQ7 CisJdWludDY0X3QgcmV0OworCisJaWYgKChlbnQgPSByZXF1ZXN0X2ZwdV9jY19lbnQoKSkgPT0g TlVMTCkKKwkJcmV0dXJuIChFTk9NRU0pOworCWZwdV9rZXJuX2VudGVyKGN1cnRocmVhZCwgZW50 LT5jdHgsIEZQVV9LRVJOX05PUk1BTCk7CisJcmV0ID0geDg2XzY0X2NhbGw0KGZuLCBhLCBiLCBj LCBkKTsKKwlmcHVfa2Vybl9sZWF2ZShjdXJ0aHJlYWQsIGVudC0+Y3R4KTsKKwlyZWxlYXNlX2Zw dV9jY19lbnQoZW50KTsKKworCXJldHVybiAocmV0KTsKK30KKwordWludDY0X3QKK194ODZfNjRf Y2FsbDUodm9pZCAqZm4sIHVpbnQ2NF90IGEsIHVpbnQ2NF90IGIsIHVpbnQ2NF90IGMsIHVpbnQ2 NF90IGQsCisgICAgdWludDY0X3QgZSkKK3sKKwlzdHJ1Y3QgZnB1X2NjX2VudCAqZW50OworCXVp bnQ2NF90IHJldDsKKworCWlmICgoZW50ID0gcmVxdWVzdF9mcHVfY2NfZW50KCkpID09IE5VTEwp CisJCXJldHVybiAoRU5PTUVNKTsKKwlmcHVfa2Vybl9lbnRlcihjdXJ0aHJlYWQsIGVudC0+Y3R4 LCBGUFVfS0VSTl9OT1JNQUwpOworCXJldCA9IHg4Nl82NF9jYWxsNShmbiwgYSwgYiwgYywgZCwg ZSk7CisJZnB1X2tlcm5fbGVhdmUoY3VydGhyZWFkLCBlbnQtPmN0eCk7CisJcmVsZWFzZV9mcHVf Y2NfZW50KGVudCk7CisKKwlyZXR1cm4gKHJldCk7Cit9CisKK3VpbnQ2NF90CitfeDg2XzY0X2Nh bGw2KHZvaWQgKmZuLCB1aW50NjRfdCBhLCB1aW50NjRfdCBiLCB1aW50NjRfdCBjLCB1aW50NjRf dCBkLAorICAgIHVpbnQ2NF90IGUsIHVpbnQ2NF90IGYpCit7CisJc3RydWN0IGZwdV9jY19lbnQg KmVudDsKKwl1aW50NjRfdCByZXQ7CisKKwlpZiAoKGVudCA9IHJlcXVlc3RfZnB1X2NjX2VudCgp KSA9PSBOVUxMKQorCQlyZXR1cm4gKEVOT01FTSk7CisJZnB1X2tlcm5fZW50ZXIoY3VydGhyZWFk LCBlbnQtPmN0eCwgRlBVX0tFUk5fTk9STUFMKTsKKwlyZXQgPSB4ODZfNjRfY2FsbDYoZm4sIGEs IGIsIGMsIGQsIGUsIGYpOworCWZwdV9rZXJuX2xlYXZlKGN1cnRocmVhZCwgZW50LT5jdHgpOwor CXJlbGVhc2VfZnB1X2NjX2VudChlbnQpOworCisJcmV0dXJuIChyZXQpOworfQogI2lmZGVmIF9f YW1kNjRfXwogCiBleHRlcm4gdm9pZAl4ODZfNjRfd3JhcCh2b2lkKTsK --e89a8f6465adbf936e04bb0d4973-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 15:41:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5483106566B for ; Mon, 12 Mar 2012 15:41:15 +0000 (UTC) (envelope-from prvs=1418b75531=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 351608FC14 for ; Mon, 12 Mar 2012 15:41:14 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Mon, 12 Mar 2012 15:41:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50018594956.msg for ; Mon, 12 Mar 2012 15:41:06 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1418b75531=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <37C359B9C25A4664938114062FBC56A5@multiplay.co.uk> From: "Steven Hartland" To: References: <18969B34B4EE402986389D5022DCCB35@multiplay.co.uk> Date: Mon, 12 Mar 2012 15:41:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: ixgbe interface micro stalls / slow responses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 15:41:15 -0000 As a quick update see below, still stumped on what's causing this but does explain at least two of the other suspect behaviours. ----- Original Message ----- From: "Steven Hartland" > We are seeing "RX Descriptors exceed system mbuf max, using > default instead!" on boot with the latest driver but the fix > listed in the readme has no effect, as in sysctl.conf we have > kern.ipc.nmbclusters=524288 > kern.ipc.nmbjumbop=262144 Just been looking at the code and call be stupid but the driver loads before root is mounted and hence before /etc/rc.d/sysctl has run so how can adding values to this possibly work? Is this meant to say /boot/loader.conf? ... > A ping from the cisco 6509 its connected to:- > Sending 1000, 100-byte ICMP Echos to 85.236.96.64, timeout is 2 seconds: > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!! > Success rate is 99 percent (996/1000), round-trip min/avg/max = 1/1/208 ms The regular loss here is due to icmp limiting so is not a factor here. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 15:46:42 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C15351065678 for ; Mon, 12 Mar 2012 15:46:42 +0000 (UTC) (envelope-from seyit.ozgur@istanbul.net) Received: from spamtrap1.istanbul.net (spamtrap1.istanbul.net [85.111.12.35]) by mx1.freebsd.org (Postfix) with ESMTP id EA4268FC19 for ; Mon, 12 Mar 2012 15:46:41 +0000 (UTC) X-ASG-Debug-ID: 1331567191-0426b062bc15b2e0001-QdxwpM Received: from GAMMA.magnetdigital.local (gamma.magnetdigital.local [192.168.131.244]) by spamtrap1.istanbul.net with ESMTP id F53VpxBttOQwBghl; Mon, 12 Mar 2012 17:46:31 +0200 (EET) X-Barracuda-Envelope-From: seyit.ozgur@istanbul.net X-Barracuda-RBL-Trusted-Forwarder: 192.168.131.244 Received: from YUHANNA.magnetdigital.local ([fe80::1058:3088:f9b1:1346]) by GAMMA.magnetdigital.local ([fe80::3cca:d6ef:febb:fafb%17]) with mapi id 14.01.0218.012; Mon, 12 Mar 2012 17:45:43 +0200 From: =?iso-8859-9?Q?Seyit_=D6zg=FCr?= X-Barracuda-Apparent-Source-IP: fe80::1058:3088:f9b1:1346 To: Steven Hartland , "freebsd-net@freebsd.org" Thread-Topic: ixgbe interface micro stalls / slow responses X-ASG-Orig-Subj: RE: ixgbe interface micro stalls / slow responses Thread-Index: AQHNAGGGkJ4cFbi5ykipjjnJogjL25ZmzPrg Date: Mon, 12 Mar 2012 15:45:42 +0000 Message-ID: <3807CE6F3BF4B04EB897F4EBF2D258CE5C055123@yuhanna.magnetdigital.local> References: <18969B34B4EE402986389D5022DCCB35@multiplay.co.uk> In-Reply-To: <18969B34B4EE402986389D5022DCCB35@multiplay.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.134.34] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00D6_01CD0077.F16AF800" MIME-Version: 1.0 X-Barracuda-Connect: gamma.magnetdigital.local[192.168.131.244] X-Barracuda-Start-Time: 1331567191 X-Barracuda-URL: http://10.10.140.223:8000/cgi-mod/mark.cgi X-ASG-Whitelist: Body =?UTF-8?B?Ll9ldmVudHM=?= X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: RE: ixgbe interface micro stalls / slow responses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 15:46:42 -0000 ------=_NextPart_000_00D6_01CD0077.F16AF800 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable If you put=20 kern.ipc.nmbclusters=3D524288 kern.ipc.nmbjumbop=3D262144=20 on /boot/loader.conf it won't be "ix0: RX Descriptors exceed system mbuf max, using default instead!" Seyit =D6zg=FCr Network Y=F6neticisi -----Original Message----- From: owner-freebsd-net@freebsd.org = [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Steven Hartland Sent: Monday, March 12, 2012 5:05 PM To: freebsd-net@freebsd.org Subject: ixgbe interface micro stalls / slow responses We've got a machine where with an ix interface on 8.2-RELEASE which is seeing intermittent slow responses. It shows as stalls on the console and is visible as high pings on an mtr from a local machine e.g. Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. X.X.X.X 0.0% 181 0.1 117.7 0.1 2665. 314.8 We've tried updating from 2.3.10 release driver + alias fix to 2.4.5 (the latest from 8.3) but still the behavour is the same. If we do a trace to an igb on the same machine everything is clean. Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 10.10.10.64 0.0% 136 0.1 0.2 0.1 12.5 1.1 We are seeing "RX Descriptors exceed system mbuf max, using default instead!" on boot with the latest driver but the fix listed in the readme has no effect, as in sysctl.conf we have kern.ipc.nmbclusters=3D524288 kern.ipc.nmbjumbop=3D262144 Nothing looks out of the ordinary by there's definitely a problem there somewhere, any ideas? Detailed info which may be use below. >From dmeg:- ix0: = port 0x2000-0x201f mem=20 0xd8400000-0xd847ffff,0xd8480000-0xd8483fff irq 52 at device 0.0 on pci5 ix0: Using MSIX interrupts with 9 vectors ix0: RX Descriptors exceed system mbuf max, using default instead! ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: Ethernet address: 00:1b:21:7e:2e:8c ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 pciconf -v -l ix0@pci0:5:0:0: class=3D0x020000 card=3D0x00068086 chip=3D0x10fb8086 = rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D network subclass =3D ethernet sysctl dev.ix dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5 dev.ix.0.%driver: ix dev.ix.0.%location: slot=3D0 function=3D0 dev.ix.0.%pnpinfo: vendor=3D0x8086 device=3D0x10fb subvendor=3D0x8086 subdevice=3D0x0006 class=3D0x020000 dev.ix.0.%parent: pci5 dev.ix.0.fc: 3 dev.ix.0.advertise_gig: 0 dev.ix.0.enable_aim: 1 dev.ix.0.advertise_speed: 0 dev.ix.0.rx_processing_limit: 128 dev.ix.0.dropped: 0 dev.ix.0.mbuf_defrag_failed: 0 dev.ix.0.no_tx_dma_setup: 0 dev.ix.0.watchdog_events: 0 dev.ix.0.tso_tx: 174470 dev.ix.0.link_irq: 3 dev.ix.0.queue0.interrupt_rate: 1000000 dev.ix.0.queue0.txd_head: 59 dev.ix.0.queue0.txd_tail: 59 dev.ix.0.queue0.no_desc_avail: 0 dev.ix.0.queue0.tx_packets: 38913 dev.ix.0.queue0.rxd_head: 384 dev.ix.0.queue0.rxd_tail: 383 dev.ix.0.queue0.rx_packets: 54982 dev.ix.0.queue0.rx_bytes: 36197485 dev.ix.0.queue0.lro_queued: 0 dev.ix.0.queue0.lro_flushed: 0 dev.ix.0.queue1.interrupt_rate: 1000000 dev.ix.0.queue1.txd_head: 1417 dev.ix.0.queue1.txd_tail: 1417 dev.ix.0.queue1.no_desc_avail: 0 dev.ix.0.queue1.tx_packets: 51196 dev.ix.0.queue1.rxd_head: 445 dev.ix.0.queue1.rxd_tail: 444 dev.ix.0.queue1.rx_packets: 70841 dev.ix.0.queue1.rx_bytes: 26319740 dev.ix.0.queue1.lro_queued: 0 dev.ix.0.queue1.lro_flushed: 0 dev.ix.0.queue2.interrupt_rate: 20408 dev.ix.0.queue2.txd_head: 194 dev.ix.0.queue2.txd_tail: 194 dev.ix.0.queue2.no_desc_avail: 0 dev.ix.0.queue2.tx_packets: 45102 dev.ix.0.queue2.rxd_head: 696 dev.ix.0.queue2.rxd_tail: 695 dev.ix.0.queue2.rx_packets: 65107 dev.ix.0.queue2.rx_bytes: 49222403 dev.ix.0.queue2.lro_queued: 0 dev.ix.0.queue2.lro_flushed: 0 dev.ix.0.queue3.interrupt_rate: 200000 dev.ix.0.queue3.txd_head: 1605 dev.ix.0.queue3.txd_tail: 1605 dev.ix.0.queue3.no_desc_avail: 0 dev.ix.0.queue3.tx_packets: 77375 dev.ix.0.queue3.rxd_head: 79 dev.ix.0.queue3.rxd_tail: 78 dev.ix.0.queue3.rx_packets: 109498 dev.ix.0.queue3.rx_bytes: 109951775 dev.ix.0.queue3.lro_queued: 0 dev.ix.0.queue3.lro_flushed: 0 dev.ix.0.queue4.interrupt_rate: 10526 dev.ix.0.queue4.txd_head: 1624 dev.ix.0.queue4.txd_tail: 1624 dev.ix.0.queue4.no_desc_avail: 0 dev.ix.0.queue4.tx_packets: 39497 dev.ix.0.queue4.rxd_head: 480 dev.ix.0.queue4.rxd_tail: 479 dev.ix.0.queue4.rx_packets: 51998 dev.ix.0.queue4.rx_bytes: 21965859 dev.ix.0.queue4.lro_queued: 0 dev.ix.0.queue4.lro_flushed: 0 dev.ix.0.queue5.interrupt_rate: 1000000 dev.ix.0.queue5.txd_head: 1613 dev.ix.0.queue5.txd_tail: 1613 dev.ix.0.queue5.no_desc_avail: 0 dev.ix.0.queue5.tx_packets: 69860 dev.ix.0.queue5.rxd_head: 846 dev.ix.0.queue5.rxd_tail: 845 dev.ix.0.queue5.rx_packets: 81331 dev.ix.0.queue5.rx_bytes: 32429926 dev.ix.0.queue5.lro_queued: 0 dev.ix.0.queue5.lro_flushed: 0 dev.ix.0.queue6.interrupt_rate: 142857 dev.ix.0.queue6.txd_head: 1482 dev.ix.0.queue6.txd_tail: 1484 dev.ix.0.queue6.no_desc_avail: 0 dev.ix.0.queue6.tx_packets: 45878 dev.ix.0.queue6.rxd_head: 355 dev.ix.0.queue6.rxd_tail: 354 dev.ix.0.queue6.rx_packets: 62211 dev.ix.0.queue6.rx_bytes: 27653559 dev.ix.0.queue6.lro_queued: 0 dev.ix.0.queue6.lro_flushed: 0 dev.ix.0.queue7.interrupt_rate: 5347 dev.ix.0.queue7.txd_head: 603 dev.ix.0.queue7.txd_tail: 603 dev.ix.0.queue7.no_desc_avail: 0 dev.ix.0.queue7.tx_packets: 61997 dev.ix.0.queue7.rxd_head: 826 dev.ix.0.queue7.rxd_tail: 825 dev.ix.0.queue7.rx_packets: 83460 dev.ix.0.queue7.rx_bytes: 50183116 dev.ix.0.queue7.lro_queued: 0 dev.ix.0.queue7.lro_flushed: 0 dev.ix.0.mac_stats.crc_errs: 0 dev.ix.0.mac_stats.ill_errs: 0 dev.ix.0.mac_stats.byte_errs: 0 dev.ix.0.mac_stats.short_discards: 0 dev.ix.0.mac_stats.local_faults: 3 dev.ix.0.mac_stats.remote_faults: 1 dev.ix.0.mac_stats.rec_len_errs: 0 dev.ix.0.mac_stats.link_xon_txd: 0 dev.ix.0.mac_stats.link_xon_rcvd: 0 dev.ix.0.mac_stats.link_xoff_txd: 0 dev.ix.0.mac_stats.link_xoff_rcvd: 0 dev.ix.0.mac_stats.total_octets_rcvd: 360072702 dev.ix.0.mac_stats.good_octets_rcvd: 359999778 dev.ix.0.mac_stats.total_pkts_rcvd: 637428 dev.ix.0.mac_stats.good_pkts_rcvd: 636321 dev.ix.0.mac_stats.mcast_pkts_rcvd: 35 dev.ix.0.mac_stats.bcast_pkts_rcvd: 1411 dev.ix.0.mac_stats.rx_frames_64: 222251 dev.ix.0.mac_stats.rx_frames_65_127: 159044 dev.ix.0.mac_stats.rx_frames_128_255: 15139 dev.ix.0.mac_stats.rx_frames_256_511: 13885 dev.ix.0.mac_stats.rx_frames_512_1023: 21283 dev.ix.0.mac_stats.rx_frames_1024_1522: 204719 dev.ix.0.mac_stats.recv_undersized: 0 dev.ix.0.mac_stats.recv_fragmented: 0 dev.ix.0.mac_stats.recv_oversized: 0 dev.ix.0.mac_stats.recv_jabberd: 0 dev.ix.0.mac_stats.management_pkts_rcvd: 0 dev.ix.0.mac_stats.management_pkts_drpd: 0 dev.ix.0.mac_stats.checksum_errs: 0 dev.ix.0.mac_stats.good_octets_txd: 882467530 dev.ix.0.mac_stats.total_pkts_txd: 816387 dev.ix.0.mac_stats.good_pkts_txd: 816387 dev.ix.0.mac_stats.bcast_pkts_txd: 36 dev.ix.0.mac_stats.mcast_pkts_txd: 0 dev.ix.0.mac_stats.management_pkts_txd: 0 dev.ix.0.mac_stats.tx_frames_64: 21509 dev.ix.0.mac_stats.tx_frames_65_127: 168051 dev.ix.0.mac_stats.tx_frames_128_255: 19184 dev.ix.0.mac_stats.tx_frames_256_511: 22775 dev.ix.0.mac_stats.tx_frames_512_1023: 24222 dev.ix.0.mac_stats.tx_frames_1024_1522: 560646 dev.ix.0.mac_stats.fc_crc: 0 dev.ix.0.mac_stats.fc_last: 0 dev.ix.0.mac_stats.fc_drpd: 0 dev.ix.0.mac_stats.fc_pkts_rcvd: 0 dev.ix.0.mac_stats.fc_pkts_txd: 0 dev.ix.0.mac_stats.fc_dword_rcvd: 0 dev.ix.0.mac_stats.fc_dword_txd: 0 vmstat -i interrupt total rate irq1: atkbd0 1 0 irq6: fdc0 1 0 irq14: ata0 35 0 irq20: uhci0 1 0 irq23: ehci0 41 0 irq66: arcmsr0 66431 74 cpu0: timer 1773313 1999 irq256: ix0:que 0 99591 112 irq257: ix0:que 1 109526 123 irq258: ix0:que 2 97963 110 irq259: ix0:que 3 220346 248 irq260: ix0:que 4 85912 96 irq261: ix0:que 5 155002 174 irq262: ix0:que 6 99027 111 irq263: ix0:que 7 124176 139 irq264: ix0:link 3 0 irq270: igb1:que 0 312 0 irq271: igb1:que 1 2 0 irq274: igb1:link 2 0 cpu7: timer 1765259 1990 cpu6: timer 1765259 1990 cpu4: timer 1765260 1990 cpu5: timer 1765260 1990 cpu1: timer 1765259 1990 cpu2: timer 1765259 1990 cpu3: timer 1765260 1990 Total 15188501 17123 netstat -m 13479/5091/18570 mbufs in use (current/cache/total) 12327/4319/16646/524288 mbuf clusters in use (current/cache/total/max) 12285/1667 mbuf+clusters out of packet secondary zone in use = (current/cache) 6/506/512/262144 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 28047K/11934K/39982K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 1257 requests for I/O initiated by sendfile 0 calls to protocol drain routines netstat -i Name Mtu Network Address Ipkts Ierrs Idrop = Opkts Oerrs Coll ix0 1500 00:1b:21:7e:2e:8c 1307940 0 0 = 1708291 0 0 ix0 1500 X.X.X.0 ixhost 26195 - - = 1601162 - - igb0* 1500 00:30:48:c5:31:02 0 0 0 = 0 0 0 igb1 1500 00:30:48:c5:31:03 741 0 0 = 721 0 0 igb1 1500 10.10.10.0 10.10.10.64 679 - - = 718 - - lo0 16384 6824 0 0 = 6824 0 0 lo0 16384 fe80:4::1 fe80:4::1 0 - - = 0 - - lo0 16384 localhost ::1 0 - - = 0 - - lo0 16384 your-net localhost 26 - - = 6824 - - A ping from the cisco 6509 its connected to:- Sending 1000, 100-byte ICMP Echos to 85.236.96.64, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!! Success rate is 99 percent (996/1000), round-trip min/avg/max =3D = 1/1/208 ms Config on the cisco end:- TenGigabitEthernet9/2 is up, line protocol is up (connected) Hardware is C6k 10000Mb 802.3, address is 001e.1323.f325 (bia 001e.1323.f325) Description: ixhost (10Gbps) MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 10Gb/s input flow-control is on, output flow-control is on ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output 46w5d, output hang never Last clearing of "show interface" counters never Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: = 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 12204000 bits/sec, 1351 packets/sec 5 minute output rate 4998000 bits/sec, 1007 packets/sec 78180252111 packets input, 92996518599740 bytes, 0 no buffer Received 314449 broadcasts (0 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 51832915763 packets output, 24954526878125 bytes, 0 underruns 0 output errors, 0 collisions, 3 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out systat 1 :if /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 = /10 Load Average | Interface Traffic Peak = Total lo0 in 0.953 KB/s 1.916 KB/s 2.669 = MB out 0.953 KB/s 1.916 KB/s 2.669 = MB igb1 in 0.063 KB/s 0.128 KB/s 85.663 = KB out 0.142 KB/s 0.269 KB/s 203.177 = KB ix0 in 215.019 KB/s 679.274 KB/s 1000.871 = MB out 755.770 KB/s 1.113 MB/s 2.447 = GB Regards Steve=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This e.mail is private and confidential between Multiplay (UK) Ltd. and = the person or entity to whom it is addressed. In the event of misdirection, = the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.=20 In the event of misdirection, illegible or incomplete transmission = please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. _______________________________________________ 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" ------=_NextPart_000_00D6_01CD0077.F16AF800-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 16:04:18 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 340C2106566B for ; Mon, 12 Mar 2012 16:04:18 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B85258FC12 for ; Mon, 12 Mar 2012 16:04:16 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so3830353bkc.13 for ; Mon, 12 Mar 2012 09:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=s5c68z9rA4z+MaSFto8Sl5DV8Rgt5iYhNP4UJFQRbf0=; b=dAiCez85dLRyGqhnJojXg5fFpcxVADzlY4kGqgxmaDHfNGzuvYx1pCuQ+b85dgYZfc NKLhfQLRn+hA6gFUkAaj+3quJSAeKnP78Ti9eHwJ4z3D5XegEbZJuf9V6AvIFaiDHWqn ngZCYZ5dIU0QltflqMLDShUAuUg3BUmC52pkJ6/8oGUyxdofCjl3LQSMUDVfqPO3zxl9 VPFmpf7uTGhap5WFtZTrUS1htoUKGxaJBM4Uz2JcrIIqttKOIpVmmMBKLYXWlYWrUKyg XSQ9HTgjUCk0ErDFSo9IqIjNLqS9BlR/K4GiOPICDNbDuBZ9vI5hs8USq2aL6Bd2WXmD DblQ== MIME-Version: 1.0 Received: by 10.205.132.73 with SMTP id ht9mr595173bkc.46.1331568255742; Mon, 12 Mar 2012 09:04:15 -0700 (PDT) Received: by 10.204.230.5 with HTTP; Mon, 12 Mar 2012 09:04:15 -0700 (PDT) Date: Mon, 12 Mar 2012 09:04:15 -0700 Message-ID: From: hiren panchasara To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Use of network_interfaces in rc.conf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 16:04:18 -0000 Looking at man rc.conf, network_interfaces (str) Set to the list of network interfaces to configure o= n this host or =E2=80=9CAUTO=E2=80=9D (the default) for all = current interfaces. Setting the network_interfaces variable to anything other than the default is deprecated. Interfaces that the adminis=E2=80=90 trator wishes to store configuration for, but not start at boot should be configured with the =E2=80=9CNOAUTO=E2=80= =9D keyword in their ifconfig_=E2=9F=A8interface=E2=9F=A9 variables as describe= d below. For example, in my rc.conf I have ifconfig_em0=3D"dhcp" What difference does it make when I have each (separately) in my rc.conf: 1) no network_interfaces at all 2) network_interfaces=3D"AUTO" 3) network_interfaces=3D"em0" 4) network_interfaces=3D"NOAUTO" It seems, all but 2 are deprecated. Thanks in advance, Hiren From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 16:49:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5230C106566B for ; Mon, 12 Mar 2012 16:49:54 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forward10.mail.yandex.net (forward10.mail.yandex.net [IPv6:2a02:6b8:0:202::5]) by mx1.freebsd.org (Postfix) with ESMTP id DB7FD8FC0A for ; Mon, 12 Mar 2012 16:49:52 +0000 (UTC) Received: from smtp9.mail.yandex.net (smtp9.mail.yandex.net [77.88.61.35]) by forward10.mail.yandex.net (Yandex) with ESMTP id 702F5102186A; Mon, 12 Mar 2012 20:49:51 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1331570991; bh=LrWHJGFTL/lx5tfNCX5EkTwGFLYFbsA5OrI4CL9Y1Vs=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZQwj5hGK358dCbpeF3fbb53Nypg8Hjsqmvc7o2W+5WgeXbPLLPJULrx4rxYpSJt3h pLKGn1WD7z1QpC8bc8efoNCpDIkX4+TSG3rEatTghdxhNJK3EKDcoDvRC65JhVBUQx Ilkmz+VkytqhROO0m6tsx17/Lp+Bnut//iK+EX08= Received: from smtp9.mail.yandex.net (localhost [127.0.0.1]) by smtp9.mail.yandex.net (Yandex) with ESMTP id 48E991520508; Mon, 12 Mar 2012 20:49:51 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1331570991; bh=LrWHJGFTL/lx5tfNCX5EkTwGFLYFbsA5OrI4CL9Y1Vs=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZQwj5hGK358dCbpeF3fbb53Nypg8Hjsqmvc7o2W+5WgeXbPLLPJULrx4rxYpSJt3h pLKGn1WD7z1QpC8bc8efoNCpDIkX4+TSG3rEatTghdxhNJK3EKDcoDvRC65JhVBUQx Ilkmz+VkytqhROO0m6tsx17/Lp+Bnut//iK+EX08= Received: from unknown (unknown [77.93.52.20]) by smtp9.mail.yandex.net (nwsmtp/Yandex) with ESMTP id nfKuj3eT-noK8Mcna; Mon, 12 Mar 2012 20:49:50 +0400 Date: Mon, 12 Mar 2012 18:49:40 +0200 From: =?utf-8?B?0JrQvtC90YzQutC+0LIg0JXQstCz0LXQvdC40Lk=?= X-Mailer: The Bat! (v4.0.24) Professional Organization: =?utf-8?B?0KfQnyDQmtC+0L3RjNC60L7QsiwgRnJlZUxpbmU=?= X-Priority: 3 (Normal) Message-ID: <853549959.20120312184940@yandex.ru> To: "Steven Hartland" In-Reply-To: <18969B34B4EE402986389D5022DCCB35@multiplay.co.uk> References: <18969B34B4EE402986389D5022DCCB35@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: ixgbe interface micro stalls / slow responses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?utf-8?B?0JrQvtC90YzQutC+0LIg0JXQstCz0LXQvdC40Lk=?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 16:49:54 -0000 Здравствуйте, Steven. Вы писали 12 марта 2012 г., 17:05:12: SH> We've got a machine where with an ix interface on 8.2-RELEASE SH> which is seeing intermittent slow responses. It shows as stalls SH> on the console and is visible as high pings on an mtr SH> from a local machine e.g. SH> Packets Pings SH> Host Loss% Snt Last Avg Best Wrst StDev SH> 1. X.X.X.X 0.0% 181 0.1 117.7 0.1 2665. 314.8 SH> We've tried updating from 2.3.10 release driver + alias fix SH> to 2.4.5 (the latest from 8.3) but still the behavour is the SH> same. SH> If we do a trace to an igb on the same machine everything is SH> clean. SH> Packets Pings SH> Host Loss% Snt Last Avg Best Wrst StDev SH> 1. 10.10.10.64 0.0% 136 0.1 0.2 0.1 12.5 1.1 SH> We are seeing "RX Descriptors exceed system mbuf max, using SH> default instead!" on boot with the latest driver but the fix SH> listed in the readme has no effect, as in sysctl.conf we have SH> kern.ipc.nmbclusters=524288 SH> kern.ipc.nmbjumbop=262144 SH> Nothing looks out of the ordinary by there's definitely a SH> problem there somewhere, any ideas? SH> Detailed info which may be use below. >>From dmeg:- SH> ix0: port 0x2000-0x201f mem SH> 0xd8400000-0xd847ffff,0xd8480000-0xd8483fff irq 52 at device 0.0 on pci5 SH> ix0: Using MSIX interrupts with 9 vectors SH> ix0: RX Descriptors exceed system mbuf max, using default instead! SH> ix0: [ITHREAD] SH> ix0: [ITHREAD] SH> ix0: [ITHREAD] SH> ix0: [ITHREAD] SH> ix0: [ITHREAD] SH> ix0: [ITHREAD] SH> ix0: [ITHREAD] SH> ix0: [ITHREAD] SH> ix0: [ITHREAD] SH> ix0: Ethernet address: 00:1b:21:7e:2e:8c SH> ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 SH> pciconf -v -l SH> ix0@pci0:5:0:0: class=0x020000 card=0x00068086 chip=0x10fb8086 rev=0x01 hdr=0x00 SH> vendor = 'Intel Corporation' SH> class = network SH> subclass = ethernet SH> sysctl dev.ix SH> dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5 SH> dev.ix.0.%driver: ix SH> dev.ix.0.%location: slot=0 function=0 SH> dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 subdevice=0x0006 class=0x020000 SH> dev.ix.0.%parent: pci5 SH> dev.ix.0.fc: 3 SH> dev.ix.0.advertise_gig: 0 SH> dev.ix.0.enable_aim: 1 SH> dev.ix.0.advertise_speed: 0 SH> dev.ix.0.rx_processing_limit: 128 SH> dev.ix.0.dropped: 0 SH> dev.ix.0.mbuf_defrag_failed: 0 SH> dev.ix.0.no_tx_dma_setup: 0 SH> dev.ix.0.watchdog_events: 0 SH> dev.ix.0.tso_tx: 174470 SH> dev.ix.0.link_irq: 3 SH> dev.ix.0.queue0.interrupt_rate: 1000000 SH> dev.ix.0.queue0.txd_head: 59 SH> dev.ix.0.queue0.txd_tail: 59 SH> dev.ix.0.queue0.no_desc_avail: 0 SH> dev.ix.0.queue0.tx_packets: 38913 SH> dev.ix.0.queue0.rxd_head: 384 SH> dev.ix.0.queue0.rxd_tail: 383 SH> dev.ix.0.queue0.rx_packets: 54982 SH> dev.ix.0.queue0.rx_bytes: 36197485 SH> dev.ix.0.queue0.lro_queued: 0 SH> dev.ix.0.queue0.lro_flushed: 0 SH> dev.ix.0.queue1.interrupt_rate: 1000000 SH> dev.ix.0.queue1.txd_head: 1417 SH> dev.ix.0.queue1.txd_tail: 1417 SH> dev.ix.0.queue1.no_desc_avail: 0 SH> dev.ix.0.queue1.tx_packets: 51196 SH> dev.ix.0.queue1.rxd_head: 445 SH> dev.ix.0.queue1.rxd_tail: 444 SH> dev.ix.0.queue1.rx_packets: 70841 SH> dev.ix.0.queue1.rx_bytes: 26319740 SH> dev.ix.0.queue1.lro_queued: 0 SH> dev.ix.0.queue1.lro_flushed: 0 SH> dev.ix.0.queue2.interrupt_rate: 20408 SH> dev.ix.0.queue2.txd_head: 194 SH> dev.ix.0.queue2.txd_tail: 194 SH> dev.ix.0.queue2.no_desc_avail: 0 SH> dev.ix.0.queue2.tx_packets: 45102 SH> dev.ix.0.queue2.rxd_head: 696 SH> dev.ix.0.queue2.rxd_tail: 695 SH> dev.ix.0.queue2.rx_packets: 65107 SH> dev.ix.0.queue2.rx_bytes: 49222403 SH> dev.ix.0.queue2.lro_queued: 0 SH> dev.ix.0.queue2.lro_flushed: 0 SH> dev.ix.0.queue3.interrupt_rate: 200000 SH> dev.ix.0.queue3.txd_head: 1605 SH> dev.ix.0.queue3.txd_tail: 1605 SH> dev.ix.0.queue3.no_desc_avail: 0 SH> dev.ix.0.queue3.tx_packets: 77375 SH> dev.ix.0.queue3.rxd_head: 79 SH> dev.ix.0.queue3.rxd_tail: 78 SH> dev.ix.0.queue3.rx_packets: 109498 SH> dev.ix.0.queue3.rx_bytes: 109951775 SH> dev.ix.0.queue3.lro_queued: 0 SH> dev.ix.0.queue3.lro_flushed: 0 SH> dev.ix.0.queue4.interrupt_rate: 10526 SH> dev.ix.0.queue4.txd_head: 1624 SH> dev.ix.0.queue4.txd_tail: 1624 SH> dev.ix.0.queue4.no_desc_avail: 0 SH> dev.ix.0.queue4.tx_packets: 39497 SH> dev.ix.0.queue4.rxd_head: 480 SH> dev.ix.0.queue4.rxd_tail: 479 SH> dev.ix.0.queue4.rx_packets: 51998 SH> dev.ix.0.queue4.rx_bytes: 21965859 SH> dev.ix.0.queue4.lro_queued: 0 SH> dev.ix.0.queue4.lro_flushed: 0 SH> dev.ix.0.queue5.interrupt_rate: 1000000 SH> dev.ix.0.queue5.txd_head: 1613 SH> dev.ix.0.queue5.txd_tail: 1613 SH> dev.ix.0.queue5.no_desc_avail: 0 SH> dev.ix.0.queue5.tx_packets: 69860 SH> dev.ix.0.queue5.rxd_head: 846 SH> dev.ix.0.queue5.rxd_tail: 845 SH> dev.ix.0.queue5.rx_packets: 81331 SH> dev.ix.0.queue5.rx_bytes: 32429926 SH> dev.ix.0.queue5.lro_queued: 0 SH> dev.ix.0.queue5.lro_flushed: 0 SH> dev.ix.0.queue6.interrupt_rate: 142857 SH> dev.ix.0.queue6.txd_head: 1482 SH> dev.ix.0.queue6.txd_tail: 1484 SH> dev.ix.0.queue6.no_desc_avail: 0 SH> dev.ix.0.queue6.tx_packets: 45878 SH> dev.ix.0.queue6.rxd_head: 355 SH> dev.ix.0.queue6.rxd_tail: 354 SH> dev.ix.0.queue6.rx_packets: 62211 SH> dev.ix.0.queue6.rx_bytes: 27653559 SH> dev.ix.0.queue6.lro_queued: 0 SH> dev.ix.0.queue6.lro_flushed: 0 SH> dev.ix.0.queue7.interrupt_rate: 5347 SH> dev.ix.0.queue7.txd_head: 603 SH> dev.ix.0.queue7.txd_tail: 603 SH> dev.ix.0.queue7.no_desc_avail: 0 SH> dev.ix.0.queue7.tx_packets: 61997 SH> dev.ix.0.queue7.rxd_head: 826 SH> dev.ix.0.queue7.rxd_tail: 825 SH> dev.ix.0.queue7.rx_packets: 83460 SH> dev.ix.0.queue7.rx_bytes: 50183116 SH> dev.ix.0.queue7.lro_queued: 0 SH> dev.ix.0.queue7.lro_flushed: 0 SH> dev.ix.0.mac_stats.crc_errs: 0 SH> dev.ix.0.mac_stats.ill_errs: 0 SH> dev.ix.0.mac_stats.byte_errs: 0 SH> dev.ix.0.mac_stats.short_discards: 0 SH> dev.ix.0.mac_stats.local_faults: 3 SH> dev.ix.0.mac_stats.remote_faults: 1 SH> dev.ix.0.mac_stats.rec_len_errs: 0 SH> dev.ix.0.mac_stats.link_xon_txd: 0 SH> dev.ix.0.mac_stats.link_xon_rcvd: 0 SH> dev.ix.0.mac_stats.link_xoff_txd: 0 SH> dev.ix.0.mac_stats.link_xoff_rcvd: 0 SH> dev.ix.0.mac_stats.total_octets_rcvd: 360072702 SH> dev.ix.0.mac_stats.good_octets_rcvd: 359999778 SH> dev.ix.0.mac_stats.total_pkts_rcvd: 637428 SH> dev.ix.0.mac_stats.good_pkts_rcvd: 636321 SH> dev.ix.0.mac_stats.mcast_pkts_rcvd: 35 SH> dev.ix.0.mac_stats.bcast_pkts_rcvd: 1411 SH> dev.ix.0.mac_stats.rx_frames_64: 222251 SH> dev.ix.0.mac_stats.rx_frames_65_127: 159044 SH> dev.ix.0.mac_stats.rx_frames_128_255: 15139 SH> dev.ix.0.mac_stats.rx_frames_256_511: 13885 SH> dev.ix.0.mac_stats.rx_frames_512_1023: 21283 SH> dev.ix.0.mac_stats.rx_frames_1024_1522: 204719 SH> dev.ix.0.mac_stats.recv_undersized: 0 SH> dev.ix.0.mac_stats.recv_fragmented: 0 SH> dev.ix.0.mac_stats.recv_oversized: 0 SH> dev.ix.0.mac_stats.recv_jabberd: 0 SH> dev.ix.0.mac_stats.management_pkts_rcvd: 0 SH> dev.ix.0.mac_stats.management_pkts_drpd: 0 SH> dev.ix.0.mac_stats.checksum_errs: 0 SH> dev.ix.0.mac_stats.good_octets_txd: 882467530 SH> dev.ix.0.mac_stats.total_pkts_txd: 816387 SH> dev.ix.0.mac_stats.good_pkts_txd: 816387 SH> dev.ix.0.mac_stats.bcast_pkts_txd: 36 SH> dev.ix.0.mac_stats.mcast_pkts_txd: 0 SH> dev.ix.0.mac_stats.management_pkts_txd: 0 SH> dev.ix.0.mac_stats.tx_frames_64: 21509 SH> dev.ix.0.mac_stats.tx_frames_65_127: 168051 SH> dev.ix.0.mac_stats.tx_frames_128_255: 19184 SH> dev.ix.0.mac_stats.tx_frames_256_511: 22775 SH> dev.ix.0.mac_stats.tx_frames_512_1023: 24222 SH> dev.ix.0.mac_stats.tx_frames_1024_1522: 560646 SH> dev.ix.0.mac_stats.fc_crc: 0 SH> dev.ix.0.mac_stats.fc_last: 0 SH> dev.ix.0.mac_stats.fc_drpd: 0 SH> dev.ix.0.mac_stats.fc_pkts_rcvd: 0 SH> dev.ix.0.mac_stats.fc_pkts_txd: 0 SH> dev.ix.0.mac_stats.fc_dword_rcvd: 0 SH> dev.ix.0.mac_stats.fc_dword_txd: 0 SH> vmstat -i SH> interrupt total rate SH> irq1: atkbd0 1 0 SH> irq6: fdc0 1 0 SH> irq14: ata0 35 0 SH> irq20: uhci0 1 0 SH> irq23: ehci0 41 0 SH> irq66: arcmsr0 66431 74 SH> cpu0: timer 1773313 1999 SH> irq256: ix0:que 0 99591 112 SH> irq257: ix0:que 1 109526 123 SH> irq258: ix0:que 2 97963 110 SH> irq259: ix0:que 3 220346 248 SH> irq260: ix0:que 4 85912 96 SH> irq261: ix0:que 5 155002 174 SH> irq262: ix0:que 6 99027 111 SH> irq263: ix0:que 7 124176 139 SH> irq264: ix0:link 3 0 SH> irq270: igb1:que 0 312 0 SH> irq271: igb1:que 1 2 0 SH> irq274: igb1:link 2 0 SH> cpu7: timer 1765259 1990 SH> cpu6: timer 1765259 1990 SH> cpu4: timer 1765260 1990 SH> cpu5: timer 1765260 1990 SH> cpu1: timer 1765259 1990 SH> cpu2: timer 1765259 1990 SH> cpu3: timer 1765260 1990 SH> Total 15188501 17123 SH> netstat -m SH> 13479/5091/18570 mbufs in use (current/cache/total) SH> 12327/4319/16646/524288 mbuf clusters in use (current/cache/total/max) SH> 12285/1667 mbuf+clusters out of packet secondary zone in use (current/cache) SH> 6/506/512/262144 4k (page size) jumbo clusters in use (current/cache/total/max) SH> 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) SH> 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) SH> 28047K/11934K/39982K bytes allocated to network (current/cache/total) SH> 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) SH> 0/0/0 requests for jumbo clusters denied (4k/9k/16k) SH> 0/0/0 sfbufs in use (current/peak/max) SH> 0 requests for sfbufs denied SH> 0 requests for sfbufs delayed SH> 1257 requests for I/O initiated by sendfile SH> 0 calls to protocol drain routines SH> netstat -i SH> Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll SH> ix0 1500 00:1b:21:7e:2e:8c 1307940 0 0 1708291 0 0 SH> ix0 1500 X.X.X.0 ixhost 26195 - - 1601162 - - SH> igb0* 1500 00:30:48:c5:31:02 0 0 0 0 0 0 SH> igb1 1500 00:30:48:c5:31:03 741 0 0 721 0 0 SH> igb1 1500 10.10.10.0 10.10.10.64 679 - - 718 - - SH> lo0 16384 6824 0 0 6824 0 0 SH> lo0 16384 fe80:4::1 fe80:4::1 0 - - 0 - - SH> lo0 16384 localhost ::1 0 - - 0 - - SH> lo0 16384 your-net localhost 26 - - 6824 - - SH> A ping from the cisco 6509 its connected to:- SH> Sending 1000, 100-byte ICMP Echos to 85.236.96.64, timeout is 2 seconds: SH> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SH> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SH> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!! SH> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SH> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SH> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!! SH> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SH> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SH> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SH> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SH> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SH> !!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SH> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SH> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SH> !!!!!!!!!!!!!!!!!!!! SH> Success rate is 99 percent (996/1000), round-trip min/avg/max = 1/1/208 ms SH> Config on the cisco end:- SH> TenGigabitEthernet9/2 is up, line protocol is up (connected) SH> Hardware is C6k 10000Mb 802.3, address is 001e.1323.f325 (bia 001e.1323.f325) SH> Description: ixhost (10Gbps) SH> MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec, SH> reliability 255/255, txload 1/255, rxload 1/255 SH> Encapsulation ARPA, loopback not set SH> Keepalive set (10 sec) SH> Full-duplex, 10Gb/s SH> input flow-control is on, output flow-control is on SH> ARP type: ARPA, ARP Timeout 04:00:00 SH> Last input never, output 46w5d, output hang never SH> Last clearing of "show interface" counters never SH> Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0 SH> Queueing strategy: fifo SH> Output queue: 0/40 (size/max) SH> 5 minute input rate 12204000 bits/sec, 1351 packets/sec SH> 5 minute output rate 4998000 bits/sec, 1007 packets/sec SH> 78180252111 packets input, 92996518599740 bytes, 0 no buffer SH> Received 314449 broadcasts (0 multicasts) SH> 0 runts, 0 giants, 0 throttles SH> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored SH> 0 watchdog, 0 multicast, 0 pause input SH> 0 input packets with dribble condition detected SH> 51832915763 packets output, 24954526878125 bytes, 0 underruns SH> 0 output errors, 0 collisions, 3 interface resets SH> 0 babbles, 0 late collision, 0 deferred SH> 0 lost carrier, 0 no carrier, 0 PAUSE output SH> 0 output buffer failures, 0 output buffers swapped out SH> systat 1 :if SH> /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10 SH> Load Average | SH> Interface Traffic Peak Total SH> lo0 in 0.953 KB/s 1.916 KB/s 2.669 MB SH> out 0.953 KB/s 1.916 KB/s 2.669 MB SH> igb1 in 0.063 KB/s 0.128 KB/s 85.663 KB SH> out 0.142 KB/s 0.269 KB/s 203.177 KB SH> ix0 in 215.019 KB/s 679.274 KB/s 1000.871 MB SH> out 755.770 KB/s 1.113 MB/s 2.447 GB SH> Regards SH> Steve can you show netstat -Q ? -- С уважением, Коньков mailto:kes-kes@yandex.ru From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 17:50:12 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 560FB1065670 for ; Mon, 12 Mar 2012 17:50:12 +0000 (UTC) (envelope-from prvs=1418b75531=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id DD34F8FC16 for ; Mon, 12 Mar 2012 17:50:11 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Mon, 12 Mar 2012 17:50:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50018603127.msg for ; Mon, 12 Mar 2012 17:50:09 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1418b75531=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <2B4507129C2141BC9D12B6F7BE5987B3@multiplay.co.uk> From: "Steven Hartland" To: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= References: <18969B34B4EE402986389D5022DCCB35@multiplay.co.uk> <853549959.20120312184940@yandex.ru> Date: Mon, 12 Mar 2012 17:50:04 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1251"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-net@freebsd.org Subject: Re: ixgbe interface micro stalls / slow responses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 17:50:12 -0000 ----- Original Message ----- From: "Коньков Евгений" Apparently not:- > > can you show netstat -Q ? > netstat -Q netstat: illegal option -- Q ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 18:22:06 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1E90106566B for ; Mon, 12 Mar 2012 18:22:06 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forward1.mail.yandex.net (forward1.mail.yandex.net [IPv6:2a02:6b8:0:602::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4B5CA8FC29 for ; Mon, 12 Mar 2012 18:22:06 +0000 (UTC) Received: from smtp2.mail.yandex.net (smtp2.mail.yandex.net [77.88.46.102]) by forward1.mail.yandex.net (Yandex) with ESMTP id 5096E12415C7; Mon, 12 Mar 2012 22:21:48 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1331576508; bh=oxUXPqwYJ/BEGcCKVyokqgH6fx37+wf3ANL6+bkiB7I=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wB51hJXDLvFuQmjsBKD9tjk3kzhbn+p/i7WHA+ZdU2XGP5IebxRl+A++kgxRHtN1V CVZlSf9HFhGHFIjLJdOLzBjvrUd/GnxKDCoR2//qx02phOLtaYTIE+RyGHT3sq7zQ0 9I+wOI3ammD6uRhQkiQdYUVCugq7aL7meoX47zY8= Received: from smtp2.mail.yandex.net (localhost [127.0.0.1]) by smtp2.mail.yandex.net (Yandex) with ESMTP id 28BBEE20400; Mon, 12 Mar 2012 22:21:48 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1331576508; bh=oxUXPqwYJ/BEGcCKVyokqgH6fx37+wf3ANL6+bkiB7I=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wB51hJXDLvFuQmjsBKD9tjk3kzhbn+p/i7WHA+ZdU2XGP5IebxRl+A++kgxRHtN1V CVZlSf9HFhGHFIjLJdOLzBjvrUd/GnxKDCoR2//qx02phOLtaYTIE+RyGHT3sq7zQ0 9I+wOI3ammD6uRhQkiQdYUVCugq7aL7meoX47zY8= Received: from unknown (unknown [77.93.52.20]) by smtp2.mail.yandex.net (nwsmtp/Yandex) with ESMTP id Lcv4S0qP-LlvGxNHJ; Mon, 12 Mar 2012 22:21:47 +0400 Date: Mon, 12 Mar 2012 20:21:36 +0200 From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= X-Mailer: The Bat! (v4.0.24) Professional Organization: =?windows-1251?B?188gyu7t/Oru4iwgRnJlZUxpbmU=?= X-Priority: 3 (Normal) Message-ID: <50980382.20120312202136@yandex.ru> To: "Steven Hartland" In-Reply-To: <2B4507129C2141BC9D12B6F7BE5987B3@multiplay.co.uk> References: <18969B34B4EE402986389D5022DCCB35@multiplay.co.uk> <853549959.20120312184940@yandex.ru> <2B4507129C2141BC9D12B6F7BE5987B3@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re[2]: ixgbe interface micro stalls / slow responses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 18:22:07 -0000 >> can you show netstat -Q ? >> netstat -Q SH> netstat: illegal option -- Q uname -a From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 18:56:42 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7554A1065686 for ; Mon, 12 Mar 2012 18:56:42 +0000 (UTC) (envelope-from prvs=1418b75531=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 078F38FC0A for ; Mon, 12 Mar 2012 18:56:41 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Mon, 12 Mar 2012 18:56:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50018607527.msg for ; Mon, 12 Mar 2012 18:56:39 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1418b75531=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <86016A34935443C383B3EE08F3D4292D@multiplay.co.uk> From: "Steven Hartland" To: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= References: <18969B34B4EE402986389D5022DCCB35@multiplay.co.uk> <853549959.20120312184940@yandex.ru> <2B4507129C2141BC9D12B6F7BE5987B3@multiplay.co.uk> <50980382.20120312202136@yandex.ru> Date: Mon, 12 Mar 2012 18:56:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1251"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-net@freebsd.org Subject: Re: Re[2]: ixgbe interface micro stalls / slow responses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 18:56:42 -0000 ----- Original Message ----- From: "Коньков Евгений" To: "Steven Hartland" Cc: Sent: Monday, March 12, 2012 6:21 PM Subject: Re[2]: ixgbe interface micro stalls / slow responses >>> can you show netstat -Q ? > >>> netstat -Q > SH> netstat: illegal option -- Q > > uname -a As mentioned 8.2-RELEASE specifically -p6 with a few additional local patches. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 19:14:10 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86F501065672 for ; Mon, 12 Mar 2012 19:14:10 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3E08F8FC08 for ; Mon, 12 Mar 2012 19:14:09 +0000 (UTC) Received: by vcmm1 with SMTP id m1so5659832vcm.13 for ; Mon, 12 Mar 2012 12:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KjXUD3cFLeJznaaXV0zf6vleJM5AKbF81abjnUVPduw=; b=uUOmm+oxZUE6mDuVLmg3kUREfpnUKRryD3Lsb0LyiEZybU+Y+1f0ii9C9fIUT8wACe Ozg+CcKOWr4mB99jIqC4oWPy7TGZPWv6+ilBsHxDoj7bxXRNu7+U5aZjZM6p2WCE5iIG syZdR0KckFvY/gXOLTNGpf0+qHK+FMmatymBWx4LN85JP5hn91F0q6Oz7lEM05S+VCzx NbV25BTOYmFEoShs0I69Gxaw4lQYQNvlP2I/36HqQ/IEwyZJhBfJhaNy6dp2IfmM33MB koL0vBk8ZqUCcDn+pRBc6OvfibQZbXzspwcYwOeE3W0dVh9OkbSN0MoBRVCW3+QhmdqD 7YZQ== MIME-Version: 1.0 Received: by 10.52.70.209 with SMTP id o17mr15699843vdu.11.1331579649507; Mon, 12 Mar 2012 12:14:09 -0700 (PDT) Received: by 10.220.215.8 with HTTP; Mon, 12 Mar 2012 12:14:09 -0700 (PDT) In-Reply-To: <86016A34935443C383B3EE08F3D4292D@multiplay.co.uk> References: <18969B34B4EE402986389D5022DCCB35@multiplay.co.uk> <853549959.20120312184940@yandex.ru> <2B4507129C2141BC9D12B6F7BE5987B3@multiplay.co.uk> <50980382.20120312202136@yandex.ru> <86016A34935443C383B3EE08F3D4292D@multiplay.co.uk> Date: Mon, 12 Mar 2012 12:14:09 -0700 Message-ID: From: Jack Vogel To: Steven Hartland Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, =?KOI8-R?B?68/O2MvP1yDl18fFzsnK?= Subject: Re: Re[2]: ixgbe interface micro stalls / slow responses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 19:14:10 -0000 Well, first thing to do is try the latest code, which is now in the 8.3 stream. Jack 2012/3/12 Steven Hartland > ----- Original Message ----- From: "=EB=CF=CE=D8=CB=CF=D7 =E5=D7=C7=C5=CE= =C9=CA" > To: "Steven Hartland" > Cc: > Sent: Monday, March 12, 2012 6:21 PM > Subject: Re[2]: ixgbe interface micro stalls / slow responses > > > > can you show netstat -Q ? >>>> >>> >> netstat -Q >>>> >>> SH> netstat: illegal option -- Q >> >> uname -a >> > > As mentioned 8.2-RELEASE specifically -p6 with a few additional local > patches. > > Regards > Steve > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D**=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This e.mail is private and confidential between Multiplay (UK) Ltd. and > the person or entity to whom it is addressed. In the event of misdirectio= n, > the recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > > ______________________________**_________________ > 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 Mon Mar 12 19:31:16 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62639106566C for ; Mon, 12 Mar 2012 19:31:16 +0000 (UTC) (envelope-from prvs=1418b75531=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id DB3688FC08 for ; Mon, 12 Mar 2012 19:31:15 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Mon, 12 Mar 2012 19:31:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50018609731.msg for ; Mon, 12 Mar 2012 19:31:01 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1418b75531=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <2ABAFC6511784968A02D9580D8EB2AE7@multiplay.co.uk> From: "Steven Hartland" To: "Jack Vogel" References: <18969B34B4EE402986389D5022DCCB35@multiplay.co.uk><853549959.20120312184940@yandex.ru><2B4507129C2141BC9D12B6F7BE5987B3@multiplay.co.uk><50980382.20120312202136@yandex.ru><86016A34935443C383B3EE08F3D4292D@multiplay.co.uk> Date: Mon, 12 Mar 2012 19:30:55 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Content-Type: text/plain; charset="KOI8-R" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, =?KOI8-R?B?68/O2MvP1yDl18fFzsnK?= Subject: Re: Re[2]: ixgbe interface micro stalls / slow responses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 19:31:16 -0000 If your referring to driver code, as mentioned in my initial post, already tried that, no change :( ----- Original Message -----=20 From: Jack Vogel=20 To: Steven Hartland=20 Cc: =EB=CF=CE=D8=CB=CF=D7 =E5=D7=C7=C5=CE=C9=CA ; freebsd-net@freebsd.org=20 Sent: Monday, March 12, 2012 7:14 PM Subject: Re: Re[2]: ixgbe interface micro stalls / slow responses Well, first thing to do is try the latest code, which is now in the 8.3 stream. Jack =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.=20 In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 20:11:07 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E8211065673 for ; Mon, 12 Mar 2012 20:11:07 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id BF7B78FC16 for ; Mon, 12 Mar 2012 20:11:06 +0000 (UTC) Received: by wern13 with SMTP id n13so2354747wer.13 for ; Mon, 12 Mar 2012 13:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=95yFmZFQaFrfeCR3jEnplaA47pnRmOl5lkam3IDZcFc=; b=gq2y0H9XfI4QFSsmKo8gHQy3oDE+jge8QrEUBkFrgy+UojAB1vHQZn2ScSoy6yeCbk DxLRDPttViN+DHGrzkrui4HB6YfAFBAzturVlTw2AXv307qumLeJNRPtoeqWG/ukajX3 yLtImzfUxmTvjjVe1cOIW84biQVo7tMSKj1voJsmYlmr/5ftUXSZbItGmir1Ixj0P2iE bb6S1eYqcMdIPOAcGeXZAUW79ivIIat+xIbYde1xecdMJ4p9V4ce/YzVxNN4R5M1NsGe KSh2dH7eJtRunASbCCkJLA+6D1/x/biXG33PHihBo63VA2xACPK60WRbtV45shV85lAN p9gA== MIME-Version: 1.0 Received: by 10.52.23.199 with SMTP id o7mr15730103vdf.79.1331583065254; Mon, 12 Mar 2012 13:11:05 -0700 (PDT) Received: by 10.220.215.8 with HTTP; Mon, 12 Mar 2012 13:11:05 -0700 (PDT) In-Reply-To: <2ABAFC6511784968A02D9580D8EB2AE7@multiplay.co.uk> References: <18969B34B4EE402986389D5022DCCB35@multiplay.co.uk> <853549959.20120312184940@yandex.ru> <2B4507129C2141BC9D12B6F7BE5987B3@multiplay.co.uk> <50980382.20120312202136@yandex.ru> <86016A34935443C383B3EE08F3D4292D@multiplay.co.uk> <2ABAFC6511784968A02D9580D8EB2AE7@multiplay.co.uk> Date: Mon, 12 Mar 2012 13:11:05 -0700 Message-ID: From: Jack Vogel To: Steven Hartland Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, =?KOI8-R?B?68/O2MvP1yDl18fFzsnK?= Subject: Re: Re[2]: ixgbe interface micro stalls / slow responses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 20:11:07 -0000 Have you gotten rid of the rx descriptors exceeded problem? Jack 2012/3/12 Steven Hartland > ** > If your referring to driver code, as mentioned in my initial post, alread= y > tried that, no change :( > > ----- Original Message ----- > *From:* Jack Vogel > *To:* Steven Hartland > *Cc:* =EB=CF=CE=D8=CB=CF=D7 =E5=D7=C7=C5=CE=C9=CA ; f= reebsd-net@freebsd.org > *Sent:* Monday, March 12, 2012 7:14 PM > *Subject:* Re: Re[2]: ixgbe interface micro stalls / slow responses > > Well, first thing to do is try the latest code, which is now in the 8.3 > stream. > > Jack > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This e.mail is private and confidential between Multiplay (UK) Ltd. and > the person or entity to whom it is addressed. In the event of misdirectio= n, > the recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 20:20:35 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D2A31065672 for ; Mon, 12 Mar 2012 20:20:35 +0000 (UTC) (envelope-from prvs=1418b75531=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id BC61A8FC08 for ; Mon, 12 Mar 2012 20:20:34 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Mon, 12 Mar 2012 20:20:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50018612862.msg for ; Mon, 12 Mar 2012 20:20:32 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1418b75531=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: From: "Steven Hartland" To: "Jack Vogel" References: <18969B34B4EE402986389D5022DCCB35@multiplay.co.uk><853549959.20120312184940@yandex.ru><2B4507129C2141BC9D12B6F7BE5987B3@multiplay.co.uk><50980382.20120312202136@yandex.ru><86016A34935443C383B3EE08F3D4292D@multiplay.co.uk><2ABAFC6511784968A02D9580D8EB2AE7@multiplay.co.uk> Date: Mon, 12 Mar 2012 20:20:27 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Content-Type: text/plain; charset="KOI8-R" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, =?KOI8-R?B?68/O2MvP1yDl18fFzsnK?= Subject: Re: Re[2]: ixgbe interface micro stalls / slow responses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 20:20:35 -0000 Looks like nmbclusters sysctl changes need to loader.conf so they are available early enough for the driver. We haven't rebooted to test that yet as the machine is under so little network load I wouldn't expect raising it from 1024 to 2048 RX descriptors to make any real difference, what do you recon? =20 Regards Steve ----- Original Message -----=20 From: Jack Vogel=20 To: Steven Hartland=20 Cc: =EB=CF=CE=D8=CB=CF=D7 =E5=D7=C7=C5=CE=C9=CA ; freebsd-net@freebsd.org=20 Sent: Monday, March 12, 2012 8:11 PM Subject: Re: Re[2]: ixgbe interface micro stalls / slow responses Have you gotten rid of the rx descriptors exceeded problem? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.=20 In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 20:32:02 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77F631065673; Mon, 12 Mar 2012 20:32:02 +0000 (UTC) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5035F8FC14; Mon, 12 Mar 2012 20:32:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2CKW2La004447; Mon, 12 Mar 2012 20:32:02 GMT (envelope-from andre@freefall.freebsd.org) Received: (from andre@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2CKW2lv004441; Mon, 12 Mar 2012 20:32:02 GMT (envelope-from andre) Date: Mon, 12 Mar 2012 20:32:02 GMT Message-Id: <201203122032.q2CKW2lv004441@freefall.freebsd.org> To: andre@FreeBSD.org, freebsd-net@FreeBSD.org, andre@FreeBSD.org From: andre@FreeBSD.org Cc: Subject: Re: kern/165879: [tcp] Syncache syncache.count overflow X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 20:32:02 -0000 Synopsis: [tcp] Syncache syncache.count overflow Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Mon Mar 12 20:31:34 UTC 2012 Responsible-Changed-Why: Snatch up. http://www.freebsd.org/cgi/query-pr.cgi?pr=165879 From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 20:32:09 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E796106566C for ; Mon, 12 Mar 2012 20:32:09 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mx1.freebsd.org (Postfix) with ESMTP id B92BA8FC19 for ; Mon, 12 Mar 2012 20:32:08 +0000 (UTC) Received: by wibhr17 with SMTP id hr17so3751507wib.1 for ; Mon, 12 Mar 2012 13:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LJeajDMbnjcP8zp6Mt5nRpL7tRGmlnhT1Vl+jmZ9Ri8=; b=sTckswFVYRTUOutsb6zPp27wy4XKh44g49UQGRiqge4nmXphZ8pPHy+dF6s0M6dlRS 0SX7qsrddvaTzZd8rMehEVE4iH94OmoOmZv5RjM4hKOI3XQvFyhfvbxjKJQ8M64vcyKg b8auFsSVWDAfAlysDIxOjudMB8bc7NYxoDy7w0IWPK+4Mia5U1Zy6qAzg2gaY9ym7ljC FJ9TIMi3Z/SnfhVMzSBE+jV4aU1XijKREj1dMuPJZ2Ds0jeYUX+EqB87rKFVUQllAA8l tMQUsfmm4tHPrSFbRFlhB1XppHaybvbBnrkUH5Z/H5T3fMalYz8AnfGz4QFEg+zOwmCH 5B+g== MIME-Version: 1.0 Received: by 10.180.99.65 with SMTP id eo1mr1041066wib.13.1331584327643; Mon, 12 Mar 2012 13:32:07 -0700 (PDT) Received: by 10.180.82.168 with HTTP; Mon, 12 Mar 2012 13:32:07 -0700 (PDT) In-Reply-To: References: <18969B34B4EE402986389D5022DCCB35@multiplay.co.uk> <853549959.20120312184940@yandex.ru> <2B4507129C2141BC9D12B6F7BE5987B3@multiplay.co.uk> <50980382.20120312202136@yandex.ru> <86016A34935443C383B3EE08F3D4292D@multiplay.co.uk> <2ABAFC6511784968A02D9580D8EB2AE7@multiplay.co.uk> Date: Mon, 12 Mar 2012 13:32:07 -0700 Message-ID: From: Jack Vogel To: Steven Hartland Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, =?KOI8-R?B?68/O2MvP1yDl18fFzsnK?= Subject: Re: Re[2]: ixgbe interface micro stalls / slow responses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 20:32:09 -0000 I don't know what to make of it right now, i would suggest going minimal, meaning go to a single queue and see what the behavior is. Jack 2012/3/12 Steven Hartland > ** > Looks like nmbclusters sysctl changes need to loader.conf so they are > available early enough for the driver. > > We haven't rebooted to test that yet as the machine is under so little > network load I wouldn't expect raising it from 1024 to 2048 RX descriptor= s > to make any real difference, what do you recon? > > Regards > Steve > > ----- Original Message ----- > *From:* Jack Vogel > *To:* Steven Hartland > *Cc:* =EB=CF=CE=D8=CB=CF=D7 =E5=D7=C7=C5=CE=C9=CA ; f= reebsd-net@freebsd.org > *Sent:* Monday, March 12, 2012 8:11 PM > *Subject:* Re: Re[2]: ixgbe interface micro stalls / slow responses > > Have you gotten rid of the rx descriptors exceeded problem? > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This e.mail is private and confidential between Multiplay (UK) Ltd. and > the person or entity to whom it is addressed. In the event of misdirectio= n, > the recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 20:52:10 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C87D106566B; Mon, 12 Mar 2012 20:52:10 +0000 (UTC) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 50D3D8FC1B; Mon, 12 Mar 2012 20:52:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2CKqAct024844; Mon, 12 Mar 2012 20:52:10 GMT (envelope-from andre@freefall.freebsd.org) Received: (from andre@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2CKqAI3024840; Mon, 12 Mar 2012 20:52:10 GMT (envelope-from andre) Date: Mon, 12 Mar 2012 20:52:10 GMT Message-Id: <201203122052.q2CKqAI3024840@freefall.freebsd.org> To: andre@FreeBSD.org, freebsd-net@FreeBSD.org, andre@FreeBSD.org From: andre@FreeBSD.org Cc: Subject: Re: kern/159795: [tcp] excessive duplicate ACKs and TCP session freezes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 20:52:10 -0000 Synopsis: [tcp] excessive duplicate ACKs and TCP session freezes Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Mon Mar 12 20:51:45 UTC 2012 Responsible-Changed-Why: Snatch up. http://www.freebsd.org/cgi/query-pr.cgi?pr=159795 From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 20:59:14 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E153106567D for ; Mon, 12 Mar 2012 20:59:14 +0000 (UTC) (envelope-from prvs=1418b75531=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id F1A2D8FC16 for ; Mon, 12 Mar 2012 20:59:13 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Mon, 12 Mar 2012 20:59:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50018615245.msg for ; Mon, 12 Mar 2012 20:59:09 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1418b75531=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: From: "Steven Hartland" To: "Jack Vogel" References: <18969B34B4EE402986389D5022DCCB35@multiplay.co.uk><853549959.20120312184940@yandex.ru><2B4507129C2141BC9D12B6F7BE5987B3@multiplay.co.uk><50980382.20120312202136@yandex.ru><86016A34935443C383B3EE08F3D4292D@multiplay.co.uk><2ABAFC6511784968A02D9580D8EB2AE7@multiplay.co.uk> Date: Mon, 12 Mar 2012 20:59:05 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Content-Type: text/plain; charset="KOI8-R" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, =?KOI8-R?B?68/O2MvP1yDl18fFzsnK?= Subject: Re: Re[2]: ixgbe interface micro stalls / slow responses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 20:59:14 -0000 Will give that a go tomorrow morning thanks :) Regards Steve ----- Original Message -----=20 From: Jack Vogel=20 To: Steven Hartland=20 Cc: =EB=CF=CE=D8=CB=CF=D7 =E5=D7=C7=C5=CE=C9=CA ; freebsd-net@freebsd.org=20 Sent: Monday, March 12, 2012 8:32 PM Subject: Re: Re[2]: ixgbe interface micro stalls / slow responses I don't know what to make of it right now, i would suggest going minimal, meaning go to a single queue and see what the behavior is.=20 Jack 2012/3/12 Steven Hartland Looks like nmbclusters sysctl changes need to loader.conf so they are available early enough for the driver. We haven't rebooted to test that yet as the machine is under so little network load I wouldn't expect raising it from 1024 to 2048 RX descriptors to make any real difference, what do you recon? =20 Regards Steve ----- Original Message -----=20 From: Jack Vogel=20 To: Steven Hartland=20 Cc: =EB=CF=CE=D8=CB=CF=D7 =E5=D7=C7=C5=CE=C9=CA ; freebsd-net@freebsd.org=20 Sent: Monday, March 12, 2012 8:11 PM Subject: Re: Re[2]: ixgbe interface micro stalls / slow responses Have you gotten rid of the rx descriptors exceeded problem? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.=20 In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.=20 In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 21:08:37 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D9DDF106568E for ; Mon, 12 Mar 2012 21:08:37 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3A8B78FC18 for ; Mon, 12 Mar 2012 21:08:37 +0000 (UTC) Received: (qmail 34430 invoked from network); 12 Mar 2012 19:14:37 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Mar 2012 19:14:37 -0000 Message-ID: <4F5E643D.3010006@freebsd.org> Date: Mon, 12 Mar 2012 22:01:49 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Mikolaj Golub References: <86ehzwwt6a.fsf@kopusha.home.net> <86r53uhibq.fsf@kopusha.home.net> <4F566A8A.3080607@freebsd.org> <86boo78itm.fsf@kopusha.home.net> In-Reply-To: <86boo78itm.fsf@kopusha.home.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-net@freebsd.org, Pawel Jakub Dawidek Subject: Re: soreceive_stream: mbuf leak if called with mp0 and MSG_WAITALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 21:08:37 -0000 On 08.03.2012 11:53, Mikolaj Golub wrote: > Hi, > > On Tue, 06 Mar 2012 20:50:34 +0100 Andre Oppermann wrote: > > AO> On 05.09.2011 21:58, Mikolaj Golub wrote: > >> > >> On Sun, 04 Sep 2011 12:30:53 +0300 Mikolaj Golub wrote: > >> > >> MG> Apparently soreceive_stream() has an issue if it is called to receive data as a > >> MG> mbuf chain (by supplying an non zero mbuf **mp0) and with MSG_WAITALL set. > >> > >> MG> I ran into this issue with smbfs, which uses soreceive() exactly in this way > >> MG> (see netsmb/smb_trantcp.c:nbssn_recv()). > >> > >> Stressing smbfs a little I also observed the following soreceive_stream() > >> related panic: > > AO> Hi Mikolaj, > > AO> thank you very much for testing, reporting and fixing bugs in soreceive_stream(). > > AO> I've altered your proposed patches a bit and committed them into my workqueue > AO> with the following revisions: > > AO> http://svn.freebsd.org/changeset/base/232617 > AO> http://svn.freebsd.org/changeset/base/232618 > > AO> Would you mind testing them again before they go into HEAD? > > With this patch smb mount fails with the error: > > smb_iod_recvall: tran return NULL without error > > AO> Index: sys/kern/uipc_socket.c > AO> =================================================================== > AO> --- sys/kern/uipc_socket.c (revision 232616) > AO> +++ sys/kern/uipc_socket.c (revision 232617) > AO> @@ -2044,7 +2044,7 @@ deliver: > AO> if (mp0 != NULL) { > AO> /* Dequeue as many mbufs as possible. */ > AO> if (!(flags& MSG_PEEK)&& len>= sb->sb_mb->m_len) { > AO> - for (*mp0 = m = sb->sb_mb; > AO> + for (m = sb->sb_mb; > AO> m != NULL&& m->m_len<= len; > AO> m = m->m_next) { > AO> len -= m->m_len; > AO> @@ -2052,10 +2052,15 @@ deliver: > AO> sbfree(sb, m); > AO> n = m; > AO> } > AO> + n->m_next = NULL; > AO> sb->sb_mb = m; > AO> + sb->sb_lastrecord = sb->sb_mb; > AO> if (sb->sb_mb == NULL) > AO> SB_EMPTY_FIXUP(sb); > AO> - n->m_next = NULL; > AO> + if (*mp0 != NULL) > AO> + m_cat(*mp0, m); > AO> + else > AO> + *mp0 = m; > AO> } > > At that moment m points to the end of the chain. Shouldn't *mp0 be set to > sb->sb_mb before the "for" loop? Yes, doesn't compute this way. I've put in your fix in this revision: http://svn.freebsd.org/changeset/base/232867 -- Andre > AO> /* Copy the remainder. */ > AO> if (len> 0) { > AO> @@ -2066,9 +2071,9 @@ deliver: > AO> if (m == NULL) > AO> len = 0; /* Don't flush data from sockbuf. */ > AO> else > AO> - uio->uio_resid -= m->m_len; > AO> + uio->uio_resid -= len; > AO> if (*mp0 != NULL) > AO> - n->m_next = m; > AO> + m_cat(*mp0, m); > AO> else > AO> *mp0 = m; > AO> if (*mp0 == NULL) { > AO> > From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 23:33:06 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CD9B106564A for ; Mon, 12 Mar 2012 23:33:06 +0000 (UTC) (envelope-from david.somayajulu@qlogic.com) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by mx1.freebsd.org (Postfix) with ESMTP id 45E9C8FC08 for ; Mon, 12 Mar 2012 23:33:05 +0000 (UTC) Received: from mail185-tx2-R.bigfish.com (10.9.14.236) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Mon, 12 Mar 2012 23:02:45 +0000 Received: from mail185-tx2 (localhost [127.0.0.1]) by mail185-tx2-R.bigfish.com (Postfix) with ESMTP id D5E2D220347; Mon, 12 Mar 2012 23:02:45 +0000 (UTC) X-SpamScore: -12 X-BigFish: VPS-12(zz9371I542M1432Nzz1202hzz8275bh8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:198.70.193.61; KIP:(null); UIP:(null); IPV:NLI; H:avexcashub1.qlogic.com; RD:avexcashub1.qlogic.com; EFVD:NLI Received-SPF: pass (mail185-tx2: domain of qlogic.com designates 198.70.193.61 as permitted sender) client-ip=198.70.193.61; envelope-from=david.somayajulu@qlogic.com; helo=avexcashub1.qlogic.com ; 1.qlogic.com ; Received: from mail185-tx2 (localhost.localdomain [127.0.0.1]) by mail185-tx2 (MessageSwitch) id 1331593363593464_28233; Mon, 12 Mar 2012 23:02:43 +0000 (UTC) Received: from TX2EHSMHS017.bigfish.com (unknown [10.9.14.244]) by mail185-tx2.bigfish.com (Postfix) with ESMTP id 89A1EC00AE; Mon, 12 Mar 2012 23:02:43 +0000 (UTC) Received: from avexcashub1.qlogic.com (198.70.193.61) by TX2EHSMHS017.bigfish.com (10.9.99.117) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 12 Mar 2012 23:02:43 +0000 Received: from avexmb1.qlogic.org ([fe80::9545:3a4f:c131:467d]) by avexcashub1.qlogic.org ([::1]) with mapi; Mon, 12 Mar 2012 16:02:41 -0700 From: David Somayajulu To: Dan Nelson Date: Mon, 12 Mar 2012 16:02:40 -0700 Thread-Topic: iSCSI Target For Freebsd Thread-Index: Acz+DCeuR/qj8R5CSq+7J1TdPH3suQCl+t1g Message-ID: <75E1A2A7D185F841A975979B0906BBA67C79E3F6A1@AVEXMB1.qlogic.org> References: <75E1A2A7D185F841A975979B0906BBA67C79E3F37F@AVEXMB1.qlogic.org> <20120309154844.GD42750@dan.emsphone.com> In-Reply-To: <20120309154844.GD42750@dan.emsphone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: qlogic.com Cc: "freebsd-net@freebsd.org" Subject: RE: iSCSI Target For Freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 23:33:06 -0000 Thanks Dan. I have managed to get istgt working. I was trying use without C= HAP. I thought if I set "AuthMethod to Auto" in istgt.conf it would be suff= icient. However I had to comment out the netmask line under [InitiatorGrou= p1] as well. Cheers David S. -----Original Message----- From: Dan Nelson [mailto:dnelson@allantgroup.com] Sent: Friday, March 09, 2012 7:49 AM To: David Somayajulu Cc: freebsd-net@freebsd.org Subject: Re: iSCSI Target For Freebsd In the last episode (Mar 08), David Somayajulu said: > Is there are an iSCSI Software Target that you can recommend. I have > tried using istgt ( on Freebsd7.2) with Windows iSCSI Software > Initiator. The initiator is able to discover the target however it is > unable to login to the target. > > The login Response shows that the =3D > <0203> indicating that "the requested ITN does not exist at this address" I have been using istgt for quite a while with no problems, both as a regul= ar drive attachment and a full diskless iSCSI boot of Windows. Check istgt= 's entries in /var/log/messages and see if it logs something useful about w= hy it refused the login. -- Dan Nelson dnelson@allantgroup.com This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. From owner-freebsd-net@FreeBSD.ORG Tue Mar 13 04:26:05 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B24941065670 for ; Tue, 13 Mar 2012 04:26:05 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 814FF8FC08 for ; Tue, 13 Mar 2012 04:26:05 +0000 (UTC) Received: by dald2 with SMTP id d2so254209dal.13 for ; Mon, 12 Mar 2012 21:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ArMVEX4I0xeVJwgCDfV4cTXphUBfvm9OOVeTRXcVGBs=; b=f0mTwfWvxcPOORtWqqFCrqH6fpF/KWdoQ/lQXl2LtCbjvoUyjKs3hVZnRmfDyaOW/V AGmfJvo1pXF6s2rVlNkX5DRlnt+M4vlara89apPR+1QvgVk3sG+Pk24Omg3zoxBulVd2 YdtRTZHxACsjye5r4mQg07B2IENmG2Z1X3/9BsVSMEvl73GJBywe3GvL0IRMpOiKJlsq qoaB1etk5sFDa2Lg+3oeuOwRKUmWKLVHevzYSCeuTiSpkCLCnT3FJttm3iG1ie/BP7f/ LJ9oSdDJaBr5vWnKrZV1lSYYoVmLQygqyVVuPgsO3MBEwbJxddW/0T5NNIFND+Eu2eDe wdJQ== Received: by 10.68.72.70 with SMTP id b6mr4650533pbv.58.1331612764766; Mon, 12 Mar 2012 21:26:04 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id u9sm111245pbj.39.2012.03.12.21.26.01 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Mar 2012 21:26:03 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 13 Mar 2012 13:25:59 -0700 From: YongHyeon PYUN Date: Tue, 13 Mar 2012 13:25:59 -0700 To: Andreas Longwitz Message-ID: <20120313202559.GA3360@michelle.cdnetworks.com> References: <4F594856.3030303@incore.de> <20120312211907.GC3671@michelle.cdnetworks.com> <4F5E0AF7.30302@incore.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F5E0AF7.30302@incore.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Intel 82550 Pro/100 Ethernet and Microcode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 04:26:05 -0000 On Mon, Mar 12, 2012 at 03:40:55PM +0100, Andreas Longwitz wrote: > > > Unfortunately this still does not make any difference on i82550C > > controller(still spews SCB timeouts). By chance, do you have > > original i82550? Show me the output of 'pciconf -l'. > > fxp0@pci0:0:3:0: class=0x020000 card=0x340f8086 chip=0x12298086 > rev=0x0d hdr=0x00 > fxp1@pci0:0:4:0: class=0x020000 card=0x340f8086 chip=0x12298086 > rev=0x0d hdr=0x00 > fxp2@pci0:1:9:0: class=0x020000 card=0x10408086 chip=0x12298086 > rev=0x0c hdr=0x00 > > >From if_fxpreg.h: > > #define FXP_REV_82550 12 > #define FXP_REV_82550_C 13 /* 82550 C stepping */ > > Therefore I think fxp0/fxp1 are 82550C (on motherboard) and fxp2 is > original 82550. I have several servers with this constellation and saw > SCB timeouts only one time during the last 6 month while debugging with > wireshark: > fwvpn kernel: fxp0: promiscuous mode enabled > fwvpn kernel: fxp0: Microcode loaded, int_delay: 1000 usec > bundle_max: 6 > fwvpn kernel: fxp0: SCB timeout: 0x80 0x20 0x90 0x1 > fwvpn last message repeated 5 times > The microcode is normally used to reduce high number of interrupts under heavy network load by bundling multiple RX frames. However your reason to use microcode for i82550C looks weird since the microcode used for i82550C does not have a fix for TCO bug. The microcode for i82550(fxp2 in your system) indeed has fix for TCO bug and includes additional feature for bundling. If you're suffering from TCO bug of i82550, NFS over UDP issue should happen only on i82550(fxp2). Can you check whether the NFS issue happens on i82550C (fxp0 and fxp1) without loading the microcode? I still can't explain why your i82550C with the loaded microcode does not generates SCB timeouts because mine always shows the error right after loading the microcode. Are you actively using fxp0 or fxp1 after loading the microcode? If yes, could you check whether the CPU Saver feature of the microcode really works on i82550C? You may be able to use netperf UDP stream test to verify that. > Regards, > > Andreas Longwitz > From owner-freebsd-net@FreeBSD.ORG Tue Mar 13 08:00:02 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A135D1065670 for ; Tue, 13 Mar 2012 08:00:02 +0000 (UTC) (envelope-from saeedeh.motlagh@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 208918FC0A for ; Tue, 13 Mar 2012 08:00:01 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so4001928wib.13 for ; Tue, 13 Mar 2012 01:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=3NJyisUxtCib/H7CTvGB/IrrmANP95WzgfWc4uXLoOA=; b=JtN+YabFMIC1KEzFKUOyBmSYT4XKF4x1tFIcMHsw3V0/RQKkJmE1MY7jSY0VluwOpA IsM2D549hegb9IS4lDPXiGkUG42v7fQM0olPral/sRuTUA5THsp894/s+5MatIFhTdxY 9NVM9N07Xb/vGhc33vmbrmQwka4+deSa24+w30m1uPSBWdjoyMQi6ioLfL+yGCOlGvmO vB3c05OcQfUtVp7fE/X/UoCvP2Imshukg+u3tvjkWWQAMbRVVJTJuNDrWrHPYzpGi+xA EY7JJInBza4AgfwwdjqmCc02Xcq16dRtd8NeWtK/yB5HVDNqqm0vu4Jhj0gEfVM9o/Rv kPlw== MIME-Version: 1.0 Received: by 10.180.86.230 with SMTP id s6mr4937339wiz.16.1331625601282; Tue, 13 Mar 2012 01:00:01 -0700 (PDT) Received: by 10.223.75.26 with HTTP; Tue, 13 Mar 2012 01:00:01 -0700 (PDT) In-Reply-To: References: <20120305084359.GA56606@server.vk2pj.dyndns.org> <20120305222811.GA64183@server.vk2pj.dyndns.org> <20120306074655.GA71641@server.vk2pj.dyndns.org> Date: Tue, 13 Mar 2012 11:30:01 +0330 Message-ID: From: saeedeh motlagh To: h bagade , freebsd-net Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: problem with vlan interfaces tagging/untagging in a simulated switch box X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 08:00:02 -0000 i think i have similar problem too. you want to have tagged and untagged traffic at the same time on the trunk port, right? in your topology the vlans and trunk port are bridged and the tagged traffic is passed through the trunk port and every thing works fine. then when you want to have the untagged traffic on the trunk port, you bridge an interface with trunk port directly. after that all the traffic which is received on the trunk port, are sent to this interface and vlans receive no packet. eth0 -+ | eth1 -+ --- bridge1 --- vlan9 --+-- eth4 ----- | eth2 -+ --- bridge2 --- vlan8 --+ --------+ | eth3 -+ ------------ bridge3 ----------------+ please let me know if i understand what you exactly mean. yours, From owner-freebsd-net@FreeBSD.ORG Tue Mar 13 09:19:22 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 87AF21065670 for ; Tue, 13 Mar 2012 09:19:22 +0000 (UTC) (envelope-from prvs=1419e3463f=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 07F868FC0C for ; Tue, 13 Mar 2012 09:19:21 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Tue, 13 Mar 2012 09:19:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50018658034.msg for ; Tue, 13 Mar 2012 09:19:14 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1419e3463f=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <32B098EB44ED44E2B9724D014F44A8A2@multiplay.co.uk> From: "Steven Hartland" To: "Jack Vogel" References: <18969B34B4EE402986389D5022DCCB35@multiplay.co.uk><853549959.20120312184940@yandex.ru><2B4507129C2141BC9D12B6F7BE5987B3@multiplay.co.uk><50980382.20120312202136@yandex.ru><86016A34935443C383B3EE08F3D4292D@multiplay.co.uk><2ABAFC6511784968A02D9580D8EB2AE7@multiplay.co.uk> Date: Tue, 13 Mar 2012 09:19:05 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Content-Type: text/plain; charset="KOI8-R" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, =?KOI8-R?B?68/O2MvP1yDl18fFzsnK?= Subject: Re: Re[2]: ixgbe interface micro stalls / slow responses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 09:19:22 -0000 Same behaviour with just one queue:- Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. ixtest 0.0% 28 0.1 24.4 0.1 297.5 73.0 ix0: port 0x2000-0x201f mem 0xd8400000-0xd847ffff,0xd8480000-0xd8483fff irq 52 at device 0.0 on pci5 ix0: Using MSIX interrupts with 2 vectors ix0: [ITHREAD] ix0: [ITHREAD] ix0: Ethernet address: 00:1b:21:7e:2e:8c ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 Setting the following in loader.conf does fix the RX warning, so could do with updating the docs so it lists /boot/loader.conf instead of /etc/sysctl.conf kern.ipc.nmbjumbop=3D262144 kern.ipc.nmbclusters=3D524288 Regards Steve ----- Original Message -----=20 From: Jack Vogel=20 To: Steven Hartland=20 Cc: =EB=CF=CE=D8=CB=CF=D7 =E5=D7=C7=C5=CE=C9=CA ; freebsd-net@freebsd.org=20 Sent: Monday, March 12, 2012 8:32 PM Subject: Re: Re[2]: ixgbe interface micro stalls / slow responses I don't know what to make of it right now, i would suggest going minimal, meaning go to a single queue and see what the behavior is.=20 Jack 2012/3/12 Steven Hartland Looks like nmbclusters sysctl changes need to loader.conf so they are available early enough for the driver. We haven't rebooted to test that yet as the machine is under so little network load I wouldn't expect raising it from 1024 to 2048 RX descriptors to make any real difference, what do you recon? =20 Regards Steve =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.=20 In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Tue Mar 13 16:27:17 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E3B3106566B for ; Tue, 13 Mar 2012 16:27:17 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 7E8098FC08 for ; Tue, 13 Mar 2012 16:27:17 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 13 Mar 2012 09:27:22 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id q2DGRG03056512; Tue, 13 Mar 2012 09:27:16 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id q2DGRGlk056510; Tue, 13 Mar 2012 09:27:16 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201203131627.q2DGRGlk056510@ambrisko.com> In-Reply-To: To: saeedeh motlagh Date: Tue, 13 Mar 2012 09:27:16 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL124d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Cc: h bagade , freebsd-net Subject: Re: problem with vlan interfaces tagging/untagging in a simulated switch box X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 16:27:17 -0000 saeedeh motlagh writes: | i think i have similar problem too. you want to have tagged and | untagged traffic at the same time on the trunk port, right? | in your topology the vlans and trunk port are bridged and the tagged | traffic is passed through the trunk port and every thing works fine. | then when you want to have the untagged traffic on the trunk port, | you bridge an interface with trunk port directly. after that all the | traffic which is received on the trunk port, are sent to this | interface and vlans receive no packet. | | eth0 -+ | | | eth1 -+ --- bridge1 --- vlan9 --+-- eth4 ----- | | | eth2 -+ --- bridge2 --- vlan8 --+ --------+ | | eth3 -+ ------------ bridge3 ----------------+ | | please let me know if i understand what you exactly mean. | yours, I think part of the problem with the standard code paths unless you use netgraph is that the vlan SW stack transmits directly to the NIC and skips the bridge. This code is in vlan_start of sys/net/if_vlan.c. There is a comment that says: Send it, precisely as ether_output() would have. Also this would only work with SW VLAN and not HW assist VLAN. So I have two changes, disable HW assist VLAN and to re-insert the VLAN packet into the ether_output just before the bridge. I ended up splitting ether_output into 2 function so I could call the end part of ether_output from vlan_start. I also had a trivial change to allow VLAN in VLAN. I don't really have to use this code now so I've dropped some of it. I did it for testing. Now I plan to create the same test environment using the vimage work since it is cleaner and easier to understand. My suggestion would be to create a netgraph solution since it shouldn't have these limitations. It's probably what I would have done if netgraph had this as the time. Doug A. From owner-freebsd-net@FreeBSD.ORG Tue Mar 13 20:39:43 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 582D81065676 for ; Tue, 13 Mar 2012 20:39:43 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 2C1C78FC0A for ; Tue, 13 Mar 2012 20:39:42 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q2DKdfIM081327 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 13 Mar 2012 13:39:42 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4F5FB0A0.9040802@freebsd.org> Date: Tue, 13 Mar 2012 13:40:00 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: h bagade References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: STP on netgraph bridge node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 20:39:43 -0000 On 3/11/12 1:06 AM, h bagade wrote: > Hi all, > > Is there any way to add STP and RSTP protocols to bridge node on > netgraph? Should I implement it on the node or it has done before? > _______________________________________________ > 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" > feel free.. I don't think it has been done, whether one adds it to that node or a separate node that hooks onto the side of it might be a reasonable question.. (but I don't know enough about STP to judge..) I dont' know how well the code in if_bridge will port over, or iff it can be made a common module. From owner-freebsd-net@FreeBSD.ORG Tue Mar 13 20:45:18 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B429A1065676 for ; Tue, 13 Mar 2012 20:45:18 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx1.freebsd.org (Postfix) with ESMTP id 86C8D8FC20 for ; Tue, 13 Mar 2012 20:45:18 +0000 (UTC) Received: by dadp14 with SMTP id p14so3422346dad.18 for ; Tue, 13 Mar 2012 13:45:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=QGa9rLXJen154dYTL/RFIqJtITpXxeJvg7Xk86LJlFI=; b=FEGEDiAPKViBo5lrldsp0Rh105T/w4dlBc9MTUqoO8RHXVL8kztP7FlvNxe+U4OALE pYHJGFcpMMAWRhaGTic/B+GLWf+A0HCV8GF1xuJ6lOI0G+1P/ZHT5gbdK+tjwUTnhxWL WNUzI/FQ1iiy78H8R/hj0HxActgSNuvEsYi7PqkiSeFKW8cURFC8Nf3z7gwJ3zo0TTTy oiwJepjSUNW4YYVhxRMl0x/H+h4Bq/pzPAJGxPQgOS+ACk200eu+CzqVCvpwnTaxzzob t1KrqRVMdhd6OwgCUMcovWZk1BBmUuxu+4n+k1g76T4GqnChjM52/v6kcpSEOcv0BeT4 rbjA== MIME-Version: 1.0 Received: by 10.68.129.41 with SMTP id nt9mr184303pbb.111.1331671518084; Tue, 13 Mar 2012 13:45:18 -0700 (PDT) Sender: andy@fud.org.nz Received: by 10.68.2.135 with HTTP; Tue, 13 Mar 2012 13:45:18 -0700 (PDT) In-Reply-To: <4F5FB0A0.9040802@freebsd.org> References: <4F5FB0A0.9040802@freebsd.org> Date: Wed, 14 Mar 2012 09:45:18 +1300 X-Google-Sender-Auth: Dmt2w_73peGnjPsxWo8KlaB99XY Message-ID: From: Andrew Thompson To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlU5RsVrN+w3NzDhMKGdNuN9ftplmeUhnyW4ahKa5NulOPQlrugAiVLkJtxO9E+X4AqIgsu Cc: h bagade , freebsd-net Subject: Re: STP on netgraph bridge node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 20:45:18 -0000 On 14 March 2012 09:40, Julian Elischer wrote: > On 3/11/12 1:06 AM, h bagade wrote: >> >> Hi all, >> >> Is there any way to add STP and RSTP protocols to bridge node on >> netgraph? Should I implement it on the node or it has done before? >> _______________________________________________ >> 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" >> > feel free.. I don't think it has been done, > > whether one adds it to that node or a separate node that hooks > onto the side of it might be a reasonable question.. (but I don't > know enough about STP to judge..) =A0I dont' know how well the code > in if_bridge will port over, or iff it can be made a common module. I split it off as a module 5 years ago and mentioned ng_bridge in the commit message. http://svnweb.freebsd.org/base?view=3Drevision&revision=3D160704 Still waiting for someone to plumb it in :) Andrew From owner-freebsd-net@FreeBSD.ORG Tue Mar 13 20:51:09 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 60F08106564A; Tue, 13 Mar 2012 20:51:09 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 32B308FC1B; Tue, 13 Mar 2012 20:51:09 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q2DKp75i081367 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 13 Mar 2012 13:51:08 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4F5FB34E.4000401@freebsd.org> Date: Tue, 13 Mar 2012 13:51:26 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Andrew Thompson References: <4F5FB0A0.9040802@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: h bagade , freebsd-net Subject: Re: STP on netgraph bridge node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 20:51:09 -0000 On 3/13/12 1:45 PM, Andrew Thompson wrote: > On 14 March 2012 09:40, Julian Elischer wrote: >> On 3/11/12 1:06 AM, h bagade wrote: >>> Hi all, >>> >>> Is there any way to add STP and RSTP protocols to bridge node on >>> netgraph? Should I implement it on the node or it has done before? >>> _______________________________________________ >>> 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" >>> >> feel free.. I don't think it has been done, >> >> whether one adds it to that node or a separate node that hooks >> onto the side of it might be a reasonable question.. (but I don't >> know enough about STP to judge..) I dont' know how well the code >> in if_bridge will port over, or iff it can be made a common module. > I split it off as a module 5 years ago and mentioned ng_bridge in the > commit message. > > http://svnweb.freebsd.org/base?view=revision&revision=160704 > > Still waiting for someone to plumb it in :) well then I guess we have a volunteer! > > Andrew > > From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 03:27:49 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2790F106564A for ; Wed, 14 Mar 2012 03:27:49 +0000 (UTC) (envelope-from nyoman.bogi@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9BE588FC0C for ; Wed, 14 Mar 2012 03:27:48 +0000 (UTC) Received: by lagv3 with SMTP id v3so1520639lag.13 for ; Tue, 13 Mar 2012 20:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mjR/OEQUcsTvMFsOutaJH7//KxfynHv8iiYfKKFp88s=; b=AcqlLYfu82OVoGdQHoA6JPjYBqVXHzz18JCKHF760m2PPd9kaLVc2M1SH0gtNCVRSR Mxm3cPTkNoHHkHO/Qbm91Zvh9px3ZP3O1JK7OnOdYCjjN4WNZqUEJTsl3c8DzEN3CYN7 dNpCgDDhAKbD+qH27qVb2fODMotPb3j6tBPm7zUJpP8bXolIEQ+WCPvq3g08yFhRVteS PaD3i5DqlPi02EU5w2v91fIWv2kilN15LMmZe3aw+tY4nCW3mAi54kKVMV7uKQWNE6E7 wpCoRi2jhPxHhUPGd2Ii71OVSUhaMEsajvSPa6UE7S9peMkJexve+QXE+G3vpg0HCqKo Fw7A== MIME-Version: 1.0 Received: by 10.112.48.200 with SMTP id o8mr360341lbn.54.1331695667280; Tue, 13 Mar 2012 20:27:47 -0700 (PDT) Received: by 10.112.115.130 with HTTP; Tue, 13 Mar 2012 20:27:47 -0700 (PDT) Date: Wed, 14 Mar 2012 10:27:47 +0700 Message-ID: From: "nyoman.bogi@gmail.com" To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: firewall stuck X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 03:27:49 -0000 dear guru, every time I open my firewall to allow SSH connection from Internet after few days my firewall always stuck. Stuck in here meaning that it deny all request (deny any from any). And after I "ipfw disable firewall" and then "ipfw enable firewall" everything works fine when I checked /var/log/messages I found lots of attempts people try to connect to my machine. why my machine get stuck when lots of people try to SSH to my machine? ------------------------------- Bogi Aditya Sisfo - IMTelkom http://bogi.blog.imtelkom.ac.id From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 05:18:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 824F4106566B for ; Wed, 14 Mar 2012 05:18:59 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 081128FC1E for ; Wed, 14 Mar 2012 05:18:58 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so1326538bkc.13 for ; Tue, 13 Mar 2012 22:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=CAeDBHnFbnNoSiE5a0+mZcnzHjM/e9mwWQukY2RabYM=; b=k/Wa7c/+Bz59OIz8WvnosZ8Nged0BmzK+K/FzC2xWh2HDCZMNryHLPxgiBi8HehO2l 890NxPySo1nJqFv4huY+tde1Xe/QCqM6f9ahQXwX+/zVYDPmdzlwqopIHWpJY2wh0owO lg6YVMRWrYK0Jetm3qo/v5aQdYEcCduG5Ircklafara717GmZJK+uNUSMIawhZU+csaG L5EqD/0ggwkzf0CqlNA5leDvaveACA34s3N/woosPiTvwAmxXqKogm/hbW7n5GKJagbl +62k1aWJ1csT1/aILmQEBUGlNtHdLgjvm6pdVjTpOcGe1+dgCvyrqKQT+oLVKo3qSCXf NZuA== MIME-Version: 1.0 Received: by 10.204.150.86 with SMTP id x22mr407317bkv.136.1331702337924; Tue, 13 Mar 2012 22:18:57 -0700 (PDT) Received: by 10.204.230.5 with HTTP; Tue, 13 Mar 2012 22:18:57 -0700 (PDT) Received: by 10.204.230.5 with HTTP; Tue, 13 Mar 2012 22:18:57 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Mar 2012 22:18:57 -0700 Message-ID: From: hiren panchasara To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Use of network_interfaces in rc.conf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 05:18:59 -0000 Can someone please help? :-) On Mar 12, 2012 9:04 AM, "hiren panchasara" wrote: > Looking at man rc.conf, > > network_interfaces > (str) Set to the list of network interfaces to configure > on > this host or =E2=80=9CAUTO=E2=80=9D (the default) for al= l current > interfaces. > Setting the network_interfaces variable to anything othe= r > than the default is deprecated. Interfaces that the > adminis=E2=80=90 > trator wishes to store configuration for, but not start = at > boot should be configured with the =E2=80=9CNOAUTO=E2=80= =9D keyword in > their > ifconfig_=E2=9F=A8interface=E2=9F=A9 variables as descri= bed below. > > For example, in my rc.conf I have > > ifconfig_em0=3D"dhcp" > > What difference does it make when I have each (separately) in my rc.conf: > > 1) no network_interfaces at all > 2) network_interfaces=3D"AUTO" > 3) network_interfaces=3D"em0" > 4) network_interfaces=3D"NOAUTO" > > It seems, all but 2 are deprecated. > > Thanks in advance, > Hiren > From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 05:32:24 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40E10106566B for ; Wed, 14 Mar 2012 05:32:24 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by mx1.freebsd.org (Postfix) with ESMTP id 24BD68FC0C for ; Wed, 14 Mar 2012 05:32:24 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [10.1.2.130] (unknown [173.200.187.194]) by asmtp019.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0M0V00C6A0PMGG50@asmtp019.mac.com> for freebsd-net@freebsd.org; Wed, 14 Mar 2012 05:32:17 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498,1.0.260,0.0.0000 definitions=2012-03-14_02:2012-03-13, 2012-03-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1203130374 From: Chuck Swiger In-reply-to: Date: Tue, 13 Mar 2012 22:32:10 -0700 Message-id: References: To: hiren panchasara X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: Use of network_interfaces in rc.conf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 05:32:24 -0000 On Mar 13, 2012, at 10:18 PM, hiren panchasara wrote: >> What difference does it make when I have each (separately) in my rc.conf: >> >> 1) no network_interfaces at all >> 2) network_interfaces="AUTO" These two are the same. >> 3) network_interfaces="em0" This will configure em0 only, using ifconfig_em0 if that is set. You'd almost certainly want to list loopback, aka lo0, in this list. >> 4) network_interfaces="NOAUTO" That's invalid. If you set: ifconfig_em0="NOAUTO" ...then em0 would not be auto-configured. Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 06:12:04 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21B8E106566C for ; Wed, 14 Mar 2012 06:12:04 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A77348FC19 for ; Wed, 14 Mar 2012 06:12:03 +0000 (UTC) Received: by wern13 with SMTP id n13so1711392wer.13 for ; Tue, 13 Mar 2012 23:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7RJSNjaxmt/nryt53zMXUM/x9jd+XSY3gYowTZa19yI=; b=zCmINyaM8NbW1P4wK/63gsb6U5jqwz9/53SelAOuC0e2f83e56pM+p8s8UpgCDyvt4 A0rqbH7YA7ykfyZGNX9a4cQjSMB1pxBIUfbcHksXc4BXLdDfz21E2nw4dCRRnfJiHUwA v3iabKwue56qTvHMEdTT7s9maRKoU94BiAki0WKgEb7rvEDib85ED4pV4LFhocO4tTrL BxII/BHLKKFrkNIFavblLoc0QJGk008nqDc7xB6er6X+0mcm2V4iFXbrRwiAlWuSljdA eZ9wXo0cCMRPI9Z4mK6Hwv4ZGXNjTUPvMLPJHEqFj7oEZb00Dh/ZqX7vIYSL3AkmRPIo q44Q== MIME-Version: 1.0 Received: by 10.180.104.137 with SMTP id ge9mr3110923wib.20.1331705522429; Tue, 13 Mar 2012 23:12:02 -0700 (PDT) Received: by 10.223.143.3 with HTTP; Tue, 13 Mar 2012 23:12:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Mar 2012 22:12:02 -0800 Message-ID: From: Kevin Oberman To: "nyoman.bogi@gmail.com" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: firewall stuck X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 06:12:04 -0000 On Tue, Mar 13, 2012 at 7:27 PM, nyoman.bogi@gmail.com wrote: > dear guru, > > every time I open my firewall to allow SSH connection from Internet > after few days my firewall always stuck. Stuck in here meaning > that it deny all request (deny any from any). > And after I "ipfw disable firewall" and then "ipfw enable firewall" > everything works fine > > when I checked /var/log/messages I found lots of attempts > people try to connect to my machine. > why my machine get stuck when lots of people try to SSH to my machine? We need a bit more information, especially your ipfw configuration. Is it a statefull firewall? It sounds a lot like your state table might be filling for some reason. Of course, if it is not a statefull firewall, that idea is probably wrong, though it could be a misconfiguration of some statefull rule that is inadvertently catching the SSH attempts. Have you done an 'ipfw show' to see what rules are being matched? it may or may not provide a clue. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 06:19:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50ED91065670 for ; Wed, 14 Mar 2012 06:19:44 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C5BE58FC16 for ; Wed, 14 Mar 2012 06:19:43 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so1358190bkc.13 for ; Tue, 13 Mar 2012 23:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U0c9B1NhiHZ4Y8uUjBFlIaIY2J8xMT92vaWdQ2bFqws=; b=bdcK5dLqDf8GUzWprkEvQYxE3nLdestkbvM4sOrjGAskgUnlH6VBtJUel4t4fYqtBa OJZ8JQm280WwBWV+jjflMCp/DM6wvR3qJNQeycu5B7xle8hf54hR9noiSAo/WAoYQsg/ B1a43ScmMh0v8iHNt9161O103nnvz89GyclmTmQUNF6rfQAkU75jTrPgkaLZtewB+iWO OiwAkYD+8wzeDIQBByadURsPGlYLHtABIS9bwz3HzgiH172i39yYBfHx/Hm74csqLCnK U3Q8wEc2xcZpVUuBeCyUZw57MSMd1oHH8UYzxexLgzShmOhj0y2aZV+ukcIQ/tGuC8rX /U6Q== MIME-Version: 1.0 Received: by 10.204.150.86 with SMTP id x22mr465328bkv.136.1331705982666; Tue, 13 Mar 2012 23:19:42 -0700 (PDT) Received: by 10.204.230.5 with HTTP; Tue, 13 Mar 2012 23:19:42 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Mar 2012 23:19:42 -0700 Message-ID: From: hiren panchasara To: Chuck Swiger Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Use of network_interfaces in rc.conf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 06:19:44 -0000 Thanks Chuck for getting back. I have a question inlined: On Tue, Mar 13, 2012 at 10:32 PM, Chuck Swiger wrote: > On Mar 13, 2012, at 10:18 PM, hiren panchasara wrote: > >> What difference does it make when I have each (separately) in my > rc.conf: > >> > >> 1) no network_interfaces at all > >> 2) network_interfaces="AUTO" > > These two are the same. > Okay. So, if my system has 4 interfaces: em0, iwn0, fwp0, wlan0 Does the above mean following? ifconfig_em0="AUTO" ifconfig_iwn0="AUTO" ifconfig_fwp0="AUTO" ifconfig_wlan0="AUTO" Also, if we say an interface is auto configured, it needs some sort of configuration to "auto-configure" it with, right? i.e. for em0 something like: ifconfig_em0="DHCP" Thanks, Hiren From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 11:20:05 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C87511065672 for ; Wed, 14 Mar 2012 11:20:05 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id DD4448FC1D for ; Wed, 14 Mar 2012 11:20:04 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q2EBJxXW085365; Wed, 14 Mar 2012 18:20:00 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4F607EDF.4010505@rdtc.ru> Date: Wed, 14 Mar 2012 18:19:59 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: hiren panchasara References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: Use of network_interfaces in rc.conf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 11:20:05 -0000 14.03.2012 13:19, hiren panchasara РЙЫЕФ: > Thanks Chuck for getting back. I have a question inlined: > > On Tue, Mar 13, 2012 at 10:32 PM, Chuck Swiger wrote: > >> On Mar 13, 2012, at 10:18 PM, hiren panchasara wrote: >>>> What difference does it make when I have each (separately) in my >> rc.conf: >>>> >>>> 1) no network_interfaces at all >>>> 2) network_interfaces="AUTO" >> >> These two are the same. >> > Okay. So, if my system has 4 interfaces: em0, iwn0, fwp0, wlan0 > > Does the above mean following? > > ifconfig_em0="AUTO" > ifconfig_iwn0="AUTO" > ifconfig_fwp0="AUTO" > ifconfig_wlan0="AUTO" No. network_interfaces is basically historic rudiment used in 2.2.x FreeBSD version and alike. In general, you should not use it in modern version at all. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 12:59:21 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6127D1065672; Wed, 14 Mar 2012 12:59:21 +0000 (UTC) (envelope-from sanpei@sanpei.org) Received: from mail1.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id 29A028FC08; Wed, 14 Mar 2012 12:59:20 +0000 (UTC) Received: from cherry2.sanpei.org (j069113.ppp.asahi-net.or.jp [61.213.69.113]) by mail1.asahi-net.or.jp (Postfix) with ESMTP id AFECE1364BB; Wed, 14 Mar 2012 21:59:11 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by cherry2.sanpei.org (8.14.4/8.14.3) with ESMTP id q2ECx8mj025541; Wed, 14 Mar 2012 21:59:09 +0900 (JST) (envelope-from sanpei@sanpei.org) Date: Wed, 14 Mar 2012 21:59:08 +0900 (JST) Message-Id: <20120314.215908.1291465837804728646.sanpei@sanpei.org> To: freebsd-emulation@freebsd.org, freebsd-net@freebsd.org From: MIHIRA Sanpei Yoshiro In-Reply-To: <20120304184529.GA57370@psconsult.nl> References: <20120304184529.GA57370@psconsult.nl> X-Mailer: Mew version 6.3 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (cherry2.sanpei.org [127.0.0.1]); Wed, 14 Mar 2012 21:59:11 +0900 (JST) Cc: freebsd@psconsult.nl Subject: Re: if_bridge stops when running virtualbox 4.1.8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 12:59:21 -0000 Hi, I also have this problem. My environment is below - FreeBSD-8.2-RELEASE/amd64 and FreeBSD-10-current/i386 - Virtualbox 4.0.14(now I'm compiling new version 4.1.8) - WI-FI HOSTAP mode(if_bridge) I hope to use both function(VirtualBox and if_bridge) at same. Please let us to know the appropriate settings. >I just noticed that when running Virtualbox 4.1.8 with a bridged network >interface, I loose connectivity to another virtual host running in qemu >whose network interface is bridged to my ethernet interface. After >stopping the Virtualbox instance, I regain connection to the virtual >host under qemu. Ifconfig doesn't give a clue. Has anyone seen this >behaviour or, even better, have a solution? --- MIHIRA, Sanpei Yoshiro Tokyo, Japan. From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 13:06:42 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05E611065670; Wed, 14 Mar 2012 13:06:42 +0000 (UTC) (envelope-from flo@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E374B8FC1C; Wed, 14 Mar 2012 13:06:41 +0000 (UTC) Received: from bender.solomo.local (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2ED6dQq084673; Wed, 14 Mar 2012 13:06:40 GMT (envelope-from flo@freebsd.org) Message-ID: <4F6097DF.8000400@freebsd.org> Date: Wed, 14 Mar 2012 14:06:39 +0100 From: Florian Smeets User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120217 Thunderbird/10.0.2 MIME-Version: 1.0 To: MIHIRA Sanpei Yoshiro References: <20120304184529.GA57370@psconsult.nl> <20120314.215908.1291465837804728646.sanpei@sanpei.org> In-Reply-To: <20120314.215908.1291465837804728646.sanpei@sanpei.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-emulation@freebsd.org, freebsd@psconsult.nl Subject: Re: if_bridge stops when running virtualbox 4.1.8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 13:06:42 -0000 On 14.03.2012 13:59, MIHIRA Sanpei Yoshiro wrote: > Hi, > > I also have this problem. > My environment is below > - FreeBSD-8.2-RELEASE/amd64 and FreeBSD-10-current/i386 > - Virtualbox 4.0.14(now I'm compiling new version 4.1.8) > - WI-FI HOSTAP mode(if_bridge) > > I hope to use both function(VirtualBox and if_bridge) at same. > Please let us to know the appropriate settings. > >> I just noticed that when running Virtualbox 4.1.8 with a bridged network >> interface, I loose connectivity to another virtual host running in qemu >> whose network interface is bridged to my ethernet interface. After >> stopping the Virtualbox instance, I regain connection to the virtual >> host under qemu. Ifconfig doesn't give a clue. Has anyone seen this >> behaviour or, even better, have a solution? > What i did was create another tap interface add that to the bridge and configure VirtualBox to use the tap interface. Seems to work for me. HTH, Florian From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 22:32:41 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4304F106566C for ; Wed, 14 Mar 2012 22:32:41 +0000 (UTC) (envelope-from adarsh.joshi@qlogic.com) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by mx1.freebsd.org (Postfix) with ESMTP id E67DF8FC14 for ; Wed, 14 Mar 2012 22:32:40 +0000 (UTC) Received: from mail172-ch1-R.bigfish.com (10.43.68.226) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.23; Wed, 14 Mar 2012 22:32:35 +0000 Received: from mail172-ch1 (localhost [127.0.0.1]) by mail172-ch1-R.bigfish.com (Postfix) with ESMTP id 3167A1406F8 for ; Wed, 14 Mar 2012 22:32:35 +0000 (UTC) X-SpamScore: -6 X-BigFish: VPS-6(zzc85fh14ffOzz1202hzz8275bh8275dhz2ei2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:198.70.193.64; KIP:(null); UIP:(null); IPV:NLI; H:avexcashub1.qlogic.com; RD:avexcashub2.qlogic.com; EFVD:NLI Received-SPF: neutral (mail172-ch1: 198.70.193.64 is neither permitted nor denied by domain of qlogic.com) client-ip=198.70.193.64; envelope-from=adarsh.joshi@qlogic.com; helo=avexcashub1.qlogic.com ; 1.qlogic.com ; Received: from mail172-ch1 (localhost.localdomain [127.0.0.1]) by mail172-ch1 (MessageSwitch) id 1331764353195726_24298; Wed, 14 Mar 2012 22:32:33 +0000 (UTC) Received: from CH1EHSMHS015.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail172-ch1.bigfish.com (Postfix) with ESMTP id 2CF551C00D5 for ; Wed, 14 Mar 2012 22:32:33 +0000 (UTC) Received: from avexcashub1.qlogic.com (198.70.193.64) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 14 Mar 2012 22:32:33 +0000 Received: from avexmb1.qlogic.org ([fe80::9545:3a4f:c131:467d]) by avexcashub2.qlogic.org ([::1]) with mapi; Wed, 14 Mar 2012 15:32:30 -0700 From: Adarsh Joshi To: "freebsd-net@freebsd.org" Date: Wed, 14 Mar 2012 15:32:29 -0700 Thread-Topic: Zero MAC address Thread-Index: Ac0CMlcWwRtJaw5xQc6Z/3ldDsu+ww== Message-ID: <5E4F49720D0BAD499EE1F01232234BA87438162F95@AVEXMB1.qlogic.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginatorOrg: qlogic.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Zero MAC address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 22:32:41 -0000 Hello everyone, I assigned a 00:00:00:00:00:00 MAC address to one of my interfaces on a mac= hine and tried to ping the peer machine. The ping did go through fine. I can the see the request and reply packets on the packet capture. I am won= dering if that is legitimate and if not, who is supposed to check that. I m= ean, the stack or the driver on the sending machine or the receiving machin= e. Basically, I am trying to test a statistics utility which keeps track of pa= ckets with invalid MAC addresses. Are the packets with zero MAC addresses = be classified as invalid? Thanks a lot Adarsh ________________________________ This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 22:48:05 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D979F106567A; Wed, 14 Mar 2012 22:48:05 +0000 (UTC) (envelope-from adarsh.joshi@qlogic.com) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by mx1.freebsd.org (Postfix) with ESMTP id 722818FC14; Wed, 14 Mar 2012 22:48:05 +0000 (UTC) Received: from mail22-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Wed, 14 Mar 2012 22:48:05 +0000 Received: from mail22-va3 (localhost [127.0.0.1]) by mail22-va3-R.bigfish.com (Postfix) with ESMTP id 8B5832E04E8; Wed, 14 Mar 2012 22:48:05 +0000 (UTC) X-SpamScore: -6 X-BigFish: VPS-6(zzc85fh14ffOzz1202hzz8275bh8275dhz2ei2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:198.70.193.64; KIP:(null); UIP:(null); IPV:NLI; H:avexcashub1.qlogic.com; RD:avexcashub2.qlogic.com; EFVD:NLI Received-SPF: neutral (mail22-va3: 198.70.193.64 is neither permitted nor denied by domain of qlogic.com) client-ip=198.70.193.64; envelope-from=adarsh.joshi@qlogic.com; helo=avexcashub1.qlogic.com ; 1.qlogic.com ; Received: from mail22-va3 (localhost.localdomain [127.0.0.1]) by mail22-va3 (MessageSwitch) id 1331765284322753_17788; Wed, 14 Mar 2012 22:48:04 +0000 (UTC) Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.237]) by mail22-va3.bigfish.com (Postfix) with ESMTP id 3ECD338004A; Wed, 14 Mar 2012 22:48:04 +0000 (UTC) Received: from avexcashub1.qlogic.com (198.70.193.64) by VA3EHSMHS010.bigfish.com (10.7.99.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 14 Mar 2012 22:48:03 +0000 Received: from avexmb1.qlogic.org ([fe80::9545:3a4f:c131:467d]) by avexcashub2.qlogic.org ([::1]) with mapi; Wed, 14 Mar 2012 15:48:01 -0700 From: Adarsh Joshi To: "freebsd-net@freebsd.org" Date: Wed, 14 Mar 2012 15:48:00 -0700 Thread-Topic: crash on lagg interface destroy Thread-Index: Ac0CMnbp3TERp9AsQx20j/ko44054A== Message-ID: <5E4F49720D0BAD499EE1F01232234BA87438162FA4@AVEXMB1.qlogic.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginatorOrg: qlogic.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-drivers@freebsd.org" Subject: crash on lagg interface destroy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 22:48:05 -0000 Hello everyone, I tried to destroy a lagg interface (created using laggproto none) and I se= e the system crash. Steps to reproduce: Kldload if_lagg Ifconfig lagg0 create ifconfig lagg0 up laggproto none laggport ql0 laggport ql1 192.168.100.1 ne= tmask 255.255.255.0 ifconfig lagg0 destroy uname -a FreeBSD bsd-02 7.4-RELEASE FreeBSD 7.4-RELEASE #0: Wed Mar 7 18:16:06 PST = 2012 root@bsd-02:/usr/src/sys/amd64/compile/MYKERNEL amd64 Crash: Tracing command ifconfig pid 1443 tid 100182 td 0xffffff0023358740 Uart_z8530_class() at 0 Ifc_simple_destroy() at Ifc_simple_destroy+0x2a If_clone_destroyif() at If_clone_destroyif+0xa5 Ifioctl() at ifioctl+0x300 Kern_ioctl() at kern_ioctl+0xa2 Ioctl() at ioctl+0xf9 Syscall() at syscall+0x252 Xfast_syscall() at Xfast_syscall+0xab --- syscall (54, FreeBSD ELF64, ioctl), rip =3D 0x8008324bc, rsp =3D 0x7fff= ffffe348, rbp =3D 0x7ffffffffee27 --- Hope it helps. Let me know if you need more info. Adarsh ________________________________ This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 23:05:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA07B106564A for ; Wed, 14 Mar 2012 23:05:39 +0000 (UTC) (envelope-from adarsh.joshi@qlogic.com) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by mx1.freebsd.org (Postfix) with ESMTP id 60C088FC18 for ; Wed, 14 Mar 2012 23:05:39 +0000 (UTC) Received: from mail82-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Wed, 14 Mar 2012 23:05:40 +0000 Received: from mail82-tx2 (localhost [127.0.0.1]) by mail82-tx2-R.bigfish.com (Postfix) with ESMTP id 89CCA1401A8; Wed, 14 Mar 2012 23:05:39 +0000 (UTC) X-SpamScore: -16 X-BigFish: VPS-16(zz9371I542M1432N98dK111aIzz1202hzz8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:198.70.193.61; KIP:(null); UIP:(null); IPV:NLI; H:avexcashub1.qlogic.com; RD:avexcashub1.qlogic.com; EFVD:NLI Received-SPF: pass (mail82-tx2: domain of qlogic.com designates 198.70.193.61 as permitted sender) client-ip=198.70.193.61; envelope-from=adarsh.joshi@qlogic.com; helo=avexcashub1.qlogic.com ; 1.qlogic.com ; Received: from mail82-tx2 (localhost.localdomain [127.0.0.1]) by mail82-tx2 (MessageSwitch) id 1331766337423717_25358; Wed, 14 Mar 2012 23:05:37 +0000 (UTC) Received: from TX2EHSMHS024.bigfish.com (unknown [10.9.14.238]) by mail82-tx2.bigfish.com (Postfix) with ESMTP id 58F19240045; Wed, 14 Mar 2012 23:05:37 +0000 (UTC) Received: from avexcashub1.qlogic.com (198.70.193.61) by TX2EHSMHS024.bigfish.com (10.9.99.124) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 14 Mar 2012 23:05:37 +0000 Received: from avexmb1.qlogic.org ([fe80::9545:3a4f:c131:467d]) by avexcashub1.qlogic.org ([::1]) with mapi; Wed, 14 Mar 2012 16:05:35 -0700 From: Adarsh Joshi To: Chuck Swiger Date: Wed, 14 Mar 2012 16:05:34 -0700 Thread-Topic: Zero MAC address Thread-Index: Ac0CNdhPKkrowf3TTCi+ZymjbZgh8QAADyEQ Message-ID: <5E4F49720D0BAD499EE1F01232234BA87438162FAE@AVEXMB1.qlogic.org> References: <5E4F49720D0BAD499EE1F01232234BA87438162F95@AVEXMB1.qlogic.org> <1AB6F524-B4F4-4718-96C5-DB2951A02D59@mac.com> In-Reply-To: <1AB6F524-B4F4-4718-96C5-DB2951A02D59@mac.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: qlogic.com Cc: "freebsd-net@freebsd.org" Subject: RE: Zero MAC address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 23:05:39 -0000 Thank you for the quick replies. I am aware of the importance of the second bit. By invalid, I was wondering= if that particular address is reserved or if it has any special meaning or= purpose. So in theory, I cannot classify it as an invalid MAC address on my packet s= tatistics utility. On a side thought, can an incoming packet be classified as "invalid MAC add= ress" if it has the same MAC address of the host? Thanks again Adarsh -----Original Message----- From: Chuck Swiger [mailto:cswiger@mac.com] Sent: Wednesday, March 14, 2012 3:57 PM To: Adarsh Joshi Cc: freebsd-net@freebsd.org Subject: Re: Zero MAC address On Mar 14, 2012, at 3:32 PM, Adarsh Joshi wrote: > I assigned a 00:00:00:00:00:00 MAC address to one of my interfaces on a m= achine and tried to ping the peer machine. The ping did go through fine. > > I can the see the request and reply packets on the packet capture. I am w= ondering if that is legitimate and if not, who is supposed to check that. I= mean, the stack or the driver on the sending machine or the receiving mach= ine. > > Basically, I am trying to test a statistics utility which keeps track of = packets with invalid MAC addresses. Are the packets with zero MAC addresse= s be classified as invalid? In theory, no-- 00:00:00 OUI belongs to Xerox, and there is nothing special= about an all-zeros MAC. If you see an OUI with the second bit of the first octet set, that would in= dicate locally managed addresses rather than global or "universally adminis= tered" numbering, otherwise you can lookup against OUI data from the IEEE: http://standards.ieee.org/develop/regauth/oui/oui.txt ...and that will let you identify the vendor of the ethernet NIC, SAS/fibre= channel controller, etc...or conclude that someone is likely spoofing MAC = addresses if you don't find the OUI listed. Maybe that's what you mean by "invalid"? Regards, -- -Chuck This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 23:33:03 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D7E4106564A for ; Wed, 14 Mar 2012 23:33:03 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8068C8FC12 for ; Wed, 14 Mar 2012 23:33:02 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so2318417bkc.13 for ; Wed, 14 Mar 2012 16:33:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WlX9ORIIm2Lc7VQ0cVuDzvkz8a9Ww+mtyMrm0uUaNCA=; b=ewsV9GpYrxxysc4ybiSnDwLVwNempGThou0hY4H2N0PqFzbaGjoFgMH17SuUnurvSm gAjfN+TP30fLMoOQnpKheb/rWXqM2kTkmKR+SwwPNrJTpQS9RlkwHRj87bQSrQbwnfor MaC1M9BCdboTY8uFp9KcZvu7aU1bQlUcneGZK90px90TYouqoIlM7icTCM62FbA5KmmJ +vXekZniTU1Dh1ag/3N7K8D9PgJ8t8zy1CqK3A8PxqaOjdNccspbXqMqwXM0coDD0jB0 UhrLmOfDjteHuyhP5juNNRBkYKunn28RCKFbqvMer+/frOvKVs4zfXZ+VqskH0t2u3OH Kc2Q== MIME-Version: 1.0 Received: by 10.205.127.130 with SMTP id ha2mr1733537bkc.28.1331767981297; Wed, 14 Mar 2012 16:33:01 -0700 (PDT) Received: by 10.204.230.5 with HTTP; Wed, 14 Mar 2012 16:33:01 -0700 (PDT) In-Reply-To: <4F607EDF.4010505@rdtc.ru> References: <4F607EDF.4010505@rdtc.ru> Date: Wed, 14 Mar 2012 16:33:01 -0700 Message-ID: From: hiren panchasara To: Eugene Grosbein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Use of network_interfaces in rc.conf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 23:33:03 -0000 On Wed, Mar 14, 2012 at 4:19 AM, Eugene Grosbein wrote: > 14.03.2012 13:19, hiren panchasara =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > Thanks Chuck for getting back. I have a question inlined: > > > > On Tue, Mar 13, 2012 at 10:32 PM, Chuck Swiger wrote: > > > >> On Mar 13, 2012, at 10:18 PM, hiren panchasara wrote: > >>>> What difference does it make when I have each (separately) in my > >> rc.conf: > >>>> > >>>> 1) no network_interfaces at all > >>>> 2) network_interfaces=3D"AUTO" > >> > >> These two are the same. > >> > > Okay. So, if my system has 4 interfaces: em0, iwn0, fwp0, wlan0 > > > > Does the above mean following? > > > > ifconfig_em0=3D"AUTO" > > ifconfig_iwn0=3D"AUTO" > > ifconfig_fwp0=3D"AUTO" > > ifconfig_wlan0=3D"AUTO" > > No. > > network_interfaces is basically historic rudiment > used in 2.2.x FreeBSD version and alike. > > In general, you should not use it in modern version at all. > Thanks Eugene. So, the only way to specify boottime configuration (that survives reboots) for an interface in rc.conf is: ifconfig_em0=3D"dhcp" ? Thanks, Hiren From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 23:57:37 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E82B71065670 for ; Wed, 14 Mar 2012 23:57:37 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id 5AB3E8FC08 for ; Wed, 14 Mar 2012 23:57:37 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com (unknown [17.209.4.71]) by asmtp022.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0M0W007WND3KPL80@asmtp022.mac.com> for freebsd-net@freebsd.org; Wed, 14 Mar 2012 22:57:20 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498,1.0.260,0.0.0000 definitions=2012-03-14_06:2012-03-14, 2012-03-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1203140252 From: Chuck Swiger In-reply-to: <5E4F49720D0BAD499EE1F01232234BA87438162F95@AVEXMB1.qlogic.org> Date: Wed, 14 Mar 2012 15:57:19 -0700 Message-id: <1AB6F524-B4F4-4718-96C5-DB2951A02D59@mac.com> References: <5E4F49720D0BAD499EE1F01232234BA87438162F95@AVEXMB1.qlogic.org> To: Adarsh Joshi X-Mailer: Apple Mail (2.1084) Cc: "freebsd-net@freebsd.org" Subject: Re: Zero MAC address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 23:57:38 -0000 On Mar 14, 2012, at 3:32 PM, Adarsh Joshi wrote: > I assigned a 00:00:00:00:00:00 MAC address to one of my interfaces on a machine and tried to ping the peer machine. The ping did go through fine. > > I can the see the request and reply packets on the packet capture. I am wondering if that is legitimate and if not, who is supposed to check that. I mean, the stack or the driver on the sending machine or the receiving machine. > > Basically, I am trying to test a statistics utility which keeps track of packets with invalid MAC addresses. Are the packets with zero MAC addresses be classified as invalid? In theory, no-- 00:00:00 OUI belongs to Xerox, and there is nothing special about an all-zeros MAC. If you see an OUI with the second bit of the first octet set, that would indicate locally managed addresses rather than global or "universally administered" numbering, otherwise you can lookup against OUI data from the IEEE: http://standards.ieee.org/develop/regauth/oui/oui.txt ...and that will let you identify the vendor of the ethernet NIC, SAS/fibre channel controller, etc...or conclude that someone is likely spoofing MAC addresses if you don't find the OUI listed. Maybe that's what you mean by "invalid"? Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 00:16:16 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E294106566C for ; Thu, 15 Mar 2012 00:16:16 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id 5390D8FC16 for ; Thu, 15 Mar 2012 00:16:16 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com (unknown [17.209.4.71]) by asmtp028.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0M0W006FWDYCAX40@asmtp028.mac.com> for freebsd-net@freebsd.org; Wed, 14 Mar 2012 16:15:49 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498,1.0.260,0.0.0000 definitions=2012-03-14_06:2012-03-14, 2012-03-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1203140258 From: Chuck Swiger In-reply-to: <5E4F49720D0BAD499EE1F01232234BA87438162FAE@AVEXMB1.qlogic.org> Date: Wed, 14 Mar 2012 16:15:48 -0700 Message-id: References: <5E4F49720D0BAD499EE1F01232234BA87438162F95@AVEXMB1.qlogic.org> <1AB6F524-B4F4-4718-96C5-DB2951A02D59@mac.com> <5E4F49720D0BAD499EE1F01232234BA87438162FAE@AVEXMB1.qlogic.org> To: Adarsh Joshi X-Mailer: Apple Mail (2.1084) Cc: "freebsd-net@freebsd.org" Subject: Re: Zero MAC address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 00:16:16 -0000 On Mar 14, 2012, at 4:05 PM, Adarsh Joshi wrote: > Thank you for the quick replies. > > I am aware of the importance of the second bit. By invalid, I was wondering if that particular address is reserved or if it has any special meaning or purpose. There isn't a special meaning for all-zeros MAC to my knowledge, although all-ones MAC is subnet-local broadcast. > So in theory, I cannot classify it as an invalid MAC address on my packet statistics utility. Yes, as far as theory goes. In practice, all-zeros MACs tend to indicate that an ethernet driver failed to read the burned-in MAC assigned to the NIC. :-) > On a side thought, can an incoming packet be classified as "invalid MAC address" if it has the same MAC address of the host? Tentatively, yes-- MACs are supposed to be unique, and any collision is bad...just be careful that you aren't seeing packets which your local host had sent (perhaps because of a L2 switching loop). Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 02:04:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A61BB106564A for ; Thu, 15 Mar 2012 02:04:34 +0000 (UTC) (envelope-from nyoman.bogi@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0D78D8FC19 for ; Thu, 15 Mar 2012 02:04:33 +0000 (UTC) Received: by lboi15 with SMTP id i15so1572059lbo.13 for ; Wed, 14 Mar 2012 19:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bVY063uVZ4rXZBjwH+IY1HlI+NVqgVYoEOOJzM1AZgA=; b=Hzr1vDNRUcvt+NUHYTRgafIZdAl1WHwoibcyvS0lcTjXJDaYvCRLIMzZUPopvClZw1 fN+h2xgm8XNbtnhiHjYNMXDnGJRGF5A7wGk5n422E5hPWyUoNhSEvVp3oIwkPQvc/Ha3 qyq0XR1AjCwJ5T/tlEJluhogLEY23gHvHhFc/bgIoZi80YEDmjjyXdcXionxgcyEf7aH qMiQldDCOuSSw49CM0Wgo2IYvuP1TVps0p5lnfhYco69WOFmKTxUzUTKQ37J4Fx7jybC FtHrub+n8lvjf1blHxcUVu3l3sxP/PXRyBhkn0aSPqvyRCECr7/hUAPNkNyNwS2qslug Dl6g== MIME-Version: 1.0 Received: by 10.152.132.130 with SMTP id ou2mr3607785lab.44.1331777063875; Wed, 14 Mar 2012 19:04:23 -0700 (PDT) Received: by 10.112.115.130 with HTTP; Wed, 14 Mar 2012 19:04:23 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Mar 2012 09:04:23 +0700 Message-ID: From: "nyoman.bogi@gmail.com" To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: firewall stuck X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 02:04:34 -0000 thanks Kevin, this is my "ipfw show" : 00100 4352617 2413620288 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 00400 0 0 deny ip from any to ::1 00500 0 0 deny ip from ::1 to any 00600 54387 5454184 allow icmp from any to any 00700 3142231 1681082246 allow ip from 10.1.1.28 to 10.1.1.0/26 00800 4659459 4478397111 allow ip from 10.1.1.0/26 to 10.1.1.28 00900 0 0 check-state 01000 137997 89083135 allow tcp from 10.1.1.28 to any setup keep-state 01100 0 0 allow tcp from 10.16.10.84 to any setup keep-state 01150 401205 276677828 allow tcp from any to 10.1.1.28 dst-port 22 setup keep-state 01200 245718 44249729 allow udp from 10.1.1.28 to any keep-state 01300 5876930 239194755 allow tcp from any to any established 01400 0 0 allow tcp from any to 10.1.1.28 dst-port 389 setup keep-state 01500 26341187 22030370786 allow tcp from any to 10.1.1.28 dst-port 80 setup keep-state 01600 80945 61013964 allow tcp from any to 10.1.1.28 dst-port 443 setup keep-state 01700 0 0 allow tcp from 10.1.1.2 to 10.1.1.28 dst-port 22 setup keep-state 01800 149642 97939477 allow tcp from any to 10.1.1.28 dst-port 25 setup keep-state 01900 140 7501 allow tcp from 10.1.0.0/16 to 10.1.1.28 dst-port 110 setup keep-state 02000 1677982 89212845 allow tcp from any to 10.1.1.28 dst-port 110 setup keep-state 02100 8996 432096 deny tcp from any to any setup 02200 244111 24117256 allow udp from any to 10.1.1.28 dst-port 53 keep-state 02300 0 0 allow udp from any to 10.1.1.12 dst-port 53 keep-state 65535 4610 1422974 deny ip from any to any I use FreeBSD 8.2 : FreeBSD 8.2-RELEASE (GENERIC) #0: Fri Feb 18 02:24:46 UTC 2011 the problem start after I add rule 01150 On Wed, Mar 14, 2012 at 1:12 PM, Kevin Oberman wrote: > On Tue, Mar 13, 2012 at 7:27 PM, nyoman.bogi@gmail.com > wrote: > > dear guru, > > > > every time I open my firewall to allow SSH connection from Internet > > after few days my firewall always stuck. Stuck in here meaning > > that it deny all request (deny any from any). > > And after I "ipfw disable firewall" and then "ipfw enable firewall" > > everything works fine > > > > when I checked /var/log/messages I found lots of attempts > > people try to connect to my machine. > > why my machine get stuck when lots of people try to SSH to my machine? > > We need a bit more information, especially your ipfw configuration. Is > it a statefull firewall? It sounds a lot like your state table might > be filling for some reason. Of course, if it is not a statefull > firewall, that idea is probably wrong, though it could be a > misconfiguration of some statefull rule that is inadvertently catching > the SSH attempts. > > Have you done an 'ipfw show' to see what rules are being matched? it > may or may not provide a clue. > -- > R. Kevin Oberman, Network Engineer > E-mail: kob6558@gmail.com > -- ------------------------------- Bogi Aditya Sisfo - IMTelkom http://bogi.blog.imtelkom.ac.id From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 04:53:24 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2757A106566B for ; Thu, 15 Mar 2012 04:53:24 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mx1.freebsd.org (Postfix) with ESMTP id AC8228FC15 for ; Thu, 15 Mar 2012 04:53:23 +0000 (UTC) Received: by wibhr17 with SMTP id hr17so7127228wib.1 for ; Wed, 14 Mar 2012 21:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oenZDYvDPWVS4a0+kPZYEy4RHzjgIhBzd0RghIk6elE=; b=EQ6lh96SR8puB9sdKNs0k0mZXFD3329ajW4DsfPsMl0o9sC75v1eTifN3vO8XYFKyr fuTq/kOwoEZ0omt7YysyqwIho+k8ygW9AQAfJZiPdMAJ/v7KpxKZkMVLl7+XPt5KuHiP A7Tzqi8fVnc+jcVKq7sBpVqSdY296IMVlum0U3AgwblehRx9/G2LUQhXE/g/FFDZyHj3 XDUGWl7t3XeeMc+e8eEmmxim0U65vICYfS1hxmpY88x2ax4PVzThPkmH1g9Dra6UHFxw Ed9kl4HKxxz550b82oSY/Cz9LIW0rB8cwCBF0VFzd2D8bTsDI0tTFBwDr7srOdtu4lGH 3prg== MIME-Version: 1.0 Received: by 10.180.104.137 with SMTP id ge9mr12012384wib.20.1331786828778; Wed, 14 Mar 2012 21:47:08 -0700 (PDT) Received: by 10.223.143.3 with HTTP; Wed, 14 Mar 2012 21:47:08 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Mar 2012 20:47:08 -0800 Message-ID: From: Kevin Oberman To: "nyoman.bogi@gmail.com" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: firewall stuck X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 04:53:24 -0000 Please don't top post. It makes following the thread very difficult. (Yes, I know too many MUAs make this difficult.) > On Wed, Mar 14, 2012 at 1:12 PM, Kevin Oberman wrote: >> >> On Tue, Mar 13, 2012 at 7:27 PM, nyoman.bogi@gmail.com >> wrote: >> > dear guru, >> > >> > every time I open my firewall to allow SSH connection from Internet >> > after few days my firewall always stuck. Stuck in here meaning >> > that it deny all request (deny any from any). >> > And after I "ipfw disable firewall" and then "ipfw enable firewall" >> > everything works fine >> > >> > when I checked /var/log/messages I found lots of attempts >> > people try to connect to my machine. >> > why my machine get stuck when lots of people try to SSH to my machine? >> >> We need a bit more information, especially your ipfw configuration. Is >> it a statefull firewall? It sounds a lot like your state table might >> be filling for some reason. Of course, if it is not a statefull >> firewall, that idea is probably wrong, though it could be a >> misconfiguration of some statefull rule that is inadvertently catching >> the SSH attempts. >> >> Have you done an 'ipfw show' to see what rules are being matched? it >> may or may not provide a clue. >> -- >> R. Kevin Oberman, Network Engineer >> E-mail: kob6558@gmail.com On Wed, Mar 14, 2012 at 6:04 PM, nyoman.bogi@gmail.com wrote: > thanks Kevin, > this is my "ipfw show" : > > 00100 4352617 2413620288 allow ip from any to any via lo0 > 00200 0 0 deny ip from any to 127.0.0.0/8 > 00300 0 0 deny ip from 127.0.0.0/8 to any > 00400 0 0 deny ip from any to ::1 > 00500 0 0 deny ip from ::1 to any > 00600 54387 5454184 allow icmp from any to any > 00700 3142231 1681082246 allow ip from 10.1.1.28 to 10.1.1.0/26 > 00800 4659459 4478397111 allow ip from 10.1.1.0/26 to 10.1.1.28 > 00900 0 0 check-state > 01000 137997 89083135 allow tcp from 10.1.1.28 to any setup keep-state > 01100 0 0 allow tcp from 10.16.10.84 to any setup > keep-state > 01150 401205 276677828 allow tcp from any to 10.1.1.28 dst-port 22 setup > keep-state > 01200 245718 44249729 allow udp from 10.1.1.28 to any keep-state > 01300 5876930 239194755 allow tcp from any to any established > 01400 0 0 allow tcp from any to 10.1.1.28 dst-port 389 > setup keep-state > 01500 26341187 22030370786 allow tcp from any to 10.1.1.28 dst-port 80 setup > keep-state > 01600 80945 61013964 allow tcp from any to 10.1.1.28 dst-port 443 > setup keep-state > 01700 0 0 allow tcp from 10.1.1.2 to 10.1.1.28 dst-port 22 > setup keep-state > 01800 149642 97939477 allow tcp from any to 10.1.1.28 dst-port 25 setup > keep-state > 01900 140 7501 allow tcp from 10.1.0.0/16 to 10.1.1.28 dst-port > 110 setup keep-state > 02000 1677982 89212845 allow tcp from any to 10.1.1.28 dst-port 110 > setup keep-state > 02100 8996 432096 deny tcp from any to any setup > 02200 244111 24117256 allow udp from any to 10.1.1.28 dst-port 53 > keep-state > 02300 0 0 allow udp from any to 10.1.1.12 dst-port 53 > keep-state > 65535 4610 1422974 deny ip from any to any > > I use FreeBSD 8.2 : > FreeBSD 8.2-RELEASE (GENERIC) #0: Fri Feb 18 02:24:46 UTC 2011 > > the problem start after I add rule 01150 so you do have a stateful rule for ssh. Putting stateful rules on services is risky because you always open yourself to DOS, ether intentionally or by accident. Every stateful access requires resources from a limited pool. You can look at this pool information with: sysctl net.inet.ip.fw | grep dyn man ipfw describes them in the "SYSCTL VARIABLES" section. I am wondering why you want a stateful rule for this. It's very risky and it looks like you are getting bitten, either by accident or a deliberate effort to DOS you. I suspect the former. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 04:57:04 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56852106566C for ; Thu, 15 Mar 2012 04:57:04 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id AAEE28FC19 for ; Thu, 15 Mar 2012 04:57:03 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q2F4uxjI090961; Thu, 15 Mar 2012 11:57:00 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4F61769B.2040809@rdtc.ru> Date: Thu, 15 Mar 2012 11:56:59 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: hiren panchasara References: <4F607EDF.4010505@rdtc.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: Use of network_interfaces in rc.conf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 04:57:04 -0000 15.03.2012 06:33, hiren panchasara РЙЫЕФ: > network_interfaces is basically historic rudiment > used in 2.2.x FreeBSD version and alike. > > In general, you should not use it in modern version at all. > > > Thanks Eugene. > > So, the only way to specify boottime configuration (that survives reboots) for an interface in rc.conf is: > ifconfig_em0="dhcp" ? Yes, thats what man rc.conf says. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 07:14:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED22A1065670; Thu, 15 Mar 2012 07:14:15 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2EA6E8FC14; Thu, 15 Mar 2012 07:14:14 +0000 (UTC) Received: by lagv3 with SMTP id v3so2958820lag.13 for ; Thu, 15 Mar 2012 00:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=K6XgLHNz0GkZ/ypk8akl5gg66lk+E5vk4XWn8S70TjM=; b=hQ5nttDzFNt0blCZBevFTCScfS4R9iuJ8/YS8Sa1Kln32wV/wTfelh7W4wqDwtk02z DxvgOaCE4m+Sfs0zdB7Eq2gqIFDn6PjRY5YSmAiUaP4Hm+APZWX5/CzIj9NywUp3HtPk x+oUqqS2P7wpilYAmozfKMBCNuX9BPfv0vocSMxBM230SarOr5p1S1B9RZj2a3gjyLOh MJ0xPvfHpyQXUds4Nd6skZbW8NEgMlRm2QAX8HOJippkV2zIxQ1s7kG6TrPKXLrHT/wM Od5uK2LwUjksph1PX0FpHjynfNjEJL9c0fgiyX0nfss5wWuLQ9tncb/Vsd0xDhU55Po9 1jGw== MIME-Version: 1.0 Received: by 10.152.133.68 with SMTP id pa4mr448791lab.12.1331795653878; Thu, 15 Mar 2012 00:14:13 -0700 (PDT) Sender: pluknet@gmail.com Received: by 10.152.21.73 with HTTP; Thu, 15 Mar 2012 00:14:13 -0700 (PDT) In-Reply-To: <5E4F49720D0BAD499EE1F01232234BA87438162FA4@AVEXMB1.qlogic.org> References: <5E4F49720D0BAD499EE1F01232234BA87438162FA4@AVEXMB1.qlogic.org> Date: Thu, 15 Mar 2012 10:14:13 +0300 X-Google-Sender-Auth: kl77sVak8cX0bqpPA87Le9PeBu4 Message-ID: From: Sergey Kandaurov To: Adarsh Joshi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , "freebsd-drivers@freebsd.org" Subject: Re: crash on lagg interface destroy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 07:14:16 -0000 On 15 March 2012 02:48, Adarsh Joshi wrote: > Hello everyone, > > I tried to destroy a lagg interface (created using laggproto none) and I = see the system crash. > > Steps to reproduce: > Kldload if_lagg > Ifconfig lagg0 create > ifconfig lagg0 up laggproto none laggport ql0 laggport ql1 192.168.100.1 = netmask 255.255.255.0 > ifconfig lagg0 destroy > > uname -a > FreeBSD bsd-02 7.4-RELEASE FreeBSD 7.4-RELEASE #0: Wed Mar =A07 18:16:06 = PST 2012 =A0 =A0 root@bsd-02:/usr/src/sys/amd64/compile/MYKERNEL =A0amd64 > > Crash: > > Tracing command ifconfig pid 1443 tid 100182 td 0xffffff0023358740 > Uart_z8530_class() at 0 > Ifc_simple_destroy() at Ifc_simple_destroy+0x2a > If_clone_destroyif() at If_clone_destroyif+0xa5 > Ifioctl() at ifioctl+0x300 > Kern_ioctl() at kern_ioctl+0xa2 > Ioctl() at ioctl+0xf9 > Syscall() at syscall+0x252 > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (54, FreeBSD ELF64, ioctl), rip =3D 0x8008324bc, rsp =3D 0x7f= ffffffe348, rbp =3D 0x7ffffffffee27 --- This is just a thought. This thread has probably lost the race when tried to take a valid pointer to ifnet for the given interface using ifunit() function (as done in if_clone_destroyif()) and then is de-referencing a pointer to an already freed memory. Since FreeBSD 8.1 this was changed to use ifunit_ref() to protect ifnet pointer against early destroy by reference counting the ifnet pointer. But this function doesn't exists in 7.x. If this is the case, then this should be easily reproduced when two parallel threads are trying to destroy the cloned interface. So, first I'd try to upgrade to 8.1 or above. --=20 wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 07:21:06 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50CAB1065670 for ; Thu, 15 Mar 2012 07:21:06 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 0B0038FC12 for ; Thu, 15 Mar 2012 07:21:05 +0000 (UTC) Received: from conversation.bsdunix.ch (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id 69D1BBD8D for ; Thu, 15 Mar 2012 07:13:49 +0000 (UTC) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by conversation.bsdunix.ch (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pHpitSClUTpr for ; Thu, 15 Mar 2012 07:13:23 +0000 (UTC) Received: from Flachrechner.local (dmhd.bsdunix.ch [82.220.17.25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTPSA id 751A7BD84 for ; Thu, 15 Mar 2012 07:13:23 +0000 (UTC) Message-ID: <4F619693.7040200@bsdunix.ch> Date: Thu, 15 Mar 2012 08:13:23 +0100 From: Thomas User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: 6RD Support (2012)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 07:21:06 -0000 Hello Is there a 6RD patch for FreeBSD9? The only patch I see is for Freebsd8: http://bougaidenpa.org/masakazu/wp-content/uploads/2010/01/freebsd8-6rd-20100130.patch.gz Regards, Thomas From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 07:39:51 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B24A7106564A for ; Thu, 15 Mar 2012 07:39:51 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 409218FC08 for ; Thu, 15 Mar 2012 07:39:50 +0000 (UTC) Received: by wern13 with SMTP id n13so3268591wer.13 for ; Thu, 15 Mar 2012 00:39:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type:content-transfer-encoding :x-gm-message-state; bh=R7f5J/4/kh+KbJOPnQYkHPSXWqh9ucwfDndyLUi8RBs=; b=KcogfpR4RcJ2dEBfLcHAFhVkZ2cx6DmjS8QNvNqwpqVrnY38JtRApOrSa30ozm9E/b 1bU/PCrEjOHqM39XZHDUaGagqydSDWrGgytqD6Qi1vLeR3YAQimuj7F4K4C57twdBtN1 U2Rl8clYTUQgKEQAsAQ99dcwwkPtYLcBGkGofh8+6dCpTnEreEEm31bdaVfeQEBJ4Axv w5T01XpAVEgcVwqQDZjJELEZ4s5qi45P572grkzZ/SgOwRWFhwXeqU9OGCHtt3TZ4w4O G+VGGn4BptMnDKXUkBdS/Q2oDkjaAdg8ge8FTXHDoODu5ucahzX8yGpWb2M/lqs+3oI2 yHiw== Received: by 10.216.134.155 with SMTP id s27mr3815691wei.80.1331797190147; Thu, 15 Mar 2012 00:39:50 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.180.96.231 with HTTP; Thu, 15 Mar 2012 00:39:30 -0700 (PDT) From: Juli Mallett Date: Thu, 15 Mar 2012 00:39:30 -0700 X-Google-Sender-Auth: boPVFp2BDv2pp0XGSiaFsIy1PXk Message-ID: To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm46UI3AYdHme8J0+dhs5aVMMOWoEGlmXCnklZqKNSvfKWLu20ynkeg/Rgl6hyqwAI9hcVm Subject: MSI-X + em(4) = Refresh mbufs: hdr dmamap load failure - 22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 07:39:51 -0000 All, On both stable/9 and trunk I see that with one of either the 82571EB or 82574L I am flooded with messages in the form of: Refresh mbufs: hdr dmamap load failure - 22 If I disable msix, then the messages go away. I am not sure why msix vs. non-msix would matter in this case unless in the msix case there's some kind of case of spurious interrupts causing em_rxeof to be called without any packets available. If that happens then perhaps e1000_rx_unrefreshed() is called when no buffers have been processed and then em_refresh_mbufs wrongly refreshes the whole ring? This seems like it would be a problem because the bus_dmamap_load_mbuf_sg code is called unconditionally, even when a new mbuf isn't being allocated. In that case, the mapping already exists. Wouldn't it be necessary to unload and then reload the mbuf? So either it's a bug that em_refresh_mbufs is being called at all, or it's naively reusing mbufs in a way that actually guarantees an error, right? Also, in the case where it frees, only m_free is called =E2=80=94 i= s there never a case where that should be an m_freem? I can imagine some, but they are likely impossible with the receive path of the driver. (I don't know for sure because the receive path and the mbuf refresh code keep changing and I've been unable to keep up.) I don't know which part it is, of course, because I don't know what port it's coming from. Like three other printfs in the driver where which device is being used matters tremendously, it uses a bare printf and not a device_printf. I could modify the driver, but for now disabling msix is easier than continuing to load new kernels to try to debug the problem. Is anyone else seeing this? Has anyone further investigated the problem? Is there a patch floating around and I just haven't found the right search terms? Thanks in advance, Juli. PS: Yes, I know this is kind of a crappy bug report, sorry. I've had a limited amount of time to investigate so far, and don't want to delay reporting it until I am able to get more time with the problematic hardware. From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 08:37:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D3C371065670; Thu, 15 Mar 2012 08:37:34 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx1.freebsd.org (Postfix) with ESMTP id 8093B8FC14; Thu, 15 Mar 2012 08:37:34 +0000 (UTC) Received: by dadp14 with SMTP id p14so12293111dad.18 for ; Thu, 15 Mar 2012 01:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Yrc/B0YQdpCldJQ2Yd0BBD1cQv0nYwifyMyXityR81c=; b=jDRcjQys7li9SblENqW3Knt7YQ2F937bH4ZyFrdqkqsfqAzjVV6/bhhClWyhOcEjBY YE5UnwOoVTQLdZt6PP55LZscBtd8SlqR2f19ldPK9iZ0c78gDgyIPcgBfMA4I2sHks4c FqaDFcqyvLXc9r0ffHZPUpluqCfuMdEGgZWzui7QbWYa0/SJx8JFWB5RN6ZhV67hVhU+ s/HDaSoDH6Me3aBpbEoE6PnDTQrQKWN9d7/xbvm0hTFnOLd9nEEUbhW/5TZExFszYRsd t6qG1v5pSIFjIoeWOz4/n9kh+10YffhJXUOOd57V5QCFkTW22LdxpH/PmMrCgBOMYSus UsUA== Received: by 10.68.236.3 with SMTP id uq3mr3371946pbc.63.1331800654334; Thu, 15 Mar 2012 01:37:34 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id b10sm1407561pbr.46.2012.03.15.01.37.31 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Mar 2012 01:37:33 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 15 Mar 2012 17:37:29 -0700 From: YongHyeon PYUN Date: Thu, 15 Mar 2012 17:37:29 -0700 To: Juli Mallett Message-ID: <20120316003729.GA3872@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: MSI-X + em(4) = Refresh mbufs: hdr dmamap load failure - 22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 08:37:34 -0000 On Thu, Mar 15, 2012 at 12:39:30AM -0700, Juli Mallett wrote: > All, > > On both stable/9 and trunk I see that with one of either the 82571EB > or 82574L I am flooded with messages in the form of: > > Refresh mbufs: hdr dmamap load failure - 22 > > If I disable msix, then the messages go away. I am not sure why msix > vs. non-msix would matter in this case unless in the msix case there's > some kind of case of spurious interrupts causing em_rxeof to be called > without any packets available. If that happens then perhaps > e1000_rx_unrefreshed() is called when no buffers have been processed > and then em_refresh_mbufs wrongly refreshes the whole ring? > > This seems like it would be a problem because the > bus_dmamap_load_mbuf_sg code is called unconditionally, even when a > new mbuf isn't being allocated. In that case, the mapping already > exists. Wouldn't it be necessary to unload and then reload the mbuf? > So either it's a bug that em_refresh_mbufs is being called at all, or > it's naively reusing mbufs in a way that actually guarantees an error, > right? Also, in the case where it frees, only m_free is called ??? is > there never a case where that should be an m_freem? I can imagine > some, but they are likely impossible with the receive path of the > driver. (I don't know for sure because the receive path and the mbuf > refresh code keep changing and I've been unable to keep up.) > > I don't know which part it is, of course, because I don't know what > port it's coming from. Like three other printfs in the driver where > which device is being used matters tremendously, it uses a bare printf > and not a device_printf. I could modify the driver, but for now > disabling msix is easier than continuing to load new kernels to try to > debug the problem. > > Is anyone else seeing this? Has anyone further investigated the Some time ago I also tried to debug low performance issue of 82574. At that time I didn't encounter the issue you mentioned but I saw spurious interrupts with MSI-X. This issue is also mentioned in 82574 data sheet(7.4.5 Clearing Interrupt Causes). However I couldn't explain odd interrupt behavior(interrupt moderation, MSI vs. MSI-X) of controller since the controller did not work as described in data sheet. > problem? Is there a patch floating around and I just haven't found > the right search terms? > > Thanks in advance, > Juli. > > PS: Yes, I know this is kind of a crappy bug report, sorry. I've had > a limited amount of time to investigate so far, and don't want to > delay reporting it until I am able to get more time with the > problematic hardware. From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 10:57:10 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1726106564A for ; Thu, 15 Mar 2012 10:57:10 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 52B948FC15 for ; Thu, 15 Mar 2012 10:57:10 +0000 (UTC) Received: by wern13 with SMTP id n13so3475232wer.13 for ; Thu, 15 Mar 2012 03:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=z2zjJfiBR4aWU+8e9jTt8VTUjZkAGjULZpUmBUPDNyM=; b=Zq0FUd8CGDguRz4CZYXsmEvzPJTKZOOgA+SSK4yE2rAXKdPMnd7jkLPi0m2JlCWaHr ymj7aPvbPGnGamnBs8Y/YP5iYmGL3j2y6quSDnY1n2/1GPNalLgLHrSklD6wOWJJfsto 0o5StjJGb2ZgQUtvT2d5rU/OE1SY0TI6NuTBcmL7rNA4MKKZ1C1wxikXDXBboE/BNUjn AhhoS7gVez9kvzaX0LV/OZp/qFwyu7cLJTxB/1ucGXXeBcYjgLypCrHgMu4Z9eM/NLj1 h4Z7ushfAU5wsdOpyPkAOKWW8D/Ukwk5j0xzG7ssMQ0dDJaq8D6IKJJ5oapDBc765ZUu R/rA== MIME-Version: 1.0 Received: by 10.216.133.234 with SMTP id q84mr3672610wei.102.1331809029417; Thu, 15 Mar 2012 03:57:09 -0700 (PDT) Received: by 10.180.102.6 with HTTP; Thu, 15 Mar 2012 03:57:09 -0700 (PDT) Date: Thu, 15 Mar 2012 06:57:09 -0400 Message-ID: From: grarpamp To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Stuck in FIN_WAIT_2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 10:57:10 -0000 Hi. I've got 900-1000 connections stuck in FIN_WAIT_2. The processes behind them on both sides have long since exited. Anything I can do to clear them out short of reboot? The box is 4.11, so no tcpdrop to try. I suspect this may be starting to limit mbuf clusters. Not sure. The box is idle. If in this state the kernel sends packets, would ipfw reset rule clear it? No big deal. From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 14:07:50 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8FC21065672 for ; Thu, 15 Mar 2012 14:07:50 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 52B358FC14 for ; Thu, 15 Mar 2012 14:07:49 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so7254824wib.13 for ; Thu, 15 Mar 2012 07:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=yQDQCPBV2BhU8Zj4T4kfHoUPqAfLxIDVcWCBFGhtIos=; b=bhorE3D8eerMx7k3dyaPO1WE/QooFnpLmEz1oVUrYuJYTzt48dkeptpIO6qfCui21m hm4jNXGwCaOYLDTD4znfU0FV2LDT8nZT5RxUu0etnqnLY4wpcQzLOCKFFqJGA1xDsSVl 2FEZ2daTTKnpyxF+moezl3n9ItWxJPA2BSW3YckD0gmVflxhQMVm1WP7/OemMcSq1kwU 0+JVSkWB597KQQ/fLRhpaMHQCT62JEvnemGlJkH3iyIVZDLRqMCVy3eTTsxzdOuo6fr5 2WCx8f2RZNY2GwEKPeLGgahjTneWWXJdU9wgZfbL8osgcZJept27S+LLfCZDUELS4Vj+ 25mA== Received: by 10.180.107.164 with SMTP id hd4mr22809127wib.18.1331820469210; Thu, 15 Mar 2012 07:07:49 -0700 (PDT) Received: from ndenevsa.sf.moneybookers.net (g1.moneybookers.com. [217.18.249.148]) by mx.google.com with ESMTPS id df3sm5384706wib.1.2012.03.15.07.07.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Mar 2012 07:07:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: Date: Thu, 15 Mar 2012 16:07:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0F2031C9-3A37-4994-BBE7-869D9F975170@gmail.com> References: To: grarpamp X-Mailer: Apple Mail (2.1257) Cc: freebsd-net@freebsd.org Subject: Re: Stuck in FIN_WAIT_2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 14:07:50 -0000 On Mar 15, 2012, at 12:57 PM, grarpamp wrote: > Hi. I've got 900-1000 connections stuck in FIN_WAIT_2. > The processes behind them on both sides have long > since exited. Anything I can do to clear them out > short of reboot? The box is 4.11, so no tcpdrop to try. > I suspect this may be starting to limit mbuf clusters. > Not sure. The box is idle. If in this state the kernel sends > packets, would ipfw reset rule clear it? No big deal. > _______________________________________________ > 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" Hi, I'm not sure if 4.11 has the following sysctls, but you can try them if = they exist : net.inet.tcp.finwait2_timeout <-- lower this net.inet.tcp.fast_finwait2_recycle <-- set this to 1 Regards, Nikolay= From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 14:34:38 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F88D106564A; Thu, 15 Mar 2012 14:34:38 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id C08468FC0A; Thu, 15 Mar 2012 14:34:37 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id AFE2725D3893; Thu, 15 Mar 2012 14:34:36 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 07FE1BDD73B; Thu, 15 Mar 2012 14:34:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 1qqcxDCeYs-0; Thu, 15 Mar 2012 14:34:35 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 2F76ABDD73E; Thu, 15 Mar 2012 14:34:35 +0000 (UTC) From: "Bjoern A. Zeeb" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Mar 2012 14:34:33 +0000 Message-Id: To: FreeBSD Networking Mailing List Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: "Alexander V. Chernikov" Subject: multi-FIB changes for GENERIC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 14:34:38 -0000 Hi, back in September last year I had prototyped a patch to make the = multi-FIB kernel option just a default removing the need for it to be set for the maximum number of FIBs allowed. This is allowing the multi-FIB feature = to be used with GENERIC kernels by just changing the tunable. Thanks to Alexander eliminating the last consumers of RT_NUMFIBS in = code, this is now possible. I haven't boot-tested the re-done patch below yet but = it should be fine and passes the compile test. Please test and review. This is also a next step to allow growing the number of FIBs available = more easily in the future (subject to mbuf changes). http://people.freebsd.org/~bz/20120315-01-rt_numfibs.diff /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 16:07:42 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3121E106564A; Thu, 15 Mar 2012 16:07:42 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 499958FC21; Thu, 15 Mar 2012 16:07:41 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so7412392wib.13 for ; Thu, 15 Mar 2012 09:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CQkd3lno8FuLyoYJpAvTne3D7qiRnt+w30t47a1P9lY=; b=SOR+qXMA+QlS0qiJLn0l8hXJ6MbXNOnmoyZOZFjU0hM6sh/b5xqch4Q84raSiQbK4V 1C/0fFC6LSJMjo2EhbCTFkui0RepqVXIV7ORYnzEpEAbeY228HlIY+iHaxHI9cJhoAwm ZhqZ/r/8JaXvsqbdMBNMCb7xeX5eHlCbFmaN5nGF9N55UuLGPgOh3+SfuuWAej70P8rr 8rul9FTBGLa9frnndG1sMEsGDCQ9hHwcb7eMAiqTn0tnHzyNpRy3PioYv8Dcen77khna MRDhFJBnns29DzVBWVMxhtaYPYOTQlc6axjt6iCu+a5zCT6HYXh2qlqPHtpx4lrbeXpR sB3g== MIME-Version: 1.0 Received: by 10.180.81.135 with SMTP id a7mr22015761wiy.16.1331827660489; Thu, 15 Mar 2012 09:07:40 -0700 (PDT) Received: by 10.180.82.168 with HTTP; Thu, 15 Mar 2012 09:07:40 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Mar 2012 09:07:40 -0700 Message-ID: From: Jack Vogel To: Juli Mallett Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: MSI-X + em(4) = Refresh mbufs: hdr dmamap load failure - 22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 16:07:42 -0000 You have header split on?? I've not seen this before so something odd is going on. Jack On Thu, Mar 15, 2012 at 12:39 AM, Juli Mallett wrote= : > All, > > On both stable/9 and trunk I see that with one of either the 82571EB > or 82574L I am flooded with messages in the form of: > > Refresh mbufs: hdr dmamap load failure - 22 > > If I disable msix, then the messages go away. I am not sure why msix > vs. non-msix would matter in this case unless in the msix case there's > some kind of case of spurious interrupts causing em_rxeof to be called > without any packets available. If that happens then perhaps > e1000_rx_unrefreshed() is called when no buffers have been processed > and then em_refresh_mbufs wrongly refreshes the whole ring? > > This seems like it would be a problem because the > bus_dmamap_load_mbuf_sg code is called unconditionally, even when a > new mbuf isn't being allocated. In that case, the mapping already > exists. Wouldn't it be necessary to unload and then reload the mbuf? > So either it's a bug that em_refresh_mbufs is being called at all, or > it's naively reusing mbufs in a way that actually guarantees an error, > right? Also, in the case where it frees, only m_free is called =97 is > there never a case where that should be an m_freem? I can imagine > some, but they are likely impossible with the receive path of the > driver. (I don't know for sure because the receive path and the mbuf > refresh code keep changing and I've been unable to keep up.) > > I don't know which part it is, of course, because I don't know what > port it's coming from. Like three other printfs in the driver where > which device is being used matters tremendously, it uses a bare printf > and not a device_printf. I could modify the driver, but for now > disabling msix is easier than continuing to load new kernels to try to > debug the problem. > > Is anyone else seeing this? Has anyone further investigated the > problem? Is there a patch floating around and I just haven't found > the right search terms? > > Thanks in advance, > Juli. > > PS: Yes, I know this is kind of a crappy bug report, sorry. I've had > a limited amount of time to investigate so far, and don't want to > delay reporting it until I am able to get more time with the > problematic hardware. > _______________________________________________ > 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 Mar 15 16:45:41 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26F37106566B; Thu, 15 Mar 2012 16:45:41 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 457C48FC0C; Thu, 15 Mar 2012 16:45:40 +0000 (UTC) Received: by wern13 with SMTP id n13so3961907wer.13 for ; Thu, 15 Mar 2012 09:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2R7xK1zJzuNP6Wti45xyzDliBLj5TqUU1EV2LqfVIwE=; b=ESHfatG7S69+2nWejTyRmkJ7parJ/S8ch1e+N3KIuA7OGXSPSRJaGRKPDtVk896X4F Y4+qmKg7AHKwPgmrpk8JIQ46rylaeAQ3GKKHT+2ZqV0oRkse8Gevu15wBE/6WYIb23mu bHryc0rRsTMV393B7gzhT6IAbARbBfiUAf86ldtfCEESKXsdcWyAEpFXzVfnAzrxXJeb EUgcaQ99izWYFykcW1RgDRhnxoRuwKMJ2lEAMVeJljEhOyG+npopv76D6WEjInWkLEPA s3Vnn/HkyE0qsK0o+ganAQMmf0YkJL7XtkgHV+hw2gtBx5Nw3sGIEr3E6xJhWzfVeSlE UAmA== MIME-Version: 1.0 Received: by 10.180.82.132 with SMTP id i4mr27991027wiy.12.1331829939408; Thu, 15 Mar 2012 09:45:39 -0700 (PDT) Received: by 10.216.166.139 with HTTP; Thu, 15 Mar 2012 09:45:39 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Mar 2012 12:45:39 -0400 Message-ID: From: Arnaud Lacombe To: Jack Vogel Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Juli Mallett , freebsd-net@freebsd.org Subject: Re: MSI-X + em(4) = Refresh mbufs: hdr dmamap load failure - 22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 16:45:41 -0000 Hi, On Thu, Mar 15, 2012 at 12:07 PM, Jack Vogel wrote: > You have header split on?? I've not seen this before so something odd > is going on. > AFAIK, you never implemented header-split on em(4), despite hardware supporting it, so that question is pointless. - Arnaud > Jack > > > On Thu, Mar 15, 2012 at 12:39 AM, Juli Mallett wro= te: > >> All, >> >> On both stable/9 and trunk I see that with one of either the 82571EB >> or 82574L I am flooded with messages in the form of: >> >> Refresh mbufs: hdr dmamap load failure - 22 >> >> If I disable msix, then the messages go away. =A0I am not sure why msix >> vs. non-msix would matter in this case unless in the msix case there's >> some kind of case of spurious interrupts causing em_rxeof to be called >> without any packets available. =A0If that happens then perhaps >> e1000_rx_unrefreshed() is called when no buffers have been processed >> and then em_refresh_mbufs wrongly refreshes the whole ring? >> >> This seems like it would be a problem because the >> bus_dmamap_load_mbuf_sg code is called unconditionally, even when a >> new mbuf isn't being allocated. =A0In that case, the mapping already >> exists. =A0Wouldn't it be necessary to unload and then reload the mbuf? >> So either it's a bug that em_refresh_mbufs is being called at all, or >> it's naively reusing mbufs in a way that actually guarantees an error, >> right? =A0Also, in the case where it frees, only m_free is called =97 is >> there never a case where that should be an m_freem? =A0I can imagine >> some, but they are likely impossible with the receive path of the >> driver. =A0(I don't know for sure because the receive path and the mbuf >> refresh code keep changing and I've been unable to keep up.) >> >> I don't know which part it is, of course, because I don't know what >> port it's coming from. =A0Like three other printfs in the driver where >> which device is being used matters tremendously, it uses a bare printf >> and not a device_printf. =A0I could modify the driver, but for now >> disabling msix is easier than continuing to load new kernels to try to >> debug the problem. >> >> Is anyone else seeing this? =A0Has anyone further investigated the >> problem? =A0Is there a patch floating around and I just haven't found >> the right search terms? >> >> Thanks in advance, >> Juli. >> >> PS: Yes, I know this is kind of a crappy bug report, sorry. =A0I've had >> a limited amount of time to investigate so far, and don't want to >> delay reporting it until I am able to get more time with the >> problematic hardware. >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 17:25:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8F05106564A; Thu, 15 Mar 2012 17:25:36 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 2EB118FC0C; Thu, 15 Mar 2012 17:25:36 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so7512049wib.13 for ; Thu, 15 Mar 2012 10:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ItCkgefMntlG5wqq5DiLnTO5pfyzXD4ZECeg67NN23Y=; b=u85BkUG3zjaEuXBQZKpm+dFdQpRSSAiSNAtz5U2C41xtzKn0cTEazvee4HJAFL9+z2 ioOMhR+XkGoWnLFVJdUB6spmBMHg8EanKU41Jbs6Ocd1DJPsC3ohACKPv7OGxObqNrKu DVKzaOyD/2u94RyCRlEraMVXAF50hRFIFSENeUx+51HGNWZPtcUF/HumrHV7mJhYdddg zvNIsBw5+1Qx9H1U7c33KJu5qFkAC4esPzqMxcDka+6nnWwHv/ufHiPHsGDDC1hOn+VN W1kG9J1b6i8JePqRYU4sENFTSQ0O2JbI4KpkT32aiMq1cm6zeXbjmyDrwICIaqtHIGu2 wYuA== MIME-Version: 1.0 Received: by 10.180.94.33 with SMTP id cz1mr17670685wib.13.1331832329122; Thu, 15 Mar 2012 10:25:29 -0700 (PDT) Received: by 10.180.82.168 with HTTP; Thu, 15 Mar 2012 10:25:29 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Mar 2012 10:25:29 -0700 Message-ID: From: Jack Vogel To: Arnaud Lacombe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Juli Mallett , freebsd-net@freebsd.org Subject: Re: MSI-X + em(4) = Refresh mbufs: hdr dmamap load failure - 22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 17:25:37 -0000 Opps, you're right, hadn't had my coffee and was thinking about igb :) Still have never seen this error before. Jack On Thu, Mar 15, 2012 at 9:45 AM, Arnaud Lacombe wrote: > Hi, > > On Thu, Mar 15, 2012 at 12:07 PM, Jack Vogel wrote: > > You have header split on?? I've not seen this before so something odd > > is going on. > > > AFAIK, you never implemented header-split on em(4), despite hardware > supporting it, so that question is pointless. > > - Arnaud > > > Jack > > > > > > On Thu, Mar 15, 2012 at 12:39 AM, Juli Mallett > wrote: > > > >> All, > >> > >> On both stable/9 and trunk I see that with one of either the 82571EB > >> or 82574L I am flooded with messages in the form of: > >> > >> Refresh mbufs: hdr dmamap load failure - 22 > >> > >> If I disable msix, then the messages go away. I am not sure why msix > >> vs. non-msix would matter in this case unless in the msix case there's > >> some kind of case of spurious interrupts causing em_rxeof to be called > >> without any packets available. If that happens then perhaps > >> e1000_rx_unrefreshed() is called when no buffers have been processed > >> and then em_refresh_mbufs wrongly refreshes the whole ring? > >> > >> This seems like it would be a problem because the > >> bus_dmamap_load_mbuf_sg code is called unconditionally, even when a > >> new mbuf isn't being allocated. In that case, the mapping already > >> exists. Wouldn't it be necessary to unload and then reload the mbuf? > >> So either it's a bug that em_refresh_mbufs is being called at all, or > >> it's naively reusing mbufs in a way that actually guarantees an error, > >> right? Also, in the case where it frees, only m_free is called =97 is > >> there never a case where that should be an m_freem? I can imagine > >> some, but they are likely impossible with the receive path of the > >> driver. (I don't know for sure because the receive path and the mbuf > >> refresh code keep changing and I've been unable to keep up.) > >> > >> I don't know which part it is, of course, because I don't know what > >> port it's coming from. Like three other printfs in the driver where > >> which device is being used matters tremendously, it uses a bare printf > >> and not a device_printf. I could modify the driver, but for now > >> disabling msix is easier than continuing to load new kernels to try to > >> debug the problem. > >> > >> Is anyone else seeing this? Has anyone further investigated the > >> problem? Is there a patch floating around and I just haven't found > >> the right search terms? > >> > >> Thanks in advance, > >> Juli. > >> > >> PS: Yes, I know this is kind of a crappy bug report, sorry. I've had > >> a limited amount of time to investigate so far, and don't want to > >> delay reporting it until I am able to get more time with the > >> problematic hardware. > >> _______________________________________________ > >> freebsd-net@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >> > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 19:04:38 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCFC8106564A; Thu, 15 Mar 2012 19:04:38 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 938CF8FC08; Thu, 15 Mar 2012 19:04:38 +0000 (UTC) Received: by dald2 with SMTP id d2so5090473dal.13 for ; Thu, 15 Mar 2012 12:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=F/NNFxncur4mkZOX+agm8c21B/+qWd4asQBjP/XfufA=; b=Rau90qdpOLPjZH/1QOMco2Qi0WQWx5NC4Hw3yLy+dIGouS8W7iG5N3KxUpyHiuHz4r NVHYvsRs+q4v5NC5m+YU7Me6MGoUSnCujKHy07PonNT1C+FJFUW0HK2Uk0TaAV2txD8/ O3l5DP6Uf8sNboxvD8k/b3YNXZZWKfN90NPxlXbJurV97T4k8mr42lbUif6qd6t75+CK hLnl0Ykrj1H4D2gp5cznoMYEhC9Z69QnzYjDnIkAn7GzjSlR2jf4IxLSemIZVYnPuYvV 1IOnw8YR7Z+1Yna7EQLMzx2o9kgX7kI33U5/2IuUca2CflTtyitUAovJNZB4wo8bQQPh mrSg== MIME-Version: 1.0 Received: by 10.68.136.231 with SMTP id qd7mr7175144pbb.28.1331838278121; Thu, 15 Mar 2012 12:04:38 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Thu, 15 Mar 2012 12:04:38 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Mar 2012 12:04:38 -0700 X-Google-Sender-Auth: Jcf9_FK1uw8OjgWm3WvbwsznB2Y Message-ID: From: Adrian Chadd To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Networking Mailing List , "Alexander V. Chernikov" Subject: Re: multi-FIB changes for GENERIC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 19:04:38 -0000 Hi, I forget, is it possible to not compile in multi-FIB support? Adrian From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 19:09:45 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1379B106566B; Thu, 15 Mar 2012 19:09:45 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 8E45A8FC12; Thu, 15 Mar 2012 19:09:44 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 528CB25D3A05; Thu, 15 Mar 2012 19:09:43 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 55BD0BDD774; Thu, 15 Mar 2012 19:09:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id XyDMQpeeiqJY; Thu, 15 Mar 2012 19:09:41 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 62DE2BDD773; Thu, 15 Mar 2012 19:09:41 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: Date: Thu, 15 Mar 2012 19:09:39 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Adrian Chadd X-Mailer: Apple Mail (2.1084) Cc: FreeBSD Networking Mailing List , "Alexander V. Chernikov" Subject: Re: multi-FIB changes for GENERIC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 19:09:45 -0000 On 15. Mar 2012, at 19:04 , Adrian Chadd wrote: > Hi, >=20 > I forget, is it possible to not compile in multi-FIB support? 1) does this have anything to do with this thread? 2) yes, if you can live without your routing table, no if not. Not sure = you can spare the 240(?) bytes on 64bit if you just stay with 1 fib, but = I guess there's a lot better fish to fry. /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 19:25:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E672106564A; Thu, 15 Mar 2012 19:25:44 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1B30F8FC08; Thu, 15 Mar 2012 19:25:42 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so3282909bkc.13 for ; Thu, 15 Mar 2012 12:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=w7rLtpU8MRiS9yXN31UDqFHtHiOO/81zhSd2AJvFlqs=; b=XGv/DwIePKs3KXXXamev3DjTxQ9AUK7Vaa+zHcPj4qr+UFcHiYOLvHwz8QYK3+MJc4 WqRJFyFVtH684L8Lwjw7xBKPSD8eoMSq23qdLh7RUc7SOFnZ3VSYnFZxlRHsCeEHvzr8 yw02U2BLcaryUS7fQHIUALcNnp5WoXQHpSrCSM5fQ5fM14KUWIVCYUmg5vYOOduJo/CQ EL+QBznGiuysYOb5PAx4C/Rhev089Y/RzcRWZVBPh/yC9WBvQdoxom8Wjk2hX6y0cfg8 +4KxBMbPTuJodpsgVNAB/PfggOtdrNDNpoYfhkS9mLSAOdl4IVYccqEh2HOguJRboKLH zeIQ== Received: by 10.204.151.217 with SMTP id d25mr2966397bkw.89.1331839541878; Thu, 15 Mar 2012 12:25:41 -0700 (PDT) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id t17sm5559888bke.6.2012.03.15.12.25.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Mar 2012 12:25:39 -0700 (PDT) From: Mikolaj Golub To: Andre Oppermann References: <86ehzwwt6a.fsf@kopusha.home.net> <86r53uhibq.fsf@kopusha.home.net> <4F566A8A.3080607@freebsd.org> <86boo78itm.fsf@kopusha.home.net> <4F5E643D.3010006@freebsd.org> X-Comment-To: Andre Oppermann Sender: Mikolaj Golub Date: Thu, 15 Mar 2012 21:25:36 +0200 In-Reply-To: <4F5E643D.3010006@freebsd.org> (Andre Oppermann's message of "Mon, 12 Mar 2012 22:01:49 +0100") Message-ID: <86d38d8y4v.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Kostik Belousov , freebsd-net@freebsd.org, Pawel Jakub Dawidek Subject: Re: soreceive_stream: mbuf leak if called with mp0 and MSG_WAITALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 19:25:44 -0000 On Mon, 12 Mar 2012 22:01:49 +0100 Andre Oppermann wrote: AO> Yes, doesn't compute this way. I've put in your fix in this revision: AO> http://svn.freebsd.org/changeset/base/232867 Running your branch, smbfs tests have passed and no issues have been detected so far. -- Mikolaj Golub From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 19:50:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32DBF106566B for ; Thu, 15 Mar 2012 19:50:31 +0000 (UTC) (envelope-from seyit.ozgur@istanbul.net) Received: from spamtrap.istanbul.net (spamtrap.istanbul.net [85.111.12.34]) by mx1.freebsd.org (Postfix) with ESMTP id A6BED8FC0A for ; Thu, 15 Mar 2012 19:50:30 +0000 (UTC) X-ASG-Debug-ID: 1331841018-0426ae630318e630001-QdxwpM Received: from GAMMA.magnetdigital.local (gamma.magnetdigital.local [192.168.131.244]) by spamtrap.istanbul.net with ESMTP id SGQnubMqWQOibB7P for ; Thu, 15 Mar 2012 21:50:18 +0200 (EET) X-Barracuda-Envelope-From: seyit.ozgur@istanbul.net X-Barracuda-RBL-Trusted-Forwarder: 192.168.131.244 Received: from YUHANNA.magnetdigital.local ([fe80::1058:3088:f9b1:1346]) by GAMMA.magnetdigital.local ([fe80::3cca:d6ef:febb:fafb%17]) with mapi id 14.01.0218.012; Thu, 15 Mar 2012 21:49:29 +0200 From: =?iso-8859-1?Q?Seyit_=D6zg=FCr?= X-Barracuda-Apparent-Source-IP: fe80::1058:3088:f9b1:1346 To: "freebsd-net@freebsd.org" Thread-Topic: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release X-ASG-Orig-Subj: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release Thread-Index: Ac0C5Fxpv2wbk7REQXGSXBWgiq7+JA== Date: Thu, 15 Mar 2012 19:49:28 +0000 Message-ID: <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F221@yuhanna.magnetdigital.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.11.161] MIME-Version: 1.0 X-Barracuda-Connect: gamma.magnetdigital.local[192.168.131.244] X-Barracuda-Start-Time: 1331841018 X-Barracuda-URL: http://10.10.140.221:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, NORMAL_HTTP_TO_IP X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.91306 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL 0.00 HTML_MESSAGE BODY: HTML included in message Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 19:50:31 -0000 Hi, Today we tried to see what happens Malformed syn packets on FreeBSD 9.0 rel= ease.. Those packets rise to CPU %100 and stucks.. listening on ix0, link-type EN10MB (Ethernet), capture size 65535 bytes 18:33:30.010215 IP vgn44-1-88-123-89-40.fbx.proxad.net > 85.xxx.xxx.90: tcp 18:33:30.010242 IP 225.74.196.88.sta.estpak.ee > 85.xxx.xxx.90: tcp 18:33:30.010269 IP Nnov-Prospekt.71.quantum.rn > 85.xxx.xxx.90: tcp 18:33:30.010296 IP host52-108-static.49-88-b.business.telecomitalia.it > 85= .xxx.xxx.90: tcp 18:33:30.010325 IP 125.Red-88-1-75.dynamicIP.rima-tde.net > 85.xxx.xxx.90: = tcp i dont know which tool generate those packets.. but as we see i dont see se= q, flag, lenth etc.. just this ouput on tcpdump... Is there any kernel feature for do NOT process malformed syn packets ?? From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 20:03:22 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 854A2106566B; Thu, 15 Mar 2012 20:03:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 524078FC0A; Thu, 15 Mar 2012 20:03:22 +0000 (UTC) Received: by dald2 with SMTP id d2so5164563dal.13 for ; Thu, 15 Mar 2012 13:03:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QyVoV1WQtaM9kC2uuKg3fB9Di4zRgQwVqvnh7L3aHlQ=; b=ivj5olMjrNUKNfjeHUM2UQ5+YSCDOTA43ZaebWzINZ4or/fOBciwJhvMlbaLb7uyxs akpX3HVXj/DqguYCHkG9wxJNmMbHh7dF72IVFX8HcEyEHRIbWiTncQUHTyLB2Bo0YQyb HVitffTAfUB3MAd1OXAUmXyUu0ordbU8XV8ijoU50j6IvAwQpI9aoY76wMBfzIHLGfCQ Kx19hi6hVx5rg1qsbTimwXKQD2YILuN9I7SCMNlmfBr81ayFsU3VViaOG6vnNcTPJd1J m6sGm5gR844I5M2t7Py/fATBOIWa2/jbOK9BLEg1s8G0jFgGzSTpsobVzAFYE3MPsy7h PF3A== MIME-Version: 1.0 Received: by 10.68.225.104 with SMTP id rj8mr7398475pbc.135.1331841802044; Thu, 15 Mar 2012 13:03:22 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Thu, 15 Mar 2012 13:03:22 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Mar 2012 13:03:22 -0700 X-Google-Sender-Auth: 39i9u6UNKJgsMigGWfd3-ZAmL8U Message-ID: From: Adrian Chadd To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Networking Mailing List , "Alexander V. Chernikov" Subject: Re: multi-FIB changes for GENERIC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 20:03:22 -0000 On 15 March 2012 12:09, Bjoern A. Zeeb wro= te: >> I forget, is it possible to not compile in multi-FIB support? > > 1) does this have anything to do with this thread? It depends if the eventual aim of this is to just have multi-FIB support enabled by default with no way to compile it out, and what the overheads are. :) > 2) yes, if you can live without your routing table, no if not. =A0Not sur= e you can spare the 240(?) bytes on 64bit if you just stay with 1 fib, but = I guess there's a lot better fish to fry. What about any extra support code that's compiled into the kernel for this feature? I'm becoming very footprint conscious now that I'm bringing up FreeBSD on modern embedded RAM/flash challenged devices. Adrian From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 20:12:28 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF7561065676 for ; Thu, 15 Mar 2012 20:12:28 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id A668B8FC08 for ; Thu, 15 Mar 2012 20:12:28 +0000 (UTC) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Received: from cswiger1.apple.com (unknown [17.209.4.71]) by asmtp028.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0M0Y0025D04RXX60@asmtp028.mac.com> for freebsd-net@freebsd.org; Thu, 15 Mar 2012 13:12:28 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498,1.0.260,0.0.0000 definitions=2012-03-15_04:2012-03-15, 2012-03-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1203150210 From: Chuck Swiger In-reply-to: <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F221@yuhanna.magnetdigital.local> Date: Thu, 15 Mar 2012 13:12:26 -0700 Content-transfer-encoding: quoted-printable Message-id: <38FA7BAB-AC2B-4515-85CF-27F77C3F4313@mac.com> References: <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F221@yuhanna.magnetdigital.local> To: =?iso-8859-1?Q?Seyit_=D6zg=FCr?= X-Mailer: Apple Mail (2.1084) Cc: "freebsd-net@freebsd.org" Subject: Re: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 20:12:28 -0000 On Mar 15, 2012, at 12:49 PM, Seyit =D6zg=FCr wrote: > Today we tried to see what happens Malformed syn packets on FreeBSD = 9.0 release.. >=20 > Those packets rise to CPU %100 and stucks.. >=20 > listening on ix0, link-type EN10MB (Ethernet), capture size 65535 = bytes > 18:33:30.010215 IP vgn44-1-88-123-89-40.fbx.proxad.net > = 85.xxx.xxx.90: tcp > 18:33:30.010242 IP 225.74.196.88.sta.estpak.ee > 85.xxx.xxx.90: tcp > 18:33:30.010269 IP Nnov-Prospekt.71.quantum.rn > 85.xxx.xxx.90: tcp > 18:33:30.010296 IP host52-108-static.49-88-b.business.telecomitalia.it = > 85.xxx.xxx.90: tcp > 18:33:30.010325 IP 125.Red-88-1-75.dynamicIP.rima-tde.net > = 85.xxx.xxx.90: tcp >=20 > i dont know which tool generate those packets.. but as we see i dont = see seq, flag, lenth etc.. just this ouput on tcpdump... >=20 > Is there any kernel feature for do NOT process malformed syn packets = ?? A firewall can block them before the system will see and try to process = them as incoming traffic. Also, running tcpdump with -X will give both hex and ASCII rendition of = the packets, which would be helpful to identify what you mean by = "malformed". Regards, --=20 -Chuck From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 20:17:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F2E3106564A for ; Thu, 15 Mar 2012 20:17:59 +0000 (UTC) (envelope-from seyit.ozgur@istanbul.net) Received: from spamtrap.istanbul.net (spamtrap.istanbul.net [85.111.12.34]) by mx1.freebsd.org (Postfix) with ESMTP id BDC058FC1B for ; Thu, 15 Mar 2012 20:17:58 +0000 (UTC) X-ASG-Debug-ID: 1331842673-0426ae630218f520001-QdxwpM Received: from GAMMA.magnetdigital.local (gamma.magnetdigital.local [192.168.131.244]) by spamtrap.istanbul.net with ESMTP id AVqPtLiWFe0r4JaR; Thu, 15 Mar 2012 22:17:53 +0200 (EET) X-Barracuda-Envelope-From: seyit.ozgur@istanbul.net X-Barracuda-RBL-Trusted-Forwarder: 192.168.131.244 Received: from YUHANNA.magnetdigital.local ([fe80::1058:3088:f9b1:1346]) by GAMMA.magnetdigital.local ([fe80::3cca:d6ef:febb:fafb%17]) with mapi id 14.01.0218.012; Thu, 15 Mar 2012 22:17:04 +0200 From: =?iso-8859-1?Q?Seyit_=D6zg=FCr?= X-Barracuda-Apparent-Source-IP: fe80::1058:3088:f9b1:1346 To: Chuck Swiger Thread-Topic: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release X-ASG-Orig-Subj: RE: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release Thread-Index: Ac0C5Fxpv2wbk7REQXGSXBWgiq7+JP//5aEAgAAhhBQ= Date: Thu, 15 Mar 2012 20:17:03 +0000 Message-ID: <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F28C@yuhanna.magnetdigital.local> References: <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F221@yuhanna.magnetdigital.local>, <38FA7BAB-AC2B-4515-85CF-27F77C3F4313@mac.com> In-Reply-To: <38FA7BAB-AC2B-4515-85CF-27F77C3F4313@mac.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.11.161] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: gamma.magnetdigital.local[192.168.131.244] X-Barracuda-Start-Time: 1331842673 X-Barracuda-URL: http://10.10.140.221:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=NORMAL_HTTP_TO_IP X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.91308 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL Cc: "freebsd-net@freebsd.org" Subject: RE: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 20:17:59 -0000 Thanks for quick reply.. but i don't use firewall. i tried to use PF.. =0A= Packer filter stucks up to 100.000 syn packets flooding(on open port).. Wit= hout packet filter it handle much more syn flooding. Like 1Mpps can handle = w/o interrupts that i see on my equiment=0A= But in this case "malformed packets" i got interrupts also input packet err= or.. cause %100 cpu..=0A= Is there any way to stop them without firewall ? Any rfc kernel feature can= check and stop those bogus packets ?=0A= Or do i something wrong on PF ? =0A= ________________________________________=0A= From: Chuck Swiger [cswiger@mac.com]=0A= Sent: Thursday, March 15, 2012 10:12 PM=0A= To: Seyit =D6zg=FCr=0A= Cc: freebsd-net@freebsd.org=0A= Subject: Re: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0= release=0A= =0A= On Mar 15, 2012, at 12:49 PM, Seyit =D6zg=FCr wrote:=0A= > Today we tried to see what happens Malformed syn packets on FreeBSD 9.0 r= elease..=0A= >=0A= > Those packets rise to CPU %100 and stucks..=0A= >=0A= > listening on ix0, link-type EN10MB (Ethernet), capture size 65535 bytes= =0A= > 18:33:30.010215 IP vgn44-1-88-123-89-40.fbx.proxad.net > 85.xxx.xxx.90: t= cp=0A= > 18:33:30.010242 IP 225.74.196.88.sta.estpak.ee > 85.xxx.xxx.90: tcp=0A= > 18:33:30.010269 IP Nnov-Prospekt.71.quantum.rn > 85.xxx.xxx.90: tcp=0A= > 18:33:30.010296 IP host52-108-static.49-88-b.business.telecomitalia.it > = 85.xxx.xxx.90: tcp=0A= > 18:33:30.010325 IP 125.Red-88-1-75.dynamicIP.rima-tde.net > 85.xxx.xxx.90= : tcp=0A= >=0A= > i dont know which tool generate those packets.. but as we see i dont see = seq, flag, lenth etc.. just this ouput on tcpdump...=0A= >=0A= > Is there any kernel feature for do NOT process malformed syn packets ??= =0A= =0A= A firewall can block them before the system will see and try to process the= m as incoming traffic.=0A= =0A= Also, running tcpdump with -X will give both hex and ASCII rendition of the= packets, which would be helpful to identify what you mean by "malformed".= =0A= =0A= Regards,=0A= --=0A= -Chuck=0A= =0A= From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 20:41:50 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33958106566B for ; Thu, 15 Mar 2012 20:41:50 +0000 (UTC) (envelope-from seyit.ozgur@istanbul.net) Received: from spamtrap1.istanbul.net (spamtrap1.istanbul.net [85.111.12.35]) by mx1.freebsd.org (Postfix) with ESMTP id 7EC898FC0C for ; Thu, 15 Mar 2012 20:41:49 +0000 (UTC) X-ASG-Debug-ID: 1331844100-0426b062bb1fab40001-QdxwpM Received: from GAMMA.magnetdigital.local (gamma.magnetdigital.local [192.168.131.244]) by spamtrap1.istanbul.net with ESMTP id HufsxjRgc8IQvTZc; Thu, 15 Mar 2012 22:41:40 +0200 (EET) X-Barracuda-Envelope-From: seyit.ozgur@istanbul.net X-Barracuda-RBL-Trusted-Forwarder: 192.168.131.244 Received: from YUHANNA.magnetdigital.local ([fe80::1058:3088:f9b1:1346]) by GAMMA.magnetdigital.local ([fe80::3cca:d6ef:febb:fafb%17]) with mapi id 14.01.0218.012; Thu, 15 Mar 2012 22:40:51 +0200 From: =?iso-8859-9?Q?Seyit_=D6zg=FCr?= X-Barracuda-Apparent-Source-IP: fe80::1058:3088:f9b1:1346 To: Chuck Swiger Thread-Topic: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release X-ASG-Orig-Subj: RE: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release Thread-Index: Ac0C5Fxpv2wbk7REQXGSXBWgiq7+JP//5aEAgAAhhBT//+NtgIAAIieX Date: Thu, 15 Mar 2012 20:40:49 +0000 Message-ID: <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F2D0@yuhanna.magnetdigital.local> References: <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F221@yuhanna.magnetdigital.local> <38FA7BAB-AC2B-4515-85CF-27F77C3F4313@mac.com> <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F28C@yuhanna.magnetdigital.local>, <13511933-562D-4887-951B-5BB01F62AB00@mac.com> In-Reply-To: <13511933-562D-4887-951B-5BB01F62AB00@mac.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.133.66] Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: gamma.magnetdigital.local[192.168.131.244] X-Barracuda-Start-Time: 1331844100 X-Barracuda-URL: http://10.10.140.223:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.91310 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "freebsd-net@freebsd.org" Subject: RE: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 20:41:50 -0000 sori my opinion but i m not a BSD guru.. i just working on BSD like 2 month= s..=0A= i know that PF or IPFW isn't build multicore arhitecture... As i know if my= server got on heavy Syn flood traffic PF or IPFW don't enough 1 core.. =0A= i also tried Syn_cookie, Syn_cookie_only and syn_cache.. if i set up syn_co= okie start input errors after 600.000 syn packets per second. But while i s= et off syn cookie protection.. my server can handle much more syn packets t= hen 600.000.. =0A= Also thats why i don't use syncookies too..=0A= If there is any statefull Firewall software on freeBSD which support multic= ore process? (you know ?). i m up to set up..=0A= =0A= i will get tcpdump again with -X param.. then i will post it again..=0A= =0A= Thanks for your comments. =0A= =0A= ________________________________________=0A= From: Chuck Swiger [cswiger@mac.com]=0A= Sent: Thursday, March 15, 2012 10:30 PM=0A= To: Seyit =D6zg=FCr=0A= Cc: freebsd-net@freebsd.org=0A= Subject: Re: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0= release=0A= =0A= On Mar 15, 2012, at 1:17 PM, Seyit =D6zg=FCr wrote:=0A= > Thanks for quick reply.. but i don't use firewall. i tried to use PF..=0A= > Packer filter stucks up to 100.000 syn packets flooding(on open port).. W= ithout packet filter it handle much more syn flooding. Like 1Mpps can handl= e w/o interrupts that i see on my equiment=0A= > But in this case "malformed packets" i got interrupts also input packet e= rror.. cause %100 cpu..=0A= > Is there any way to stop them without firewall ? Any rfc kernel feature c= an check and stop those bogus packets ?=0A= > Or do i something wrong on PF ?=0A= =0A= I prefer IPFW myself, but you probably ran out of stateful rule slots. For= a high-volume services which is expected to be Internet-reachable (ie, por= t 80 to a busy webserver), you really just don't want to have stateful rule= s-- it's too easy to DoS the firewall itself, as you noticed. In any event= , you don't need state if you are just blacklisting attack sources.=0A= =0A= You haven't really identified what you mean by "malformed", but maybe you a= re talking about a SYN flood, in which case make sure that SYN cookies and = SYN cache are enabled...=0A= =0A= Regards,=0A= --=0A= -Chuck=0A= =0A= From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 21:25:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1FF21065672; Thu, 15 Mar 2012 21:25:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C8BF08FC18; Thu, 15 Mar 2012 21:25:39 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 8157E46B49; Thu, 15 Mar 2012 17:25:39 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E0138B91A; Thu, 15 Mar 2012 17:25:38 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Thu, 15 Mar 2012 14:17:04 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <4F5C587B.6010004@gmail.com> In-Reply-To: <4F5C587B.6010004@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203151417.04507.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 15 Mar 2012 17:25:39 -0400 (EDT) Cc: Adrian Chadd , Jason Wolfe , Hooman Fazaeli Subject: Re: Intel 82574L interface wedging - em7.3.2/8.2-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 21:25:40 -0000 On Sunday, March 11, 2012 3:47:07 am Hooman Fazaeli wrote: > On 3/11/2012 5:31 AM, Adrian Chadd wrote: > > Are you able to post the patch here? > > Maybe Jack can look at what's going on and apply it to the latest > > intel ethernet driver. > > > > > > Adrian > > > > Below is the patch for if_em.c (7.2.3). It simply checks driver's > queue status when the link state changes (inactive -> active) and > start transmit task if queue(s) are not empty. > > It also contains stuff I have added to compile on 7 plus some code > for test and diagnostics. Hmm, so I have yet to test this, but I found several bugs related to transmit in em(4) and igb(4) recently just reading the code. (Mostly unnecessary scheduling of tasks for transmit.) I've included your change of restarting TX when link becomes active. I've also updated it to fix resume for em and igb to DTRT when buf_ring is used, and to not include old-style start routines at all when using multiq. It is at http://www.freebsd.org/~jhb/patches/e1000_txeof2.patch -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 21:30:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 605E6106566B for ; Thu, 15 Mar 2012 21:30:34 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by mx1.freebsd.org (Postfix) with ESMTP id 46D138FC0C for ; Thu, 15 Mar 2012 21:30:34 +0000 (UTC) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Received: from cswiger1.apple.com (unknown [17.209.4.71]) by asmtp024.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0M0Y00MZQ0Y7YX20@asmtp024.mac.com> for freebsd-net@freebsd.org; Thu, 15 Mar 2012 13:30:08 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498,1.0.260,0.0.0000 definitions=2012-03-15_04:2012-03-15, 2012-03-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1203150216 From: Chuck Swiger In-reply-to: <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F28C@yuhanna.magnetdigital.local> Date: Thu, 15 Mar 2012 13:30:07 -0700 Content-transfer-encoding: quoted-printable Message-id: <13511933-562D-4887-951B-5BB01F62AB00@mac.com> References: <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F221@yuhanna.magnetdigital.local> <38FA7BAB-AC2B-4515-85CF-27F77C3F4313@mac.com> <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F28C@yuhanna.magnetdigital.local> To: =?iso-8859-1?Q?Seyit_=D6zg=FCr?= X-Mailer: Apple Mail (2.1084) Cc: "freebsd-net@freebsd.org" Subject: Re: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 21:30:34 -0000 On Mar 15, 2012, at 1:17 PM, Seyit =D6zg=FCr wrote: > Thanks for quick reply.. but i don't use firewall. i tried to use PF..=20= > Packer filter stucks up to 100.000 syn packets flooding(on open = port).. Without packet filter it handle much more syn flooding. Like = 1Mpps can handle w/o interrupts that i see on my equiment > But in this case "malformed packets" i got interrupts also input = packet error.. cause %100 cpu.. > Is there any way to stop them without firewall ? Any rfc kernel = feature can check and stop those bogus packets ? > Or do i something wrong on PF ?=20 I prefer IPFW myself, but you probably ran out of stateful rule slots. = For a high-volume services which is expected to be Internet-reachable = (ie, port 80 to a busy webserver), you really just don't want to have = stateful rules-- it's too easy to DoS the firewall itself, as you = noticed. In any event, you don't need state if you are just = blacklisting attack sources. You haven't really identified what you mean by "malformed", but maybe = you are talking about a SYN flood, in which case make sure that SYN = cookies and SYN cache are enabled... Regards, --=20 -Chuck From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 21:43:04 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22944106566B for ; Thu, 15 Mar 2012 21:43:04 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id AFAA88FC0A for ; Thu, 15 Mar 2012 21:43:03 +0000 (UTC) Received: by wern13 with SMTP id n13so4356667wer.13 for ; Thu, 15 Mar 2012 14:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=344JzJkDzkXAVt8Ww02gtwqQCQXky0BdOjzFcK38dCk=; b=N+f5QK1tmmPMBbWFNAd+CNmgR6QlwYj2qVvwgja9ZoNQae2I0BNQeeGcA7dpVhVHJl tYBBam9oGCt8Lt3DqTp45OaOQw43LqRb5Hl+08H1NX/KaxZUS9VlWkRPOw/e2jX64NLG ke303JuJdYjKIAx0FceAL680X/NhP0x1uMlQUrq+yywyTZAUw20soKPOHv1MGVs6UqSD fo9nM9eq86T9N4W7URBQskNSKgzUPi67hNFhXqgcpZNVqDKT3VTZIfXB6msTbc/W6Rwv xjUeZ8LtVCAOjtFaCmJd9jpYdu8SBdpqOMdPOQBh5dvJEF4GdqWeEThG2IS3WBgNhHaE H6jQ== MIME-Version: 1.0 Received: by 10.216.133.234 with SMTP id q84mr81351wei.102.1331847782615; Thu, 15 Mar 2012 14:43:02 -0700 (PDT) Received: by 10.180.102.6 with HTTP; Thu, 15 Mar 2012 14:43:02 -0700 (PDT) In-Reply-To: <0F2031C9-3A37-4994-BBE7-869D9F975170@gmail.com> References: <0F2031C9-3A37-4994-BBE7-869D9F975170@gmail.com> Date: Thu, 15 Mar 2012 17:43:02 -0400 Message-ID: From: grarpamp To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: Stuck in FIN_WAIT_2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 21:43:04 -0000 > net.inet.tcp.finwait2_timeout <-- lower this > net.inet.tcp.fast_finwait2_recycle <-- set this to 1 Not present. This state has lingered for a couple years. It needs upgraded anyways, reboot coming. From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 22:57:40 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C98E106566B for ; Thu, 15 Mar 2012 22:57:40 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id CE0F78FC1F for ; Thu, 15 Mar 2012 22:57:39 +0000 (UTC) Received: by wern13 with SMTP id n13so4415055wer.13 for ; Thu, 15 Mar 2012 15:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=pbmD/YeH2FfLBsTrG5U5IB5tC9E+kXY28Svt+EohFP8=; b=XP3bf3fACs6Qj7VRPlNQMcAZUrIrDh2/aCDz4JpAmoatCiRBDrGlVh/K4UvrN53GnX od8SDfKNY/NdGvrnICMsJHhRD6NloisFEzvgXmvx+GUYOofw/S8zZoJXkKHPyJLXKc3t 0lwF1h15LWbxW5k9yhct3bPlxIe4aeojg7XpAyttuVvqH6kRejo3LjWvIjsbms+YH5iy 5qz7ImXRA72yFssfmD6bJLMDARIEqmxPU2dVGblez/mj3JDqOu7tEHorXaAlF2mvvJoF uOmIwrAwE8SxgZbPXJIjMmBEprgeCOk1bjTDqTmeYho+IVW1NYqTQ4NvhO3cJtT1o3ms fOPg== Received: by 10.216.144.138 with SMTP id n10mr209754wej.56.1331852258945; Thu, 15 Mar 2012 15:57:38 -0700 (PDT) Received: from imba-brutale.totalterror.net ([93.152.152.135]) by mx.google.com with ESMTPS id gp8sm8769155wib.5.2012.03.15.15.57.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Mar 2012 15:57:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-9 From: Nikolay Denev In-Reply-To: <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F2D0@yuhanna.magnetdigital.local> Date: Fri, 16 Mar 2012 00:57:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <14B45EAA-EC95-463B-A4C0-4CE9090FA274@gmail.com> References: <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F221@yuhanna.magnetdigital.local> <38FA7BAB-AC2B-4515-85CF-27F77C3F4313@mac.com> <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F28C@yuhanna.magnetdigital.local>, <13511933-562D-4887-951B-5BB01F62AB00@mac.com> <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F2D0@yuhanna.magnetdigital.local> To: =?iso-8859-1?Q?Seyit_=D6zg=FCr?= X-Mailer: Apple Mail (2.1257) Cc: "freebsd-net@freebsd.org" Subject: Re: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 22:57:40 -0000 On Mar 15, 2012, at 10:40 PM, Seyit =D6zg=FCr wrote: > sori my opinion but i m not a BSD guru.. i just working on BSD like 2 = months.. > i know that PF or IPFW isn't build multicore arhitecture... As i know = if my server got on heavy Syn flood traffic PF or IPFW don't enough 1 = core..=20 > i also tried Syn_cookie, Syn_cookie_only and syn_cache.. if i set up = syn_cookie start input errors after 600.000 syn packets per second. But = while i set off syn cookie protection.. my server can handle much more = syn packets then 600.000..=20 > Also thats why i don't use syncookies too.. > If there is any statefull Firewall software on freeBSD which support = multicore process? (you know ?). i m up to set up.. >=20 > i will get tcpdump again with -X param.. then i will post it again.. >=20 > Thanks for your comments.=20 >=20 > ________________________________________ > From: Chuck Swiger [cswiger@mac.com] > Sent: Thursday, March 15, 2012 10:30 PM > To: Seyit =D6zg=FCr > Cc: freebsd-net@freebsd.org > Subject: Re: Malformed syn packet cause %100 cpu and interrupts = FreeBSD 9.0 release >=20 > On Mar 15, 2012, at 1:17 PM, Seyit =D6zg=FCr wrote: >> Thanks for quick reply.. but i don't use firewall. i tried to use = PF.. >> Packer filter stucks up to 100.000 syn packets flooding(on open = port).. Without packet filter it handle much more syn flooding. Like = 1Mpps can handle w/o interrupts that i see on my equiment >> But in this case "malformed packets" i got interrupts also input = packet error.. cause %100 cpu.. >> Is there any way to stop them without firewall ? Any rfc kernel = feature can check and stop those bogus packets ? >> Or do i something wrong on PF ? >=20 > I prefer IPFW myself, but you probably ran out of stateful rule slots. = For a high-volume services which is expected to be Internet-reachable = (ie, port 80 to a busy webserver), you really just don't want to have = stateful rules-- it's too easy to DoS the firewall itself, as you = noticed. In any event, you don't need state if you are just = blacklisting attack sources. >=20 > You haven't really identified what you mean by "malformed", but maybe = you are talking about a SYN flood, in which case make sure that SYN = cookies and SYN cache are enabled... >=20 > Regards, > -- > -Chuck >=20 >=20 In my experience you will endure a lot more SYN flood traffic if you use = only syncache, and also increase the syncache sysctls. Sycookies are somewhat more expensive to calculate and they cause 100% = CPU load much sooner. I use : net.inet.tcp.syncache.hashsize=3D2048 net.inet.tcp.syncache.cachelimit=3D61440 net.inet.tcp.syncache.bucketlimit=3D30 Does this works better for you? From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 23:20:42 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E711C106566B for ; Thu, 15 Mar 2012 23:20:41 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9F53E8FC1D for ; Thu, 15 Mar 2012 23:20:41 +0000 (UTC) Received: by yhgm50 with SMTP id m50so4451674yhg.13 for ; Thu, 15 Mar 2012 16:20:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=MTA8rAd2CBjqF2WpU5SClO39I+JKU87rlrlMEYu9IzQ=; b=S9lSLn1/mXS7pr+u2uA1jBatTA9qHMoS3nea9n9GC2NXNDtKBV8Q9VtKsXgZZK7sr4 uMYClf2tjm6AqPpc0paB+2N+souZBxCU9xiYStIEgb4jUYRSZV9Ljahap0rOMHcS0T0e JxVcMFzjoTFGTCek6d9qubrIcZvsfmgfbW/8Kync7QRqVhfBpUoJ+p5bKgLbvabWO7Y9 9C0Xheh3LzrXBBokrCzCxxkDj1JgH2zX8xU7dgW5Qci9vqVuPY8bdRnrerdTFA5y0iqV AP7EBMnGJTdtfy7d2q5h6XQEyAAK9tK6KJbJhCzLhUmFhUtZOBLGj2z8SrGZ+JFoE+8R ebew== MIME-Version: 1.0 Received: by 10.60.4.105 with SMTP id j9mr545234oej.29.1331853640980; Thu, 15 Mar 2012 16:20:40 -0700 (PDT) Received: by 10.60.49.164 with HTTP; Thu, 15 Mar 2012 16:20:40 -0700 (PDT) In-Reply-To: <13511933-562D-4887-951B-5BB01F62AB00@mac.com> References: <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F221@yuhanna.magnetdigital.local> <38FA7BAB-AC2B-4515-85CF-27F77C3F4313@mac.com> <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F28C@yuhanna.magnetdigital.local> <13511933-562D-4887-951B-5BB01F62AB00@mac.com> Date: Thu, 15 Mar 2012 16:20:40 -0700 Message-ID: From: Michael Sierchio To: Chuck Swiger X-Gm-Message-State: ALoCoQmwuVsHCh+oDUwZV/6YY2V5ZsJXvGH3HTA446Fk4aUb+n56c6xqxt1ceJSKtlcXLjpxe/rM Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" , =?ISO-8859-1?Q?Seyit_=D6zg=FCr?= Subject: Re: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 23:20:42 -0000 2012/3/15 Chuck Swiger I prefer IPFW myself, but you probably ran out of stateful rule slots. For > a high-volume services which is expected to be Internet-reachable (ie, port > 80 to a busy webserver), you really just don't want to have stateful > rules-- it's too easy to DoS the firewall itself, as you noticed. In any > event, you don't need state if you are just blacklisting attack sources. > I too prefer ipfw, especially since adding blacklist IP addresses or networks to a table is extremely efficient. > You haven't really identified what you mean by "malformed", but maybe you > are talking about a SYN flood, in which case make sure that SYN cookies and > SYN cache are enabled... I'm still wondering, too. Are the packets malformed, or is this a SYN flood? - M From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 23:27:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86433106566C for ; Thu, 15 Mar 2012 23:27:31 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 16EC08FC0A for ; Thu, 15 Mar 2012 23:27:30 +0000 (UTC) Received: by wern13 with SMTP id n13so4436400wer.13 for ; Thu, 15 Mar 2012 16:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=oPQTW4wkLxnFZyv5XpGf27wIFys+FhHpjTDq4btGsQg=; b=ojTAF3HZD4Be4BL0mHwnlETyq5paL2XN1kluz6amzpqvcl0Fgv+/udx4NhGpomheVw nlMpB2wY2pvTiHMLi/A0fpgiUeg0PdoXpxNcTe6TR9JJInGa9xS+zmjW0secELi6TJ9d UltwvobkSRlHn0QQEsYJ07MROrQ20R84CkraGSyxgpTniQ4Fts2B7EzbP5iCikBujeYn e1hOsWPnTD9W1X0H7xiJQeZKIqW6kA0pwxRPmAiL7o6nntD+aPKyY7TWLRv2V2NndLxU xKwK2L10Z0reb+Px081AzLy/pdSTfq0HYKuDiwc8b2ugjGMS35VhoS9PwxgTH1aeOnQf ltIA== MIME-Version: 1.0 Received: by 10.180.78.233 with SMTP id e9mr30444449wix.0.1331854049925; Thu, 15 Mar 2012 16:27:29 -0700 (PDT) Received: by 10.223.143.3 with HTTP; Thu, 15 Mar 2012 16:27:29 -0700 (PDT) In-Reply-To: <4F61769B.2040809@rdtc.ru> References: <4F607EDF.4010505@rdtc.ru> <4F61769B.2040809@rdtc.ru> Date: Thu, 15 Mar 2012 16:27:29 -0700 Message-ID: From: Kevin Oberman To: Eugene Grosbein Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, hiren panchasara Subject: Re: Use of network_interfaces in rc.conf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 23:27:31 -0000 2012/3/14 Eugene Grosbein : > 15.03.2012 06:33, hiren panchasara =D0=C9=DB=C5=D4: > >> =9A =9A network_interfaces is basically historic rudiment >> =9A =9A used in 2.2.x FreeBSD version and alike. >> >> =9A =9A In general, you should not use it in modern version at all. >> >> >> Thanks Eugene. >> >> So, the only way to specify boottime configuration (that survives reboot= s) for an interface in rc.conf is: >> ifconfig_em0=3D"dhcp" ? > > Yes, thats what man rc.conf says. Minor correction, but the man page says 'ifconfig_em0=3D"DHCP". It may not be case sensitive, but I have always uded CAPS like the man page specifies. Also, I usually end up specifying SYNCDHCP to avoid having something else that requires network starting before the interface is configured. Of course, ifconfig_* may have any valid ifconfig argument in it, but remember the rc.conf is shell, so you must put all of the definition in a single statement. You can't do: ifconfig_em0=3D"DHCP" ifconfig_em0=3D"mediaopt half-duplex" That will not do DHCP, so hte interface will not come up. Of course, you can concatinate a second entry to the first using normal sh syntax. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 23:41:27 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 654AA1065674; Thu, 15 Mar 2012 23:41:27 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 29AA38FC1E; Thu, 15 Mar 2012 23:41:26 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q2FNf9Gq039637; Thu, 15 Mar 2012 16:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1331854870; bh=1Lz/P9BuoX+V9LYG17HrXgmXX2lKeamxMjirl6TqFpc=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=QWZ03hwLelz23Z0ERUDJ0vx4Rhavj4zPcUsv6a8xqKujIEEPHgVx23IIY48NQy3VD sW2e2RQaFDd3xRWBtgjGOBIiRapCoz83zgjlz2gznqGQRub6Wuq/LXZ50Q6c0Fb2HF zwX3dO56KEJFBXGpOAMd6tsjXhNk1CQ4olmaoKO8= From: Sean Bruno To: John Baldwin In-Reply-To: <201203151417.04507.jhb@freebsd.org> References: <4F5C587B.6010004@gmail.com> <201203151417.04507.jhb@freebsd.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 15 Mar 2012 16:41:09 -0700 Message-ID: <1331854869.3317.15.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Hooman Fazaeli , Jason Wolfe Subject: Re: Intel 82574L interface wedging - em7.3.2/8.2-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 23:41:27 -0000 > > Hmm, so I have yet to test this, but I found several bugs related to transmit > in em(4) and igb(4) recently just reading the code. (Mostly unnecessary > scheduling of tasks for transmit.) I've included your change of restarting > TX when link becomes active. I've also updated it to fix resume for em > and igb to DTRT when buf_ring is used, and to not include old-style start > routines at all when using multiq. It is at > http://www.freebsd.org/~jhb/patches/e1000_txeof2.patch > I think that some of the code being removed originated from our universe over here at Yahoo. We were seeing the driver assert IFF_OACTIVE and never clearing out. Reviewing this patch at a glance I note that the check of IFF_OACTIVE was removed, if the kernel can get us out of that state without the IFF_OACTIVE checks, then I'm good with it. Sean ref: @@ -1497,10 +1509,11 @@ if (!drbr_empty(ifp, txr->br)) em_mq_start_locked(ifp, txr, NULL); #else - em_start_locked(ifp, txr); + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) + em_start_locked(ifp, txr); #endif EM_TX_UNLOCK(txr); - if (more || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) { + if (more) { taskqueue_enqueue(adapter->tq, &adapter->que_task); return; From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 23:59:26 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2EB7106566C for ; Thu, 15 Mar 2012 23:59:26 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id A27588FC08 for ; Thu, 15 Mar 2012 23:59:26 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q2FNx8Z7048426 for ; Thu, 15 Mar 2012 16:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1331855949; bh=0/SRcz1GLSs9Zlpf+HYVyEqe925zRpqgy6Rhwc7KvQo=; h=Subject:From:Reply-To:To:Content-Type:Date:Message-ID: Mime-Version:Content-Transfer-Encoding; b=YoTKKQz3qsAksrk5Cd+V4wr/g9SklWHua0Q99wvDqA5jzWG0m3Dt9VpAhp0bUVyDc UlUg4bMKlKtve1TwL9RZESAHwhjWERW3rfUMOSZ+B7A7CYhStMjyC8O0eQ08qqn4oQ DTIoyWJsWSErZsDNIhi3aOhECGRFihv6Ec/Urs50= From: Sean Bruno To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Thu, 15 Mar 2012 16:59:08 -0700 Message-ID: <1331855948.3317.17.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: bind error when using SO_REUSEPORT(implies SO_REUSEADDR) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 23:59:27 -0000 Hey, I just found a bind bug ticket in my queue about bind. I noted that on stable/6 stable/7 stable/9 & head the referenced code "fails". It seems that this is a problem, but I have no idea if its a real problem or not. Our devs think it is. Anyway, here is a code snippet to show the failure in bind. On linux/solaris this does not fail. http://people.freebsd.org/~sbruno/bind_test.c simple compile with gcc -o test test.c and run as normal user. Sean From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 00:18:12 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F47A106564A for ; Fri, 16 Mar 2012 00:18:12 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by mx1.freebsd.org (Postfix) with ESMTP id 1D1158FC0A for ; Fri, 16 Mar 2012 00:18:11 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q2G07lpp018899 for ; Thu, 15 Mar 2012 17:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1331856467; bh=U9NMmZ/C3rnCmeOjGalJaAj3aXn/OlYMTyHxQPKObsM=; h=Subject:From:Reply-To:To:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=wnBzM8tcA77NSnj1nhnH1NUEuwsqejgeA2e/4/HVmZ5JCxXIyI226UZ550UgEW8kD hIHRRwFcNJNokQ4neXmKsXSmMy4N5NST10z87tDNG7wZ4FLf47VVJ/rG7wgKLfC2t4 +ErsMSNCxEZ9iqg22+/5qoT+xM4zCTAXMlql0A1I= From: Sean Bruno To: "freebsd-net@freebsd.org" In-Reply-To: <1331855948.3317.17.camel@powernoodle-l7.corp.yahoo.com> References: <1331855948.3317.17.camel@powernoodle-l7.corp.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 15 Mar 2012 17:07:46 -0700 Message-ID: <1331856466.3317.18.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Re: bind error when using SO_REUSEPORT(implies SO_REUSEADDR) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "sbruno@freebsd.org" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 00:18:12 -0000 On Thu, 2012-03-15 at 16:59 -0700, Sean Bruno wrote: > Hey, I just found a bind bug ticket in my queue about bind. I noted > that on stable/6 stable/7 stable/9 & head the referenced code "fails". > > It seems that this is a problem, but I have no idea if its a real > problem or not. Our devs think it is. Anyway, here is a code snippet > to show the failure in bind. On linux/solaris this does not fail. > > http://people.freebsd.org/~sbruno/bind_test.c > > simple compile with gcc -o test test.c and run as normal user. > > Sean > this is bind() not bind ... :-) Sean From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 00:50:00 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5D18106564A for ; Fri, 16 Mar 2012 00:50:00 +0000 (UTC) (envelope-from ericx@ericx.net) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 223298FC0C for ; Fri, 16 Mar 2012 00:49:59 +0000 (UTC) Received: by eekd17 with SMTP id d17so2337090eek.13 for ; Thu, 15 Mar 2012 17:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericx.net; s=selector0; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Sm3PKFyZrtTxX0k3gwauO58xkdUR6Xgc1hAzzSvu69Q=; b=OF7o3su1Bn6l/zlGIUMZNcFHqqBrS83O8IQ0I88il+sl27ZWLys1eiGOkCCTs+2/cf RUMxjj5Az3jdvWE+thYpz7N97N6QKzLFcQgw1qFKL6Lc8WZA0joswtQjbkwD2mLY7c5n qvofh6CFrTNvkAZ3o1jy8ea/4K8g6fIvgbzrc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=Sm3PKFyZrtTxX0k3gwauO58xkdUR6Xgc1hAzzSvu69Q=; b=MecKfnu2GmR4PmMrTfVZvqq2NvNuGr83vcUjtHxK89lCGDd+1YueFrvE11vDu+CbCn bDarfUSNeGgvdghWsPJYaD9kO3U/Zr8WsCRVeQnSPuU9793GtFp8GCwlZ95c6CPTNRp4 YV2dvHcPA623wA3nOkFE9nwOejqOYkFh1SqNE0H16sKIKfaJPEPkiHY2uyn3VRnPCUZ3 bqrt2cSp6bKlNVFOaeR+d2lOSqP5xL/BVdi+4QQRKsOtWdkrv9K/a4Z5JSGuH4KJv2sz HygM3JmOoNYqeowDU7vh35tjgIkLkQv7i8JPoVZBaIiej4qkDZ7MdRPhpOeKEN5ueq44 cySw== Received: by 10.213.8.197 with SMTP id i5mr39369ebi.212.1331858998904; Thu, 15 Mar 2012 17:49:58 -0700 (PDT) Received: from ?IPv6:2001:470:1f07:a3a:0:dead:d00d:ff02? ([2001:470:1f07:a3a:0:dead:d00d:ff02]) by mx.google.com with ESMTPS id y11sm12564908eem.3.2012.03.15.17.49.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Mar 2012 17:49:58 -0700 (PDT) Message-ID: <4F628E33.1060303@ericx.net> Date: Thu, 15 Mar 2012 20:49:55 -0400 From: "Eric W. Bates" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4F607EDF.4010505@rdtc.ru> <4F61769B.2040809@rdtc.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQmTr2NqISWPa76nAWftdLhXPWPxhwB9pUOtH4ChsLd2awJj4LTF7PrWttHHDp0BpI8oeUma Subject: Re: Use of network_interfaces in rc.conf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 00:50:00 -0000 On 3/15/2012 7:27 PM, Kevin Oberman wrote: > 2012/3/14 Eugene Grosbein: >> 15.03.2012 06:33, hiren panchasara РЙЫЕФ: >> >>> network_interfaces is basically historic rudiment >>> used in 2.2.x FreeBSD version and alike. >>> >>> In general, you should not use it in modern version at all. >>> >>> >>> Thanks Eugene. >>> >>> So, the only way to specify boottime configuration (that survives reboots) for an interface in rc.conf is: >>> ifconfig_em0="dhcp" ? >> >> Yes, thats what man rc.conf says. > > Minor correction, but the man page says 'ifconfig_em0="DHCP". It may > not be case sensitive, but I have always uded CAPS like the man page > specifies. Also, I usually end up specifying SYNCDHCP to avoid having > something else that requires network starting before the interface is > configured. > > Of course, ifconfig_* may have any valid ifconfig argument in it, but > remember the rc.conf is shell, so you must put all of the definition > in a single statement. You can't do: > ifconfig_em0="DHCP" > ifconfig_em0="mediaopt half-duplex" > That will not do DHCP, so hte interface will not come up. Of course, > you can concatinate a second entry to the first using normal sh > syntax. FreeBSD rc has a clever way around this. In /etc/network.subr ifscript_up(), if the file /etc/start_if.em0 is readable, it will be dot executed. So you can put as much multi-line config info in there as you would like. e.g.: ifconfig em0 mediaopt half-duplex dhclient em0 As long as network_interfaces includes em0 (and it will be automatically included by default), then start_if.em0 will be run. Conversely, stop_if.em0 will also run when rc runs at shutdown. From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 08:08:50 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B9356106564A for ; Fri, 16 Mar 2012 08:08:50 +0000 (UTC) (envelope-from seyit.ozgur@istanbul.net) Received: from spamtrap.istanbul.net (spamtrap.istanbul.net [85.111.12.34]) by mx1.freebsd.org (Postfix) with ESMTP id CBD108FC12 for ; Fri, 16 Mar 2012 08:08:48 +0000 (UTC) X-ASG-Debug-ID: 1331885324-0426ae63031a7380001-QdxwpM Received: from GAMMA.magnetdigital.local (gamma.magnetdigital.local [192.168.131.244]) by spamtrap.istanbul.net with ESMTP id upIfCKsvdY6GNf5b; Fri, 16 Mar 2012 10:08:44 +0200 (EET) X-Barracuda-Envelope-From: seyit.ozgur@istanbul.net X-Barracuda-RBL-Trusted-Forwarder: 192.168.131.244 Received: from YUHANNA.magnetdigital.local ([fe80::1058:3088:f9b1:1346]) by GAMMA.magnetdigital.local ([fe80::3cca:d6ef:febb:fafb%17]) with mapi id 14.01.0218.012; Fri, 16 Mar 2012 10:07:55 +0200 From: =?iso-8859-9?Q?Seyit_=D6zg=FCr?= X-Barracuda-Apparent-Source-IP: fe80::1058:3088:f9b1:1346 To: Michael Sierchio , Chuck Swiger Thread-Topic: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release X-ASG-Orig-Subj: RE: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release Thread-Index: Ac0C5Fxpv2wbk7REQXGSXBWgiq7+JP//5aEAgAAhhBT//+NtgIAAL6YA//9OefA= Date: Fri, 16 Mar 2012 08:07:53 +0000 Message-ID: <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F65C@yuhanna.magnetdigital.local> References: <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F221@yuhanna.magnetdigital.local> <38FA7BAB-AC2B-4515-85CF-27F77C3F4313@mac.com> <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F28C@yuhanna.magnetdigital.local> <13511933-562D-4887-951B-5BB01F62AB00@mac.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.134.34] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0157_01CD035C.A6E9D7F0" MIME-Version: 1.0 X-Barracuda-Connect: gamma.magnetdigital.local[192.168.131.244] X-Barracuda-Start-Time: 1331885324 X-Barracuda-URL: http://10.10.140.221:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.91356 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" Subject: RE: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 08:08:50 -0000 ------=_NextPart_000_0157_01CD035C.A6E9D7F0 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable it's of course Syn flood with malformed syn packets around 100.000 = packet per second with differents IP address.. around 40.000 pps starting input errors CPU cause %100 (NIC uses 8 core with different irq's x8 bus (2.5 GTs) all cpu's %100). also 60.000 pps can't handle it..=20 But while normal syn flood same equiment can handle around 1Mpps = (different IPs) .. its without any firewall software.. just tune some kernel = params.. =20 Today i will get tcpdump with -X param.. and i will share with you. =20 I think this problem about those packets process with cpu and CPU raise = UP %100 but those are bogus SYN packets..=20 =DD think if bogus syn packets don't process by CPU.. it will be OK.. =20 Regards =20 Seyit =D6zg=FCr Network Y=F6neticisi =20 From: Michael Sierchio [mailto:kudzu@tenebras.com]=20 Sent: Friday, March 16, 2012 1:21 AM To: Chuck Swiger Cc: Seyit =D6zg=FCr; freebsd-net@freebsd.org Subject: Re: Malformed syn packet cause %100 cpu and interrupts FreeBSD = 9.0 release =20 =20 2012/3/15 Chuck Swiger =20 =20 I prefer IPFW myself, but you probably ran out of stateful rule slots. = For a high-volume services which is expected to be Internet-reachable (ie, = port 80 to a busy webserver), you really just don't want to have stateful = rules-- it's too easy to DoS the firewall itself, as you noticed. In any event, = you don't need state if you are just blacklisting attack sources. =20 I too prefer ipfw, especially since adding blacklist IP addresses or networks to a table is extremely efficient. =20 You haven't really identified what you mean by "malformed", but maybe = you are talking about a SYN flood, in which case make sure that SYN cookies = and SYN cache are enabled... =20 I'm still wondering, too. Are the packets malformed, or is this a SYN flood? =20 - M=20 ------=_NextPart_000_0157_01CD035C.A6E9D7F0-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 09:16:16 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9D39106564A for ; Fri, 16 Mar 2012 09:16:16 +0000 (UTC) (envelope-from seyit.ozgur@istanbul.net) Received: from spamtrap1.istanbul.net (spamtrap1.istanbul.net [85.111.12.35]) by mx1.freebsd.org (Postfix) with ESMTP id 4DD8B8FC0A for ; Fri, 16 Mar 2012 09:16:15 +0000 (UTC) X-ASG-Debug-ID: 1331889369-0426b062bb213c30001-QdxwpM Received: from GAMMA.magnetdigital.local (gamma.magnetdigital.local [192.168.131.244]) by spamtrap1.istanbul.net with ESMTP id oAzJgnJ1h3zNdx3f; Fri, 16 Mar 2012 11:16:09 +0200 (EET) X-Barracuda-Envelope-From: seyit.ozgur@istanbul.net X-Barracuda-RBL-Trusted-Forwarder: 192.168.131.244 Received: from YUHANNA.magnetdigital.local ([fe80::1058:3088:f9b1:1346]) by GAMMA.magnetdigital.local ([fe80::3cca:d6ef:febb:fafb%17]) with mapi id 14.01.0218.012; Fri, 16 Mar 2012 11:15:19 +0200 From: =?iso-8859-9?Q?Seyit_=D6zg=FCr?= X-Barracuda-Apparent-Source-IP: fe80::1058:3088:f9b1:1346 To: Nikolay Denev Thread-Topic: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release X-ASG-Orig-Subj: RE: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release Thread-Index: AQHNAv722OgOvL9cl0SnAaRt5PzT1pZso7Hw Date: Fri, 16 Mar 2012 09:15:19 +0000 Message-ID: <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F7E4@yuhanna.magnetdigital.local> References: <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F221@yuhanna.magnetdigital.local> <38FA7BAB-AC2B-4515-85CF-27F77C3F4313@mac.com> <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F28C@yuhanna.magnetdigital.local>, <13511933-562D-4887-951B-5BB01F62AB00@mac.com> <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F2D0@yuhanna.magnetdigital.local> <14B45EAA-EC95-463B-A4C0-4CE9090FA274@gmail.com> In-Reply-To: <14B45EAA-EC95-463B-A4C0-4CE9090FA274@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.134.34] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0178_01CD0366.122EFFF0" MIME-Version: 1.0 X-Barracuda-Connect: gamma.magnetdigital.local[192.168.131.244] X-Barracuda-Start-Time: 1331889369 X-Barracuda-URL: http://10.10.140.223:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.91360 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" Subject: RE: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 09:16:17 -0000 ------=_NextPart_000_0178_01CD0366.122EFFF0 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable Here is my=20 bsd# sysctl -a | grep syncache.hashsize=20 net.inet.tcp.syncache.hashsize: 512 bsd# sysctl -a | grep syncache.cachelimit net.inet.tcp.syncache.cachelimit: 15360 bsd# sysctl -a | grep syncache.bucketlimit net.inet.tcp.syncache.bucketlimit: 30 i will incrase hashsize and cachelimit and retest again.. Seyit =D6zg=FCr Network Y=F6neticisi -----Original Message----- From: owner-freebsd-net@freebsd.org = [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Nikolay Denev Sent: Friday, March 16, 2012 12:58 AM To: Seyit =D6zg=FCr Cc: freebsd-net@freebsd.org Subject: Re: Malformed syn packet cause %100 cpu and interrupts FreeBSD = 9.0 release On Mar 15, 2012, at 10:40 PM, Seyit =D6zg=FCr wrote: > sori my opinion but i m not a BSD guru.. i just working on BSD like 2 months.. > i know that PF or IPFW isn't build multicore arhitecture... As i know = if my server got on heavy Syn flood traffic PF or IPFW don't enough 1 = core..=20 > i also tried Syn_cookie, Syn_cookie_only and syn_cache.. if i set up syn_cookie start input errors after 600.000 syn packets per second. But while i set off syn cookie protection.. my server can handle much more = syn packets then 600.000..=20 > Also thats why i don't use syncookies too.. > If there is any statefull Firewall software on freeBSD which support multicore process? (you know ?). i m up to set up.. >=20 > i will get tcpdump again with -X param.. then i will post it again.. >=20 > Thanks for your comments.=20 >=20 > ________________________________________ > From: Chuck Swiger [cswiger@mac.com] > Sent: Thursday, March 15, 2012 10:30 PM > To: Seyit =D6zg=FCr > Cc: freebsd-net@freebsd.org > Subject: Re: Malformed syn packet cause %100 cpu and interrupts=20 > FreeBSD 9.0 release >=20 > On Mar 15, 2012, at 1:17 PM, Seyit =D6zg=FCr wrote: >> Thanks for quick reply.. but i don't use firewall. i tried to use = PF.. >> Packer filter stucks up to 100.000 syn packets flooding(on open=20 >> port).. Without packet filter it handle much more syn flooding. Like 1Mpps can handle w/o interrupts that i see on my equiment But in this = case "malformed packets" i got interrupts also input packet error.. cause = %100 cpu.. >> Is there any way to stop them without firewall ? Any rfc kernel = feature can check and stop those bogus packets ? >> Or do i something wrong on PF ? >=20 > I prefer IPFW myself, but you probably ran out of stateful rule slots. For a high-volume services which is expected to be Internet-reachable = (ie, port 80 to a busy webserver), you really just don't want to have = stateful rules-- it's too easy to DoS the firewall itself, as you noticed. In = any event, you don't need state if you are just blacklisting attack sources. >=20 > You haven't really identified what you mean by "malformed", but maybe = you are talking about a SYN flood, in which case make sure that SYN cookies = and SYN cache are enabled... >=20 > Regards, > -- > -Chuck >=20 >=20 In my experience you will endure a lot more SYN flood traffic if you use only syncache, and also increase the syncache sysctls. Sycookies are somewhat more expensive to calculate and they cause 100% = CPU load much sooner. I use : net.inet.tcp.syncache.hashsize=3D2048 net.inet.tcp.syncache.cachelimit=3D61440 net.inet.tcp.syncache.bucketlimit=3D30 Does this works better for you? _______________________________________________ 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" ------=_NextPart_000_0178_01CD0366.122EFFF0-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 09:51:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63505106566C for ; Fri, 16 Mar 2012 09:51:44 +0000 (UTC) (envelope-from ml@netfence.it) Received: from cp-out7.libero.it (cp-out7.libero.it [212.52.84.107]) by mx1.freebsd.org (Postfix) with ESMTP id E4DB38FC18 for ; Fri, 16 Mar 2012 09:51:43 +0000 (UTC) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0206.4F630D28.0232,ss=1,re=0.000,fgs=0 X-libjamoibt: 1555 Received: from soth.ventu (151.41.184.118) by cp-out7.libero.it (8.5.133) id 4F5A1A6700CA7707 for freebsd-net@freebsd.org; Fri, 16 Mar 2012 10:51:36 +0100 Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.4/8.14.4) with ESMTP id q2G9pVV5061939 for ; Fri, 16 Mar 2012 10:51:31 +0100 (CET) (envelope-from ml@netfence.it) Message-ID: <4F630D23.2070509@netfence.it> Date: Fri, 16 Mar 2012 10:51:31 +0100 From: Andrea Venturoli User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; it-IT; rv:1.9.2.28) Gecko/20120314 Thunderbird/3.1.20 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.1.2.13 Subject: LAGG and CARP troubles X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 09:51:44 -0000 Hello. I'm using 7.4p6/i386 and this is (a part of) my configuration > cloned_interfaces="lagg0 vlan1 vlan2 vlan3 carp0 carp1 carp6 carp7 carp9 carp10" > ifconfig_em0="up" > ifconfig_em1="up" > ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 192.168.101.1 netmask 255.255.255.0" > ifconfig_carp0="vhid 1 pass xxxxxxx 192.168.101.10" > ifconfig_carp1="vhid 2 advskew 200 pass yyyyyyyy 192.168.101.10" lagg0 would work fine (using two cables, recovering from one disconnection, etc...). However carp0 will stay MASTER only with one cable; as soon as I connect both em interfaces, I'll get: > kernel: carp0: MASTER -> BACKUP (more frequent advertisement received) What am I doing wrong? bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 10:12:30 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C158F106564A for ; Fri, 16 Mar 2012 10:12:30 +0000 (UTC) (envelope-from sol289@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9528E8FC08 for ; Fri, 16 Mar 2012 10:12:30 +0000 (UTC) Received: by dald2 with SMTP id d2so6221001dal.13 for ; Fri, 16 Mar 2012 03:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=mm7ZtV/i9CtgO8xZdj579g1qPBBMIn0PFr+4By8Q5j0=; b=bzKxn0nIMIDvWSg+PMhvwFunltrDHjbntG8Y1g2AYUbFgW1wzdoMr39ejwDMbSWSWO zIzMFE41whh0ZCmwIdfnQ6OqRxiNgSNSl1XPjPAT4H9V3dcr8IsZD+0Abrm6jr3HIG3p NFRwlcPTgcFlOgUxO9s5IboOXaveKawWzOXVCg2iiKQuKTi9M0XqQVKcVlCcB/1QejK/ D4vwwT/M7jAuZzeJ50eReeBhM+qFi+2Z9EUACZBm/C7PBLO5DJLMt3Lhax3VvYSmnXd6 vU/AGgWemC+Xd6D+lXp70Tj4INsgZmSwXY7HJYA89/udOT1g3I6kfV2n22K4zzvZJuqQ GpOg== Received: by 10.68.221.97 with SMTP id qd1mr3915217pbc.79.1331892750135; Fri, 16 Mar 2012 03:12:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.74.137 with HTTP; Fri, 16 Mar 2012 03:12:08 -0700 (PDT) In-Reply-To: <4F630D23.2070509@netfence.it> References: <4F630D23.2070509@netfence.it> From: Alexander Lunev Date: Fri, 16 Mar 2012 14:12:08 +0400 Message-ID: To: Andrea Venturoli Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: LAGG and CARP troubles X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 10:12:30 -0000 On Fri, Mar 16, 2012 at 1:51 PM, Andrea Venturoli wrote: > I'm using 7.4p6/i386 and this is (a part of) my configuration > >> cloned_interfaces=3D"lagg0 vlan1 vlan2 vlan3 carp0 carp1 carp6 carp7 car= p9 >> carp10" >> ifconfig_em0=3D"up" >> ifconfig_em1=3D"up" >> ifconfig_lagg0=3D"laggproto lacp laggport em0 laggport em1 192.168.101.1 >> netmask 255.255.255.0" >> ifconfig_carp0=3D"vhid 1 pass xxxxxxx 192.168.101.10" >> ifconfig_carp1=3D"vhid 2 advskew 200 pass yyyyyyyy 192.168.101.10" > > > lagg0 would work fine (using two cables, recovering from one disconnectio= n, > etc...). > > However carp0 will stay MASTER only with one cable; as soon as I connect > both em interfaces, I'll get: > >> kernel: carp0: MASTER -> BACKUP (more frequent advertisement received) > > > What am I doing wrong? I think it is somehow related to my problem "carp over openvpn", maybe? Your carp interfaces behaving just like mine then. http://docs.freebsd.org/cgi/mid.cgi?CABk4_A7ii-9-cUTcrVGA2-LAuWhGm4zFVXbaw3= jwjpygeobjBQ I wonder if this problem can be solved too. -- your sweet isn't ready yet > > =C2=A0bye & Thanks > =C2=A0 =C2=A0 =C2=A0 =C2=A0av. > _______________________________________________ > 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 Mar 16 12:34:52 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1DF54106566B; Fri, 16 Mar 2012 12:34:52 +0000 (UTC) (envelope-from sanpei@sanpei.org) Received: from mail1.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id D5B728FC0C; Fri, 16 Mar 2012 12:34:51 +0000 (UTC) Received: from cherry2.sanpei.org (j069113.ppp.asahi-net.or.jp [61.213.69.113]) by mail1.asahi-net.or.jp (Postfix) with ESMTP id A1B3513686E; Fri, 16 Mar 2012 21:34:44 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by cherry2.sanpei.org (8.14.4/8.14.3) with ESMTP id q2GCYfCm005261; Fri, 16 Mar 2012 21:34:42 +0900 (JST) (envelope-from sanpei@sanpei.org) Date: Fri, 16 Mar 2012 21:34:41 +0900 (JST) Message-Id: <20120316.213441.1551145784576134237.sanpei@sanpei.org> To: flo@freebsd.org From: MIHIRA Sanpei Yoshiro In-Reply-To: <4F6097DF.8000400@freebsd.org> References: <20120304184529.GA57370@psconsult.nl> <20120314.215908.1291465837804728646.sanpei@sanpei.org> <4F6097DF.8000400@freebsd.org> X-Mailer: Mew version 6.3 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (cherry2.sanpei.org [127.0.0.1]); Fri, 16 Mar 2012 21:34:44 +0900 (JST) Cc: freebsd-net@freebsd.org, freebsd-emulation@freebsd.org, freebsd@psconsult.nl Subject: Re: if_bridge stops when running virtualbox 4.1.8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 12:34:52 -0000 Hi, Thank you for your information. Now I can use both VirtualBox and WI-FI HOSTAP mode. I refered below URL for TAP setup. http://forums.freebsd.org/showthread.php?t=7153 1. load kernel modules kldload /boot/kernel/if_bridge.ko kldload /boot/kernel/if_tap.ko 2. setup tap interface sysctl net.link.tap.user_open=1 chown root:vboxusers /dev/tap0 chmod 660 /dev/tap0 3. create tap interface and bridge interface - I use bridge1 for tap, because I use bridge0 for WI-FI HOSTAP - net0 is for my ehternet network ifconfig bridge1 create ifconfig bridge1 addm net0 ifconfig tap0 192.168.1.111 netmask 255.255.255.0 ifconfig bridge1 addm tap0 ifconfig bridge1 up 4. start virtualbox and change bridge adapter to tap0 5. enable WI-FI with src/tools/tools/net80211/scripts/setup.wpa2 / Florian >On 14.03.2012 13:59, MIHIRA Sanpei Yoshiro wrote: >> Hi, >> >> I also have this problem. >> My environment is below >> - FreeBSD-8.2-RELEASE/amd64 and FreeBSD-10-current/i386 >> - Virtualbox 4.0.14(now I'm compiling new version 4.1.8) >> - WI-FI HOSTAP mode(if_bridge) >> >> I hope to use both function(VirtualBox and if_bridge) at same. >> Please let us to know the appropriate settings. >> >>> I just noticed that when running Virtualbox 4.1.8 with a bridged >>> network >>> interface, I loose connectivity to another virtual host running in >>> qemu >>> whose network interface is bridged to my ethernet interface. After >>> stopping the Virtualbox instance, I regain connection to the virtual >>> host under qemu. Ifconfig doesn't give a clue. Has anyone seen >>> this >>> behaviour or, even better, have a solution? >> > >What i did was create another tap interface add that to the bridge >and configure VirtualBox to use the tap interface. Seems to work for >me. From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 14:04:12 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F0A910656D0; Fri, 16 Mar 2012 14:04:12 +0000 (UTC) (envelope-from sanpei@sanpei.org) Received: from mail1.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id 25C948FC16; Fri, 16 Mar 2012 14:04:11 +0000 (UTC) Received: from cherry2.sanpei.org (j069113.ppp.asahi-net.or.jp [61.213.69.113]) by mail1.asahi-net.or.jp (Postfix) with ESMTP id 855B3134B61; Fri, 16 Mar 2012 23:04:09 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by cherry2.sanpei.org (8.14.4/8.14.3) with ESMTP id q2GE45RX006431; Fri, 16 Mar 2012 23:04:05 +0900 (JST) (envelope-from sanpei@sanpei.org) Date: Fri, 16 Mar 2012 23:04:04 +0900 (JST) Message-Id: <20120316.230404.1590768603250781725.sanpei@sanpei.org> To: flo@freebsd.org From: MIHIRA Sanpei Yoshiro In-Reply-To: <4F6097DF.8000400@freebsd.org> References: <20120304184529.GA57370@psconsult.nl> <20120314.215908.1291465837804728646.sanpei@sanpei.org> <4F6097DF.8000400@freebsd.org> X-Mailer: Mew version 6.3 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (cherry2.sanpei.org [127.0.0.1]); Fri, 16 Mar 2012 23:04:09 +0900 (JST) Cc: freebsd-net@freebsd.org, freebsd-emulation@freebsd.org, freebsd@psconsult.nl Subject: Re: if_bridge stops when running virtualbox 4.1.8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 14:04:12 -0000 Hi, Thank you for your information. I mistake bridge interface settings. I use only one bridge interface(bridge0) and add ethernet, wi-fi and tap interfaces. Now I can use both VirtualBox and WI-FI HOSTAP mode. I refered below URL for TAP setup. http://forums.freebsd.org/showthread.php?t=7153 1. load kernel modules kldload /boot/kernel/if_bridge.ko kldload /boot/kernel/if_tap.ko 2. setup tap interface sysctl net.link.tap.user_open=1 chown root:vboxusers /dev/tap0 chmod 660 /dev/tap0 3. create tap interface and bridge interface - wlan0 is for WI-FI interface - net0 is for my ehternet network ifconfig bridge0 create ifconfig bridge0 addm net0 ifconfig tap0 192.168.1.111 netmask 255.255.255.0 ifconfig bridge0 addm tap0 ifconfig bridge0 addm wlan0 ifconfig bridge0 up 4. start virtualbox and change bridge adapter to tap0 5. enable WI-FI with src/tools/tools/net80211/scripts/setup.wpa2 / Florian >On 14.03.2012 13:59, MIHIRA Sanpei Yoshiro wrote: >> Hi, >> >> I also have this problem. >> My environment is below >> - FreeBSD-8.2-RELEASE/amd64 and FreeBSD-10-current/i386 >> - Virtualbox 4.0.14(now I'm compiling new version 4.1.8) >> - WI-FI HOSTAP mode(if_bridge) >> >> I hope to use both function(VirtualBox and if_bridge) at same. >> Please let us to know the appropriate settings. >> >>> I just noticed that when running Virtualbox 4.1.8 with a bridged >>> network >>> interface, I loose connectivity to another virtual host running in >>> qemu >>> whose network interface is bridged to my ethernet interface. After >>> stopping the Virtualbox instance, I regain connection to the virtual >>> host under qemu. Ifconfig doesn't give a clue. Has anyone seen >>> this >>> behaviour or, even better, have a solution? >> > >What i did was create another tap interface add that to the bridge >and configure VirtualBox to use the tap interface. Seems to work for >me. From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 15:32:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E5CF106566B; Fri, 16 Mar 2012 15:32:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6E4F48FC0A; Fri, 16 Mar 2012 15:32:59 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 245B846B2A; Fri, 16 Mar 2012 11:32:59 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 84883B94E; Fri, 16 Mar 2012 11:32:58 -0400 (EDT) From: John Baldwin To: Sean Bruno Date: Fri, 16 Mar 2012 11:29:52 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201203151417.04507.jhb@freebsd.org> <1331854869.3317.15.camel@powernoodle-l7.corp.yahoo.com> In-Reply-To: <1331854869.3317.15.camel@powernoodle-l7.corp.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201203161129.53034.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 16 Mar 2012 11:32:58 -0400 (EDT) Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Hooman Fazaeli , Jason Wolfe Subject: Re: Intel 82574L interface wedging - em7.3.2/8.2-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 15:32:59 -0000 On Thursday, March 15, 2012 7:41:09 pm Sean Bruno wrote: > > > > > Hmm, so I have yet to test this, but I found several bugs related to transmit > > in em(4) and igb(4) recently just reading the code. (Mostly unnecessary > > scheduling of tasks for transmit.) I've included your change of restarting > > TX when link becomes active. I've also updated it to fix resume for em > > and igb to DTRT when buf_ring is used, and to not include old-style start > > routines at all when using multiq. It is at > > http://www.freebsd.org/~jhb/patches/e1000_txeof2.patch > > > > I think that some of the code being removed originated from our universe > over here at Yahoo. We were seeing the driver assert IFF_OACTIVE and > never clearing out. > > Reviewing this patch at a glance I note that the check of IFF_OACTIVE > was removed, if the kernel can get us out of that state without the > IFF_OACTIVE checks, then I'm good with it. Yes, it was buggy before in that it would just sit and poll unnecessarily. The problem was that it wasn't actually kicking off retransmits in some cases (e.g. igb_msix_que and em_msix_tx). That was the real cause of it hanging on OACTIVE. The current code schedules more tasks as a much more expensive workaround and I remove all that. > Sean > > ref: > > @@ -1497,10 +1509,11 @@ > if (!drbr_empty(ifp, txr->br)) > em_mq_start_locked(ifp, txr, NULL); > #else > - em_start_locked(ifp, txr); > + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) > + em_start_locked(ifp, txr); > #endif > EM_TX_UNLOCK(txr); > - if (more || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) { > + if (more) { > taskqueue_enqueue(adapter->tq, &adapter->que_task); > return; > > > > -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 15:39:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A93381065674 for ; Fri, 16 Mar 2012 15:39:59 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 528428FC12 for ; Fri, 16 Mar 2012 15:39:58 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.4/8.14.4) with ESMTP id q2GFcwQJ091412; Fri, 16 Mar 2012 10:38:58 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.4/8.14.4/Submit) id q2GFcvCO091411; Fri, 16 Mar 2012 10:38:57 -0500 (CDT) (envelope-from brooks) Date: Fri, 16 Mar 2012 10:38:57 -0500 From: Brooks Davis To: "Eric W. Bates" Message-ID: <20120316153857.GB81115@lor.one-eyed-alien.net> References: <4F607EDF.4010505@rdtc.ru> <4F61769B.2040809@rdtc.ru> <4F628E33.1060303@ericx.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aVD9QWMuhilNxW9f" Content-Disposition: inline In-Reply-To: <4F628E33.1060303@ericx.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org Subject: Re: Use of network_interfaces in rc.conf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 15:39:59 -0000 --aVD9QWMuhilNxW9f Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 15, 2012 at 08:49:55PM -0400, Eric W. Bates wrote: > On 3/15/2012 7:27 PM, Kevin Oberman wrote: > > 2012/3/14 Eugene Grosbein: > >> 15.03.2012 06:33, hiren panchasara ?????: > >> > >>> network_interfaces is basically historic rudiment > >>> used in 2.2.x FreeBSD version and alike. > >>> > >>> In general, you should not use it in modern version at all. > >>> > >>> > >>> Thanks Eugene. > >>> > >>> So, the only way to specify boottime configuration (that survives reb= oots) for an interface in rc.conf is: > >>> ifconfig_em0=3D"dhcp" ? > >> > >> Yes, thats what man rc.conf says. > > > > Minor correction, but the man page says 'ifconfig_em0=3D"DHCP". It may > > not be case sensitive, but I have always uded CAPS like the man page > > specifies. Also, I usually end up specifying SYNCDHCP to avoid having > > something else that requires network starting before the interface is > > configured. > > > > Of course, ifconfig_* may have any valid ifconfig argument in it, but > > remember the rc.conf is shell, so you must put all of the definition > > in a single statement. You can't do: > > ifconfig_em0=3D"DHCP" > > ifconfig_em0=3D"mediaopt half-duplex" > > That will not do DHCP, so hte interface will not come up. Of course, > > you can concatinate a second entry to the first using normal sh > > syntax. >=20 > FreeBSD rc has a clever way around this. In /etc/network.subr=20 > ifscript_up(), if the file /etc/start_if.em0 is readable, it will be dot= =20 > executed. So you can put as much multi-line config info in there as you= =20 > would like. e.g.: >=20 > ifconfig em0 mediaopt half-duplex > dhclient em0 >=20 > As long as network_interfaces includes em0 (and it will be automatically= =20 > included by default), then start_if.em0 will be run. Conversely,=20 > stop_if.em0 will also run when rc runs at shutdown. On many cases you can simply use: ifconfig_em0=3D"DHCP mediaopt half-duplex" While DHCP is not an actual ifconfig option we strip it from the list (along with several other psuedo-arguments) and pass the remainder to ifconfig. Not all option will work this way, but I believe mediaopt does. -- Brooks --aVD9QWMuhilNxW9f Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFPY16RXY6L6fI4GtQRAo6yAJoDTKxzZHbNW80gpf2u6lb1LwsYuwCfQtyP Rnzw1llBrC4l4NjgUlNHTAY= =Whaq -----END PGP SIGNATURE----- --aVD9QWMuhilNxW9f-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 15:48:37 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71DDA1065674 for ; Fri, 16 Mar 2012 15:48:37 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 05DDC8FC0A for ; Fri, 16 Mar 2012 15:48:36 +0000 (UTC) Received: by eekd17 with SMTP id d17so2642418eek.13 for ; Fri, 16 Mar 2012 08:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ogYTamovyjN02coC8a7JdxlvDkcZyoHGn4m+ahtzTX0=; b=i/2zJJNUTE8RjSOYMBJImPdrXqaI6tBx4+mvnB6c80hgapE+712nPRDTdgai2XGag8 1AXjFQ3Xtty74E2iyWzXAjrAgi/NzI6Upg/QCk4aQu1RpzHxdQtxFnoJqCF42UH60elC jDNkrf3ERE2f4TdBDd7N3I0EjJVrX6WtyAbQd4gFMNsg0ynX36ZlZQiQSswUMoo5pjBe 23doCIKSjFqea40ZWMw6kehG5OdVLBBtVSnCmv2OU6l+y2kKV5QQdTkfl16e7UquZKLj UPHWqax+0qtXUjpzv7+BVSpHuq+ac2+mFHKEwW84Zft2a3cqQDaYf38+1TMBd83S5Hrj eQ/w== MIME-Version: 1.0 Received: by 10.52.93.77 with SMTP id cs13mr1652410vdb.71.1331912544371; Fri, 16 Mar 2012 08:42:24 -0700 (PDT) Received: by 10.220.195.68 with HTTP; Fri, 16 Mar 2012 08:42:24 -0700 (PDT) In-Reply-To: References: <4F630D23.2070509@netfence.it> Date: Fri, 16 Mar 2012 08:42:24 -0700 Message-ID: From: Freddie Cash To: Alexander Lunev Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: LAGG and CARP troubles X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 15:48:37 -0000 If you're adventurous, could you upgrade a test box to 10-CURRENT and try the new CARP code? From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 15:52:27 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 606501065672; Fri, 16 Mar 2012 15:52:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2902E8FC19; Fri, 16 Mar 2012 15:52:27 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so256617pbc.13 for ; Fri, 16 Mar 2012 08:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=iD5xXyKMJe/XQaxgjO+y0kW2usEf6QUJERlCCMkKj8k=; b=aqmhM1zO3pnAQPYuxFVvnkCmZ+gjkuR4JUk6vx0m0IKv67VopF5ShJuG6H59s3mf5Z I29vsxkLraBKTTV9/QjyA2ohXR8+JQGXk2u7DFl/6OUDvxBBttFP39qP7d3vykUzl0YA uiud9TJWpIfOJQPpOk7DDwU1dIcSwacWO3ToM/QPpKC28w4+F/cDTxf19krrJJAzwM9S IH19kXWice6HLqavrdvyuK0R1AwK9KZI7zudBLwzhtOp3LDRcDuufInMd2D8UJHt+6A8 tfg0ixR8GjmEKPXjzIw2aSUfQyUsJ3Ok3El46JSfNPt3cD8WkW8bTt0W2HxlnVEFyM4U BaJw== MIME-Version: 1.0 Received: by 10.68.232.2 with SMTP id tk2mr16140429pbc.68.1331913146903; Fri, 16 Mar 2012 08:52:26 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Fri, 16 Mar 2012 08:52:26 -0700 (PDT) In-Reply-To: <201203161129.53034.jhb@freebsd.org> References: <201203151417.04507.jhb@freebsd.org> <1331854869.3317.15.camel@powernoodle-l7.corp.yahoo.com> <201203161129.53034.jhb@freebsd.org> Date: Fri, 16 Mar 2012 08:52:26 -0700 X-Google-Sender-Auth: qqKfl9_6n2UVSv6ciYg7kKcZN90 Message-ID: From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" , Hooman Fazaeli , Sean Bruno , Jason Wolfe Subject: Re: Intel 82574L interface wedging - em7.3.2/8.2-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 15:52:27 -0000 Can someone please just send me some recent em/igb hardware? I'll sit down and find ways to break things and help Jack fix them. I've been knee deep in this crap with ath(4) so I'm well versed now in the art of "making your NIC and network stack not angry." Adrian From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 17:09:05 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD4F61065672 for ; Fri, 16 Mar 2012 17:09:05 +0000 (UTC) (envelope-from ded1@MyBSD.org.my) Received: from kasumi.nsc.gov.my (megatron.nsc.gov.my [115.133.176.102]) by mx1.freebsd.org (Postfix) with ESMTP id 118E98FC12 for ; Fri, 16 Mar 2012 17:09:04 +0000 (UTC) Received: from kasumi.nsc.gov.my (localhost [127.0.0.1]) by kasumi.nsc.gov.my (Postfix) with ESMTP id CAE9660ADCE for ; Sat, 17 Mar 2012 01:09:02 +0800 (MYT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mybsd.org.my; h= from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version; s=outbound; bh=cY5mgbwKS86ngOPJOrfF aTMr0bsr5BxQK+KU7I/6Z50=; b=hzKOtTAcle+ta52ROpX6YnLUB6CvsjjeeW+Z LfQ74IFgdhczGZGTRRm3u1HbwG9ulis4Vx9+gAXj51vSXT7aQbEFNHqsbBJrWmq2 Sdz+Kg39j+w1nvNjJlXklxCzesZlN8gR7Op7bKqEUyB1J45Gun5M+oHfK7t3l1gE TJ9rAm0= Received: from [192.168.2.155] (unknown [175.136.227.138]) by kasumi.nsc.gov.my (Postfix) with ESMTPA id 93ECB60ACE6 for ; Sat, 17 Mar 2012 01:09:02 +0800 (MYT) From: Ahmad Faisal Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 17 Mar 2012 01:09:21 +0800 Message-Id: <94A1A00F-B80B-47EC-829B-E84E552F2E95@MyBSD.org.my> To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1082.1) X-Mailer: Apple Mail (2.1082.1) Subject: Problem with FreeBSD working with squid and WCCPv2 Cisco 6500 series X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 17:09:05 -0000 Hi, i have some query and would like to ask anyone on squid with cisco catalyst 6500 switch with wccpv2 My setup: - squid2.7-stable9 on freebsd 7.2-RELEASE - cisco switch catalyst 6500 with ios 12.2(33)SXJ1 Internet | | --------- Cisco FWSM firewall | | | | | cisco switch catalyst 6500 (Core switch) 10.4.10.1 DMZ Segment | | | | Internal LAN (10.0.0.0/8) | | | | Squid box User (202.188.244.8) FreeBSD conf : ------------------------ ifconfig gre0 ------------- gre0: flags=d051 metric 0 mtu 1476 tunnel inet 202.188.244.8 --> 10.4.10.1 inet 202.188.244.8 --> 192.168.249.2 netmask 0xffffffff ipnat rules: ---------------- rdr bce0 0.0.0.0/0 port 80 -> 202.188.244.8 port 7788 rdr bce0 0.0.0.0/0 port 443 -> 202.188.244.8 port 7788 rdr gre0 0.0.0.0/0 port 80 -> 202.188.244.8 port 7788 rdr gre0 0.0.0.0/0 port 443 -> 202.188.244.8 port 7788 ipf rules: ------------- pass in log first on gre0 all pass out log first on gre0 all pass in log first on bce0 all pass out log first on bce0 all /etc/rc.conf ----------------- ifconfig_bce0="inet 202.188.244.8 netmask 255.255.255.0" cloned_interfaces="gre0" ifconfig_gre0="inet 202.188.244.8 192.168.249.2 netmask 255.255.255.255 link2 tunnel 202.188.244.8 10.4.10.1 up" sysctl.conf -------------- net.inet.ip.forwarding: 1 net.inet.ip.fastforwarding: 1 squid.conf ------------------- wccp2_router 10.4.10.1 wccp2_forwarding_method 1 wccp2_return_method 1 wccp2_service standard 0 wccp2_address 0.0.0.0 wccp2_assignment_method 1 Cisco 6500 output: ------------------- #show ip wccp web-cache Global WCCP information: Router information: Router Identifier: 192.168.250.2 Protocol Version: 2.0 Service Identifier: web-cache Number of Service Group Clients: 1 Number of Service Group Routers: 1 Total Packets s/w Redirected: 3799 Process: 0 CEF: 3799 Redirect access-list: 120 Total Packets Denied Redirect: 0 Total Packets Unassigned: 382 Group access-list: 20 Total Messages Denied to Group: 0 Total Authentication failures: 0 Total Bypassed Packets Received: 0 #show ip wccp web-cache detail WCCP Client information: WCCP Client ID: 202.188.244.8 Protocol Version: 2.0 State: Usable Redirection: GRE Packet Return: GRE Assignment: HASH Initial Hash Info: 00000000000000000000000000000000 00000000000000000000000000000000 Assigned Hash Info: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF Hash Allotment: 256 (100.00%) Packets s/w Redirected: 3139 Connect Time: 00:48:27 Bypassed Packets Process: 0 CEF: 0 Errors: 0 squid cache log: 2012/03/14 19:31:51| wccp2HereIam: sending to service id 0 2012/03/14 19:31:51| Sending HereIam packet size 144 2012/03/14 19:31:51| Incoming WCCPv2 I_SEE_YOU length 132. 2012/03/14 19:31:51| Complete packet received 2012/03/14 19:31:51| Incoming WCCP2_I_SEE_YOU Received ID old=1591 new=1592. 2012/03/14 19:31:51| Cleaning out cache list Cisco 6500 debug message: *Mar 14 18:53:43.291: WCCP-EVNT:wccp_update_assignment_status: enter *Mar 14 18:53:43.291: WCCP-EVNT:wccp_update_assignment_status: exit *Mar 14 18:53:43.291: WCCP-EVNT:wccp_validate_wc_assignments: enter *Mar 14 18:53:43.291: WCCP-EVNT:wccp_validate_wc_assignments: not mask assignment, exit *Mar 14 18:53:43.291: WCCP-PKT:S00: Sending I_See_You packet to 202.188.244.8 w/ rcv_id 000005F4 *Mar 14 18:53:53.291: WCCP-EVNT:wccp_update_assignment_status: enter *Mar 14 18:53:53.291: WCCP-EVNT:wccp_update_assignment_status: exit *Mar 14 18:53:53.291: WCCP-EVNT:wccp_validate_wc_assignments: enter *Mar 14 18:53:53.291: WCCP-EVNT:wccp_validate_wc_assignments: not mask assignment, exit *Mar 14 18:53:53.291: WCCP-PKT:S00: Sending I_See_You packet to 202.188.244.8 w/ rcv_id 000005F5 *Mar 14 18:54:03.295: WCCP-EVNT:wccp_update_assignment_status: enter *Mar 14 18:54:03.295: WCCP-EVNT:wccp_update_assignment_status: exit *Mar 14 18:54:03.295: WCCP-EVNT:wccp_validate_wc_assignments: enter *Mar 14 18:54:03.295: WCCP-EVNT:wccp_validate_wc_assignments: not mask assignment, exit *Mar 14 18:54:03.295: WCCP-PKT:S00: Sending I_See_You packet to 202.188.244.8 w/ rcv_id 000005F6 1. User can go to the internet - if proxy ip set in their browser 2. User cannot go to internet - if proxy ip is not set in the browser 3. squid didn't log any client access (access.log) - if they don't set in their browser 4. squid cache.log can see cisco 6500 & squid box communicate (refer above log) Appreciate your suggestion / feedback / tips. Thanks. From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 17:49:06 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A039A106564A; Fri, 16 Mar 2012 17:49:06 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forward6.mail.yandex.net (unknown [IPv6:2a02:6b8:0:202:22cf:30ff:fe6b:6ebc]) by mx1.freebsd.org (Postfix) with ESMTP id 029178FC0A; Fri, 16 Mar 2012 17:49:06 +0000 (UTC) Received: from smtp7.mail.yandex.net (smtp7.mail.yandex.net [77.88.61.55]) by forward6.mail.yandex.net (Yandex) with ESMTP id 94830112286F; Fri, 16 Mar 2012 21:49:04 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1331920144; bh=ZYs8N/wZL7BiiRHP4SaHPMyQjooKsnf8euycpw56Z5w=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=iINizmrg03kNWYRGzdIlJBRmjykVWiz+crsNrBmYZlzA5be2KO3lxIoKmYcaGUnxX 3QGeFyjyDqZ4HuSmSg86QmlFp1Z65UFLbacAzNbBUmhpeCkOlrEH4KgsN+m3CR3z6Z Uc0w1yoDDuayXirny8ZytkeJZ05PlUZHV3vQVXtM= Received: from smtp7.mail.yandex.net (localhost [127.0.0.1]) by smtp7.mail.yandex.net (Yandex) with ESMTP id 36F3E1580505; Fri, 16 Mar 2012 21:49:04 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1331920144; bh=ZYs8N/wZL7BiiRHP4SaHPMyQjooKsnf8euycpw56Z5w=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=iINizmrg03kNWYRGzdIlJBRmjykVWiz+crsNrBmYZlzA5be2KO3lxIoKmYcaGUnxX 3QGeFyjyDqZ4HuSmSg86QmlFp1Z65UFLbacAzNbBUmhpeCkOlrEH4KgsN+m3CR3z6Z Uc0w1yoDDuayXirny8ZytkeJZ05PlUZHV3vQVXtM= Received: from unknown (unknown [77.93.52.20]) by smtp7.mail.yandex.net (nwsmtp/Yandex) with ESMTP id n0Qav6Al-n3QaUWHp; Fri, 16 Mar 2012 21:49:04 +0400 Date: Fri, 16 Mar 2012 19:48:49 +0200 From: =?utf-8?B?0JrQvtC90YzQutC+0LIg0JXQstCz0LXQvdC40Lk=?= X-Mailer: The Bat! (v4.0.24) Professional Organization: =?utf-8?B?0KfQnyDQmtC+0L3RjNC60L7QsiwgRnJlZUxpbmU=?= X-Priority: 3 (Normal) Message-ID: <732484676.20120316194849@yandex.ru> To: Adrian Chadd In-Reply-To: References: <201203151417.04507.jhb@freebsd.org> <1331854869.3317.15.camel@powernoodle-l7.corp.yahoo.com> <201203161129.53034.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: "freebsd-net@freebsd.org" , Jason Wolfe , Hooman Fazaeli , John Baldwin , Sean Bruno Subject: Re[2]: Intel 82574L interface wedging - em7.3.2/8.2-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?utf-8?B?0JrQvtC90YzQutC+0LIg0JXQstCz0LXQvdC40Lk=?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 17:49:06 -0000 Здравствуйте, Adrian. Вы писали 16 марта 2012 г., 17:52:26: AC> Can someone please just send me some recent em/igb hardware? I'll sit AC> down and find ways to break things and help Jack fix them. AC> I've been knee deep in this crap with ath(4) so I'm well versed now in AC> the art of "making your NIC and network stack not angry." I can give to you root access to machine with igb hardware. will that be enough? -- С уважением, Коньков mailto:kes-kes@yandex.ru From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 18:00:35 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B60CE1065677; Fri, 16 Mar 2012 18:00:35 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 7005C8FC1E; Fri, 16 Mar 2012 18:00:35 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id q2GI0W0E013992; Fri, 16 Mar 2012 14:00:32 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4F637FBB.8030107@sentex.net> Date: Fri, 16 Mar 2012 14:00:27 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adrian Chadd References: <201203151417.04507.jhb@freebsd.org> <1331854869.3317.15.camel@powernoodle-l7.corp.yahoo.com> <201203161129.53034.jhb@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on 64.7.153.18 Cc: "freebsd-net@freebsd.org" , Jason Wolfe , Hooman Fazaeli , John Baldwin , Sean Bruno Subject: Re: Intel 82574L interface wedging - em7.3.2/8.2-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 18:00:35 -0000 On 3/16/2012 11:52 AM, Adrian Chadd wrote: > Can someone please just send me some recent em/igb hardware? I'll sit > down and find ways to break things and help Jack fix them. > > I've been knee deep in this crap with ath(4) so I'm well versed now in > the art of "making your NIC and network stack not angry." The 82574L is not that common on NICs and tends to be on server motherboards. igb is easy enough to source. ---Mike > > > > Adrian > _______________________________________________ > 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" > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 18:20:29 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF7801065673; Fri, 16 Mar 2012 18:20:29 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id D5AE78FC19; Fri, 16 Mar 2012 18:20:28 +0000 (UTC) Received: by wern13 with SMTP id n13so5517382wer.13 for ; Fri, 16 Mar 2012 11:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QnhzDbKE6cjG2jzELg6J1lr3F/uIZnUGE2aAgBh3Blo=; b=ENA6WoV6rmjas/9NW/hymbh+QJJRPMnXdixO8/+WTbYZRqVwXsTWs8bjcUu5RvNPY5 T0wM+nLM9tHEUS/LO499rl8+4Q6nGHgS9wt5M6qNDp7a8GtXO6ou5fyB3X2TIF78CMCe pQ0NZa6FhYfhY3aXKpGVh3AvYRlVp74WVWaYaJsSbxRNNIdnD/wY+AEr9bgBl5QpcUGS e3LnKWPyC7x8cmnVM485luSGm4s4jQBqHDhIvdZ6ijbXRNGxSYb9Lei1cZcfU6t6h+3M IvYvoN6AUMtFXf+25RCHnNDi0LTr0T8QAu7qv0FaXElgnPY5K3wkAqUG+Wy1oYO44WAY yMpA== MIME-Version: 1.0 Received: by 10.180.14.73 with SMTP id n9mr614507wic.16.1331922028003; Fri, 16 Mar 2012 11:20:28 -0700 (PDT) Received: by 10.180.82.168 with HTTP; Fri, 16 Mar 2012 11:20:27 -0700 (PDT) In-Reply-To: <4F637FBB.8030107@sentex.net> References: <201203151417.04507.jhb@freebsd.org> <1331854869.3317.15.camel@powernoodle-l7.corp.yahoo.com> <201203161129.53034.jhb@freebsd.org> <4F637FBB.8030107@sentex.net> Date: Fri, 16 Mar 2012 11:20:27 -0700 Message-ID: From: Jack Vogel To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Adrian Chadd , John Baldwin , Jason Wolfe , "freebsd-net@freebsd.org" , Hooman Fazaeli , Sean Bruno Subject: Re: Intel 82574L interface wedging - em7.3.2/8.2-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 18:20:29 -0000 Its looking like I will be able to provide him with some hardware. Cheers, Jack On Fri, Mar 16, 2012 at 11:00 AM, Mike Tancsa wrote: > On 3/16/2012 11:52 AM, Adrian Chadd wrote: > > Can someone please just send me some recent em/igb hardware? I'll sit > > down and find ways to break things and help Jack fix them. > > > > I've been knee deep in this crap with ath(4) so I'm well versed now in > > the art of "making your NIC and network stack not angry." > > The 82574L is not that common on NICs and tends to be on server > motherboards. igb is easy enough to source. > > ---Mike > > > > > > > > > Adrian > > _______________________________________________ > > 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" > > > > > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 20:50:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF2DB1065670 for ; Fri, 16 Mar 2012 20:50:36 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id 6EF838FC1A for ; Fri, 16 Mar 2012 20:50:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id 0A809446003; Fri, 16 Mar 2012 16:53:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lp4q9zRMfsRb; Fri, 16 Mar 2012 16:53:36 -0400 (EDT) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id 1A1F98BCEDA; Fri, 16 Mar 2012 16:53:36 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Andrew Boyer In-Reply-To: <4F3F7FDF.8060202@my.gd> Date: Fri, 16 Mar 2012 16:50:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3672F21A-B65A-4F55-8D02-D2C5FFFACE3D@averesystems.com> References: <1329376106.7683.YahooMailNeo@web162203.mail.bf1.yahoo.com> <4F3D0197.60100@my.gd> <37B92AD6-F745-4D26-A924-271476558D93@averesystems.com> <4F3F7FDF.8060202@my.gd> To: Damien Fleuriot X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, "M. V." Subject: Re: Assigning multiple IPs in the same network to an interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 20:50:36 -0000 On Feb 18, 2012, at 5:39 AM, Damien Fleuriot wrote: > On 2/16/12 3:39 PM, Andrew Boyer wrote: >>=20 >> On Feb 16, 2012, at 8:16 AM, Damien Fleuriot wrote: >>=20 >>> On 2/16/12 8:08 AM, M. V. wrote: >>>> hi everybody, >>>>=20 >>>> i have a problem with setting multiple IPs in the same network in = FreeBSD: >>>>=20 >>>> - suppose I assign two new IP addresses in the same network to eth0 = with ifconfig: >>>> #ifconfig eth0 add 192.168.10.1/24 >>>> #ifconfig eth0 add 192.168.10.2/24 >>>>=20 >>>> - everything works fine and the output of "netstat -r" is like what = it should be: >>>> #netstat -r >>>> .... >>>> 192.168.10.0 eth0 >>>> 192.168.10.1 lo0 >>>> 192.168.10.2 lo0 >>>> ... >>>>=20 >>>> - but now if I delete first IP address, connection to 192.168.10.0 = network will be gone. and in output of "netstat -r" the route to = 192.168.10.0 (via eth0) is gone: >>>> #ifconfig eth0 delete 192.168.10.1 >>>>=20 >>>> #netstat -r >>>> .... >>>>=20 >>>> 192.168.10.2 lo0 >>>> ..... >>>>=20 >>>> - am i missing something here? shouldn't the route to the network = remain in routing table (because we still have 192.168.10.2 assigned to = interface)? >>>>=20 >>>> Thanks. >>>>=20 >>>=20 >>> You shouldn't assign your secondary IP with a /24 mask, use /32. >>>=20 >>> You'll run into problems otherwise. >>>=20 >>> As a rule of thumb, your aliases =3D /32 >>>=20 >>=20 >> M.V. - >> What you are doing should work fine. There were a handful of routing = table bugs fixed in the last few months that corrected this behavior. = The last two were just merged to stable/8 yesterday. What release are = you running? =20 >>=20 >> -Andrew >>=20 >=20 > This is of interest to me. >=20 > Do these fixes allow one to use say /24 aliases instead of /32 without > running into problems ? >=20 Sorry for the long delay. I'm not aware of any restriction on how many = IPs or subnets you can install, as long as the subnets don't conflict. I haven't tried IPv6, though... -Andrew -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 22:48:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 37E2A106566C for ; Fri, 16 Mar 2012 22:48:56 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mx1.freebsd.org (Postfix) with ESMTP id C4A628FC0A for ; Fri, 16 Mar 2012 22:48:55 +0000 (UTC) Received: by wibhr17 with SMTP id hr17so1364391wib.1 for ; Fri, 16 Mar 2012 15:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CAW4IWfKhw+jsYWMtzsVoHiWVA2JAJRq03/91HzgDlU=; b=Sp0gFXRpe49AZQ5jNOgX+nCTX7XGtPSNk+S1mjbNa21f0B3vf8gtqn0ZNgR9nJIX6B Y0zQKsyYnsxLnCAWQlE0GduLvr4Gb2nJ3pB4ckSDNjZQc0MAbw4R4Aj/4/PWkrYrqGpn 9VRpN/5jqIpBmnFMi71JxqGfXAdvfCkBEmilNn23FlDZAO426/8XsQPDaliwfGsRnwDj znlDSF3A/orJS3HpCV7Y0p0h3x5ug/7DHYSBDPQgdaHMG7i3Kp4J776t6Vp8yqcp2lw+ 1EVyfBg26Yy3puFB64Nh68g5GeBSdyiXnnYoyN0lj94bJw74chJbmn0bltay265d7ZsV 0E6w== MIME-Version: 1.0 Received: by 10.180.97.41 with SMTP id dx9mr2113984wib.9.1331938129021; Fri, 16 Mar 2012 15:48:49 -0700 (PDT) Received: by 10.180.102.6 with HTTP; Fri, 16 Mar 2012 15:48:48 -0700 (PDT) Date: Fri, 16 Mar 2012 18:48:48 -0400 Message-ID: From: grarpamp To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: netmap X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 22:48:56 -0000 Hi. I read most of the netmap paper. In short, cool work :) I have one question... is this meant only for use with dedicated tap interfaces? Or will it be integrated with the mangement interface? Example... Today: fxp0 - onboard NIC, 192.168.0.10, ssh, httpd, smtp, tcpdump, etc. ixgbe0 - PCIe addon NIC, tap interface, netmap Tomorrow: ixgbe0 - all the above functions in one NIC It would seem to me that an 'emulate an interface' shim/driver could be written that would hook into netmap below and provide all the normal interface semantics above. netmap interface <--> emulation driver <--> 'net0' interface So example... /etc/rc.conf:netmap_emulate1='ixgbe0 net0' /etc/rc.conf:netmap_emulate2='em0 net1' /etc/rc.conf:netmap_emulate3='fxp1 net2' /etc/rc.conf:ifconfig_net0='inet 10.0.0.3/24' ifconfig net0 192.168.0.10/24 -alias ifconfig net0 ::1 tcpdump, httpd, sshd, ... ipfw, pf, netgraph, vlan, bridge, carp, ... and all the other various capabilities of a physical NIC, etc... Also, though perhaps not needed for line rate capture, but for making a standard interface to them... will various 10/100/1000 NICS such as fxp, em, de, bfe, etc... end up being netmap capable? From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 22:55:05 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F1E81065672 for ; Fri, 16 Mar 2012 22:55:05 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 4070F8FC17 for ; Fri, 16 Mar 2012 22:55:05 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 5F1797300A; Sat, 17 Mar 2012 00:13:37 +0100 (CET) Date: Sat, 17 Mar 2012 00:13:37 +0100 From: Luigi Rizzo To: grarpamp Message-ID: <20120316231337.GA62350@onelab2.iet.unipi.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: netmap X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 22:55:05 -0000 On Fri, Mar 16, 2012 at 06:48:48PM -0400, grarpamp wrote: > Hi. I read most of the netmap paper. In short, cool work :) > > I have one question... is this meant only for use with dedicated > tap interfaces? Or will it be integrated with the mangement interface? > > Example... > > Today: > fxp0 - onboard NIC, 192.168.0.10, ssh, httpd, smtp, tcpdump, etc. > ixgbe0 - PCIe addon NIC, tap interface, netmap > > Tomorrow: > ixgbe0 - all the above functions in one NIC > > It would seem to me that an 'emulate an interface' shim/driver > could be written that would hook into netmap below and provide > all the normal interface semantics above. yes this is the long term plan (actually, kind of works now too if the netmap-attached client then passes the packets to the host stack). The tricky question is who select which (incoming) traffic needs to go to the host, and which one should be filtered out. I have some ideas but need to figure out what is the best way to go. > netmap interface <--> emulation driver <--> 'net0' interface > > So example... > > /etc/rc.conf:netmap_emulate1='ixgbe0 net0' > /etc/rc.conf:netmap_emulate2='em0 net1' > /etc/rc.conf:netmap_emulate3='fxp1 net2' > /etc/rc.conf:ifconfig_net0='inet 10.0.0.3/24' > ifconfig net0 192.168.0.10/24 -alias > ifconfig net0 ::1 > tcpdump, httpd, sshd, ... > ipfw, pf, netgraph, vlan, bridge, carp, ... > and all the other various capabilities of a physical NIC, etc... > > Also, though perhaps not needed for line rate capture, but for > making a standard interface to them... will various 10/100/1000 > NICS such as fxp, em, de, bfe, etc... end up being netmap capable? the em family is already supported. For the 100Mbit ports there is really no point, as CPUs are fast enough already. cheers luigi > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 00:22:46 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EEEA106564A for ; Sat, 17 Mar 2012 00:22:46 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 17C8D8FC0C for ; Sat, 17 Mar 2012 00:22:45 +0000 (UTC) Received: by wern13 with SMTP id n13so5791022wer.13 for ; Fri, 16 Mar 2012 17:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=wtwEOr8qOA8q1l1xKolvLG8hSY1bUdilwp+NeCWRDCc=; b=cogZF8W2S/KzGi+Wg+gbPTNBVMOAd2Rh+ACi7hV4dxqgTDCSIP5SWEpc3+G0K9RKga J1kS10GxLdB2PnGxDqYTaOcm8U6t7iWOaZenCexoyhl70J/BcKkHuK8z76xLpIw7Wc0O tkh1TgEoFFewUgAtv4Jn2ilM/areqIusLEWL+zBdACVIxJL3flSd/EE3v4Z/EA0Uh2df N4bVn3rUesJToAeVDBQVn5hm0vIAc2mQzghYhTynYwzZ+5kvaLfZugSNeTXnwaQw0+Ld YbLCN843hjKYUXrFyvjGVFO36Y2t2+gSmRPt+HdBOBrVMmzaL8J+7WFy3+9ek5c2bDJt qZvQ== MIME-Version: 1.0 Received: by 10.216.133.234 with SMTP id q84mr2633206wei.102.1331943765186; Fri, 16 Mar 2012 17:22:45 -0700 (PDT) Received: by 10.180.102.6 with HTTP; Fri, 16 Mar 2012 17:22:45 -0700 (PDT) In-Reply-To: <20120316231337.GA62350@onelab2.iet.unipi.it> References: <20120316231337.GA62350@onelab2.iet.unipi.it> Date: Fri, 16 Mar 2012 20:22:45 -0400 Message-ID: From: grarpamp To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: netmap X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 00:22:46 -0000 > yes this is the long term plan (actually, kind of works now too > if the netmap-attached client then passes the packets to the host > stack). I would not know how to do that as a common user. Maybe like divert/natd socket in ipfw. But perhaps natd is the only example of user tool in base for that kind of thing right now. > The tricky question is who select which (incoming) traffic needs > to go to the host, and which one should be filtered out. I have > some ideas but need to figure out what is the best way to go. I guess it would need to have all the usual interface semantics... MAC, multicast, promiscuous, alias, vlan, jumbo, v4/v6, checksum, routing, bpf, statistics. I doubt userland interface for all those to the kernel exists yet, and some are only accessible by the code nearest the iron. Maybe better to let the full emulator be kernel space. And it seems there is some additional configuration, or loss of service risk, if the emulator is userland and that account gets compromised. If that is what you meant by 'who'. If the user wanted to then run divert/natd, raw, quagga, and other processing for read/write, they could as normal, just with net0 interface. Anyways, I don't know much. > the em family is already supported. For the 100Mbit ports there > is really no point, as CPUs are fast enough already. Of course, it would just be a consistency thing, /dev/netmap ed0 :) And much boring work when 1000Mbit parts is cheap standard to use now. From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 07:26:41 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 649CA1065670 for ; Sat, 17 Mar 2012 07:26:41 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 246B18FC14 for ; Sat, 17 Mar 2012 07:26:40 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 1FF5E7300A; Sat, 17 Mar 2012 08:45:20 +0100 (CET) Date: Sat, 17 Mar 2012 08:45:20 +0100 From: Luigi Rizzo To: grarpamp Message-ID: <20120317074520.GB69097@onelab2.iet.unipi.it> References: <20120316231337.GA62350@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: netmap X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 07:26:41 -0000 On Fri, Mar 16, 2012 at 08:22:45PM -0400, grarpamp wrote: > > yes this is the long term plan (actually, kind of works now too > > if the netmap-attached client then passes the packets to the host > > stack). > > I would not know how to do that as a common user. the "bridge" application in tools/tools/examples does exactly that -- it can pass all packets (bidirectionally) between the host stack and an interface in netmap mode. With little modifications it can decide to look at the packets, keep some for itself, modify them, etc. And the OS still believes the interface is there so playing with addresses, forwarding tables, etc still works as always. To come to the rest of your message: sure it would be great if netmap could at the same time do all what is available in the standard stack _and_ go much faster. But life is typically a tradeoff and this case is no different: at the moment i can only offer the option of run-time switching between the standard stack and netmap mode, where you can do some things much faster but you have a bit of inconvenience with other features (e.g. you cannot do bpf in netmap mode, although netmap itself is a much faster way of doing capture/inject). cheers luigi From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 15:18:27 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D2241065880 for ; Sat, 17 Mar 2012 15:18:27 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from hosted.mx.as41113.net (unknown [IPv6:2001:b70:201:2::22]) by mx1.freebsd.org (Postfix) with ESMTP id 2BC1A8FC08 for ; Sat, 17 Mar 2012 15:18:27 +0000 (UTC) Received: from [172.16.11.44] (unknown [91.208.177.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by hosted.mx.as41113.net (Postfix) with ESMTPSA id E79D322814 for ; Sat, 17 Mar 2012 15:18:25 +0000 (UTC) Message-ID: <4F64AB3B.9030806@rewt.org.uk> Date: Sat, 17 Mar 2012 15:18:19 +0000 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: msk/Yukon issues since 9.0-REL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 15:18:27 -0000 Hi guys, I've upgraded to 9.0-REL from RC3 (I think) and the previous workarounds I've used for msk/Yukon II problems don't seem to work anymore: rc.conf: ifconfig_msk0="inet 192.168.201.2/30 -lro -tso -vlanhwfilter -vlanhwtag" pciconf: mskc0@pci0:7:0:0: class=0x020000 card=0x81e6104d chip=0x435111ab rev=0x15 hdr=0x00 vendor = 'Marvell Technology Group Ltd.' device = '88E8036 PCI-E Fast Ethernet Controller' class = network subclass = ethernet I seem to get the usual error: msk0: watchdog timeout msk0: prefetch unit stuck? msk0: initialization failed: no memory for Rx buffers MSI(-X) is disabled but it doesn't seem to make any difference.... Is there anything I can try to either debug or "fix" it? Thanks, J From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 16:22:30 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 607BA1065670 for ; Sat, 17 Mar 2012 16:22:30 +0000 (UTC) (envelope-from oliver@FreeBSD.org) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [78.111.72.186]) by mx1.freebsd.org (Postfix) with SMTP id B42B18FC1B for ; Sat, 17 Mar 2012 16:22:29 +0000 (UTC) Received: (qmail 58909 invoked by uid 80); 17 Mar 2012 16:22:27 -0000 Received: from dsdf-4db5da51.pool.mediaWays.net (dsdf-4db5da51.pool.mediaWays.net [77.181.218.81]) by avocado.salatschuessel.net (Horde Framework) with HTTP; Sat, 17 Mar 2012 17:22:27 +0100 Date: Sat, 17 Mar 2012 17:22:27 +0100 Message-ID: <20120317172227.Horde.tDn5QKQd9PdPZLpDyq9bvcA@avocado.salatschuessel.net> From: Oliver Lehmann To: net@freebsd.org User-Agent: Internet Messaging Program (IMP) H4 (5.0.19) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Cc: Subject: invalid MAC addresses? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 16:22:30 -0000 Hi, when I update the BIOS of my new AM3+ Mainboard, The MAC address of my re0 card gets changed from c8:60:00:60:3b:c6 to ed:0b:00:00:e0:00 With this change, no communication with any other FreeBSD system is possible. When I try to ping another FreeBSD system, all I can see on the system I ping with tcpdump is: # tcpdump -i fxp0 -n -vv tcpdump: listening on fxp0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:06:50.689424 IP (tos 0x0, ttl 120, id 3004, offset 0, flags [none], proto ICMP (1), length 84) 10.111.72.186 > 10.111.72.185: ICMP echo request, id 47626, seq 0, length 64 17:06:50.689488 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.111.72.186 tell 10.111.72.185, length 28 17:06:50.689758 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.111.72.186 is-at ed:0b:00:00:e0:00, length 46 But the MAC address gets not stored in the ARP cache of the pinged system and now answer is sent back to the pinging system: # arp -n 10.111.72.186 ? (10.111.72.186) at (incomplete) on fxp0 expired [ethernet] 10.111.72.186 is the system with the changed BIOS/MAC address from where I issued a ping to 10.111.72.185 Both systems are connected together with a crossover cable. When I attach the system with the changed MAC adress to a switch, and issue dhclient command, the system which does not answered my ping before, hands out an IP adress to this system (it is my DHCP server) Then again - ping does not work to any FreeBSD system attached to this switch. Pinging a Windows system works and I can even ping my network printer attached to this switch. So I wonder what is wrong with this MAC Address that FreeBSD does not like it? :( Greetings, Oliver From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 16:45:38 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2040106564A for ; Sat, 17 Mar 2012 16:45:38 +0000 (UTC) (envelope-from oliver@FreeBSD.org) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [78.111.72.186]) by mx1.freebsd.org (Postfix) with SMTP id 2BB418FC08 for ; Sat, 17 Mar 2012 16:45:37 +0000 (UTC) Received: (qmail 59583 invoked by uid 80); 17 Mar 2012 16:45:35 -0000 Received: from dsdf-4db5da51.pool.mediaWays.net (dsdf-4db5da51.pool.mediaWays.net [77.181.218.81]) by avocado.salatschuessel.net (Horde Framework) with HTTP; Sat, 17 Mar 2012 17:45:35 +0100 Date: Sat, 17 Mar 2012 17:45:35 +0100 Message-ID: <20120317174535.Horde.ILH5KKQd9PdPZL_v0g67vcA@avocado.salatschuessel.net> From: Oliver Lehmann To: net@freebsd.org References: <20120317172227.Horde.tDn5QKQd9PdPZLpDyq9bvcA@avocado.salatschuessel.net> In-Reply-To: <20120317172227.Horde.tDn5QKQd9PdPZLpDyq9bvcA@avocado.salatschuessel.net> User-Agent: Internet Messaging Program (IMP) H4 (5.0.19) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Cc: Subject: Re: invalid MAC addresses? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 16:45:39 -0000 Oliver Lehmann wrote: > when I update the BIOS of my new AM3+ Mainboard, The > MAC address of my re0 card gets changed from > c8:60:00:60:3b:c6 to ed:0b:00:00:e0:00 With this > [...] > So I wonder what is wrong with this MAC Address that FreeBSD > does not like it? :( by the way... my dmesg is spammed with: in_arp: source hardware address is multicast From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 17:14:07 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F037106566B for ; Sat, 17 Mar 2012 17:14:07 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2048A8FC1B for ; Sat, 17 Mar 2012 17:14:06 +0000 (UTC) Received: by iahk25 with SMTP id k25so9736707iah.13 for ; Sat, 17 Mar 2012 10:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=6g0bCTX0QdkLrHucMV7PkyKm4GyL7bEMKto8lpUZSMM=; b=dLa98jOohi3DPJ3mZ4vOoSVj9Q5fiZqr3/dqx9IF0aLdT31Me4gr6DNHvVNd7V0elH +IGuJHyiu7pKNfuk4FmST2hHPAuE0mAi5hk+6y6MNRTQIRwOOLLsQ0G01NkUtw25Ou3+ My6xvhbrJcX4IGWl4EERZCbMQzvCWqO4ofeqs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=6g0bCTX0QdkLrHucMV7PkyKm4GyL7bEMKto8lpUZSMM=; b=W9OZIS4ycDQ0TfgJKIbKC76GFBF15Lq0ig0C7Aar+8fHa01XhCi0Vstg7Y+j+8xz8R pFYFy1HV3P/beOwRnTne8iArIxzVaM1UU/SWrAsED8l3NbREi4Y1kVkunY+gBNYPrkaQ ao8X1AZ5CMqXu24yyIF0o3ae0dCPQ3jArNMA4iVeE6so6UfJwo8ZGgVKEefOaptguh/F CkqyvcfZKbK3axUgfOfEffurmQi4usaYcGMgPhDt6yPrniAUzEmtyIBp7fOvd4ts+bDF HYElj3GAhxZCu1dgVEzDBTxoRtwbNaimIljKC2LPHGrWMWVTl7NKhAYZtEI1zDIPTLZY /QlQ== Received: by 10.50.203.74 with SMTP id ko10mr2336334igc.7.1332004446544; Sat, 17 Mar 2012 10:14:06 -0700 (PDT) Received: from DataIX.net ([99.112.214.41]) by mx.google.com with ESMTPS id s3sm3123822igw.17.2012.03.17.10.14.05 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 17 Mar 2012 10:14:05 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q2HHE3tR014734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Mar 2012 13:14:03 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q2HHDu9R014424; Sat, 17 Mar 2012 13:13:56 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Sat, 17 Mar 2012 13:13:56 -0400 From: Jason Hellenthal To: Oliver Lehmann Message-ID: <20120317171356.GA86699@DataIX.net> References: <20120317172227.Horde.tDn5QKQd9PdPZLpDyq9bvcA@avocado.salatschuessel.net> <20120317174535.Horde.ILH5KKQd9PdPZL_v0g67vcA@avocado.salatschuessel.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120317174535.Horde.ILH5KKQd9PdPZL_v0g67vcA@avocado.salatschuessel.net> X-Gm-Message-State: ALoCoQkHFAU6TPYqAScvEHuZfm6B7qNbYA09gREqyzFpudj+o7yUYqo2Xudzo7UQP8wn91jVL9kM Cc: net@freebsd.org Subject: Re: invalid MAC addresses? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 17:14:07 -0000 On Sat, Mar 17, 2012 at 05:45:35PM +0100, Oliver Lehmann wrote: > Oliver Lehmann wrote: > > > when I update the BIOS of my new AM3+ Mainboard, The > > MAC address of my re0 card gets changed from > > c8:60:00:60:3b:c6 to ed:0b:00:00:e0:00 With this > > [...] > > So I wonder what is wrong with this MAC Address that FreeBSD > > does not like it? :( > > by the way... my dmesg is spammed with: > > in_arp: source hardware address is multicast > Could it be that your machine is attempting a PXE boot first from the BIOS level ? or possibly from loader ? -- ;s =; From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 17:19:44 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B97C1065676 for ; Sat, 17 Mar 2012 17:19:44 +0000 (UTC) (envelope-from oliver@FreeBSD.org) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [78.111.72.186]) by mx1.freebsd.org (Postfix) with SMTP id 5465D8FC14 for ; Sat, 17 Mar 2012 17:19:43 +0000 (UTC) Received: (qmail 60502 invoked by uid 80); 17 Mar 2012 17:19:42 -0000 Received: from dsdf-4db5da51.pool.mediaWays.net (dsdf-4db5da51.pool.mediaWays.net [77.181.218.81]) by avocado.salatschuessel.net (Horde Framework) with HTTP; Sat, 17 Mar 2012 18:19:42 +0100 Date: Sat, 17 Mar 2012 18:19:42 +0100 Message-ID: <20120317181942.Horde.uee2KaQd9PdPZMeuN4P84wA@avocado.salatschuessel.net> From: Oliver Lehmann To: net@freebsd.org References: <20120317172227.Horde.tDn5QKQd9PdPZLpDyq9bvcA@avocado.salatschuessel.net> <20120317174535.Horde.ILH5KKQd9PdPZL_v0g67vcA@avocado.salatschuessel.net> In-Reply-To: <20120317174535.Horde.ILH5KKQd9PdPZL_v0g67vcA@avocado.salatschuessel.net> User-Agent: Internet Messaging Program (IMP) H4 (5.0.19) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Cc: Subject: Re: invalid MAC addresses? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 17:19:44 -0000 Mh.... bad to answer me again :( Looks like the problem was caused by sysutils/flashrom which I used to update my BIOS. When updating thourh EZ flash from ASUS, the MAC adresss stays the same between the old and the new BIOS. Seems to be, that the MAC address is set through the BIOS update process and not when flashrom is used.... So - problem solved. From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 17:23:02 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2597C1065673 for ; Sat, 17 Mar 2012 17:23:02 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id CCEBC8FC16 for ; Sat, 17 Mar 2012 17:23:01 +0000 (UTC) Received: by iahk25 with SMTP id k25so9750051iah.13 for ; Sat, 17 Mar 2012 10:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=LasljX6HnKAcsV1Q+efZFJy0FeFJ50OBplogz8GfxJk=; b=FqL6b+Xr9qyoyif+ZnQgNxWE3VI5uyTNaAv6odP1dGynMGfvoWYrE0NQDeozGcUlXh Si1mI7dWlNEb2ZFd97mrj1X5AV/RI0EhFGqyBcG3rWGhfMsdph6m0rkBseHC7xpH0rVV dW479K/8yhyWSyeAE8o7SsgZZpdy5WUAHrkeY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=LasljX6HnKAcsV1Q+efZFJy0FeFJ50OBplogz8GfxJk=; b=D9ACDomMrc1dWG5zwkHRMO53jqsHqKt6b1IKpS5+xyN+dPVT7YBIH0Sg+0BAbC84sV 9Ol8Es2+RG/0826DBht7OowN+SnU0SIalkjxdOfn8WgNESr9/nYety2/B7qW44mpqiNL TzTx4pAl3FS+FH4BQQSRYLM0xp5jUVxa8aXtwTrQE2VJwAWM+juTuGF6ixXpdjAzKYDB 6nDtwIl/+H33Dsu9nw0JTvad4KXgTu42MRdA3yHY/Efsr1M9Yd4ddnFiSRW4d727yR2N NGN4d9voTzPRTHxqJ1gnHB6gEPb7icwNf2CujdKINVP+wiaZxFOFKYplrwyUgZbhy1tM RnlQ== Received: by 10.50.185.230 with SMTP id ff6mr2166378igc.70.1332004981273; Sat, 17 Mar 2012 10:23:01 -0700 (PDT) Received: from DataIX.net ([99.112.214.41]) by mx.google.com with ESMTPS id b11sm3171077igq.7.2012.03.17.10.23.00 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 17 Mar 2012 10:23:00 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q2HHMw4W093404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Mar 2012 13:22:58 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q2HHMrxM092505; Sat, 17 Mar 2012 13:22:53 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Sat, 17 Mar 2012 13:22:53 -0400 From: Jason Hellenthal To: Oliver Lehmann Message-ID: <20120317172253.GB86699@DataIX.net> References: <20120317172227.Horde.tDn5QKQd9PdPZLpDyq9bvcA@avocado.salatschuessel.net> <20120317174535.Horde.ILH5KKQd9PdPZL_v0g67vcA@avocado.salatschuessel.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120317174535.Horde.ILH5KKQd9PdPZL_v0g67vcA@avocado.salatschuessel.net> X-Gm-Message-State: ALoCoQkY0EJxk2GqZT2h6cS79YGthmVuWaBCOBYLUUKTuO/z6XB3XihXAux9iFPbNiIIY16W9KLa Cc: net@freebsd.org Subject: Re: invalid MAC addresses? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 17:23:02 -0000 On Sat, Mar 17, 2012 at 05:45:35PM +0100, Oliver Lehmann wrote: > Oliver Lehmann wrote: > > > when I update the BIOS of my new AM3+ Mainboard, The > > MAC address of my re0 card gets changed from > > c8:60:00:60:3b:c6 to ed:0b:00:00:e0:00 With this > > [...] > > So I wonder what is wrong with this MAC Address that FreeBSD > > does not like it? :( > > by the way... my dmesg is spammed with: > > in_arp: source hardware address is multicast > I take my last reply back. It appears after some googling that MAC address "ed:0b:00:00:e0:00" there are problems all over the place with that BIOS update you applied. Only answer I see at first glance is reverting to the previous BIOS revision. -- ;s =; From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 17:25:26 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1EF17106566B for ; Sat, 17 Mar 2012 17:25:26 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id C82348FC18 for ; Sat, 17 Mar 2012 17:25:25 +0000 (UTC) Received: by iahk25 with SMTP id k25so9753302iah.13 for ; Sat, 17 Mar 2012 10:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=wmkNL+xJHetSBLzEg+y8E10o047PDhz5Qel7jppUad4=; b=S4wgJ6ZCUvafXlABeIBk+Lw2cYsNTaQWFJZ5OGIlmXlqrXcnZJ0HnVJ8+RZbXrDEvg JcSqNTH0glWZ5psWtHTpcdZzKdi31P3Fe+C6gColc42k+ktf2H5M4VX7PYQR3VoOhLRl VcZymgNYOraL4G74NYkoY6sdPHi1OXPEbwNt8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=wmkNL+xJHetSBLzEg+y8E10o047PDhz5Qel7jppUad4=; b=FBew4ekUNdOEp10SX86+qV88I9OCgXqtxw7Hi9tfYBGkAbdy0t7QnTwfGOwCBnRNLh xsZIcsTUxKbKteU0NBo7ZKc7Iu7pz51cm/0y0qWGRi7r/5Yj81TLiDTkJUa7PgD4yEiN 8itY8CzvXt9YcsHtx/bEv9TUUGHmqdIz9FxDTOLAx9B3WgtNJJZFOV7Fz5jLB/0RBDk8 HdzKdCWKmfw6I5gidLZOPqf5acnvDg8w78HAkiYigyFBIp60nygEQGk9ivyVShVU3KBd mfFCiw5gJSWERzNzTlvlBVnVb4eycjBh5PB8awNoN2ngcXB1sx9SAEY229fegVMV9qmR YWMw== Received: by 10.50.184.200 with SMTP id ew8mr2397932igc.1.1332005125458; Sat, 17 Mar 2012 10:25:25 -0700 (PDT) Received: from DataIX.net ([99.112.214.41]) by mx.google.com with ESMTPS id zv10sm2186138igb.13.2012.03.17.10.25.21 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 17 Mar 2012 10:25:25 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q2HHPGUk069021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Mar 2012 13:25:16 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q2HHPBKC068206; Sat, 17 Mar 2012 13:25:11 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Sat, 17 Mar 2012 13:25:11 -0400 From: Jason Hellenthal To: Oliver Lehmann Message-ID: <20120317172511.GC86699@DataIX.net> References: <20120317172227.Horde.tDn5QKQd9PdPZLpDyq9bvcA@avocado.salatschuessel.net> <20120317174535.Horde.ILH5KKQd9PdPZL_v0g67vcA@avocado.salatschuessel.net> <20120317172253.GB86699@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120317172253.GB86699@DataIX.net> X-Gm-Message-State: ALoCoQkNHXgT3xJh6xvfBUwlecONdHXXo2hpFpGjGL6H5gpm8ZAR7Ds2JfMjCQ9cPAG0hYAqgTbE Cc: net@freebsd.org Subject: Re: invalid MAC addresses? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 17:25:26 -0000 Geeeeeezus I am bad today... http://forums.gentoo.org/viewtopic-p-6721163.html On Sat, Mar 17, 2012 at 01:22:53PM -0400, Jason Hellenthal wrote: > > > On Sat, Mar 17, 2012 at 05:45:35PM +0100, Oliver Lehmann wrote: > > Oliver Lehmann wrote: > > > > > when I update the BIOS of my new AM3+ Mainboard, The > > > MAC address of my re0 card gets changed from > > > c8:60:00:60:3b:c6 to ed:0b:00:00:e0:00 With this > > > [...] > > > So I wonder what is wrong with this MAC Address that FreeBSD > > > does not like it? :( > > > > by the way... my dmesg is spammed with: > > > > in_arp: source hardware address is multicast > > > > I take my last reply back. It appears after some googling that MAC > address "ed:0b:00:00:e0:00" there are problems all over the place with > that BIOS update you applied. Only answer I see at first glance is > reverting to the previous BIOS revision. > > -- > ;s =; -- ;s =; From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 18:00:27 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 340BD106564A for ; Sat, 17 Mar 2012 18:00:27 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay1-bcrtfl2.verio.net (relay1-bcrtfl2.verio.net [131.103.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id C4B7E8FC12 for ; Sat, 17 Mar 2012 18:00:26 +0000 (UTC) Received: from iad-wprd-xchw01.corp.verio.net (iad-wprd-xchw01.corp.verio.net [198.87.7.164]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id C1E6FB038115 for ; Sat, 17 Mar 2012 13:38:14 -0400 (EDT) Thread-index: Ac0EZLrhkP8b6hb+QEmEKQ0f4a4DbA== Received: from hometx-733b1p1.corp.verio.net ([10.144.2.53]) by iad-wprd-xchw01.corp.verio.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Mar 2012 13:38:13 -0400 Received: by hometx-733b1p1.corp.verio.net (sSMTP sendmail emulation); Sat, 17 Mar 2012 12:38:12 -0500 Date: Sat, 17 Mar 2012 12:38:12 -0500 From: "David DeSimone" To: Message-ID: <20120317173811.GI6640@verio.net> Content-Transfer-Encoding: 7bit Mail-Followup-To: freebsd-net@freebsd.org References: <20120317172227.Horde.tDn5QKQd9PdPZLpDyq9bvcA@avocado.salatschuessel.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-class: urn:content-classes:message In-Reply-To: <20120317172227.Horde.tDn5QKQd9PdPZLpDyq9bvcA@avocado.salatschuessel.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Importance: normal Priority: normal Precedence: bulk User-Agent: Mutt/1.5.20 (2009-12-10) X-OriginalArrivalTime: 17 Mar 2012 17:38:13.0158 (UTC) FILETIME=[BA3F8C60:01CD0464] Subject: Re: invalid MAC addresses? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 18:00:27 -0000 Oliver Lehmann wrote: > > when I update the BIOS of my new AM3+ Mainboard, The MAC address of > my re0 card gets changed from c8:60:00:60:3b:c6 to ed:0b:00:00:e0:00 > With this change, no communication with any other FreeBSD system is > possible. The mac address ed:0b:00:00:e0:00 is a multicast mac (first octet has bit 1 set), which means it is not suitable for use with a unicast IP. Other systems when they see your ARP reply with a multicast mac, are going to treat this as an error, and ignore your ARP. You could work around the problem by forcing the mac to something else, (such as 22:44:66:11:22:33) and then other systems will believe that the mac is acceptable for unicast. However, it's clear that your NIC's eeprom has been programmed with an incorrect mac setting, which it sounds like you are already trying to fix. -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 23:28:30 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8A8A106564A; Sat, 17 Mar 2012 23:28:30 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8C3FA8FC0C; Sat, 17 Mar 2012 23:28:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2HNSUxu076193; Sat, 17 Mar 2012 23:28:30 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2HNSUnc076189; Sat, 17 Mar 2012 23:28:30 GMT (envelope-from gavin) Date: Sat, 17 Mar 2012 23:28:30 GMT Message-Id: <201203172328.q2HNSUnc076189@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/165963: [panic] [ipf] ipfilter/nat NULL pointer deference X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2012 23:28:30 -0000 Old Synopsis: reboot system New Synopsis: [panic] [ipf] ipfilter/nat NULL pointer deference Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sat Mar 17 17:35:44 UTC 2012 Responsible-Changed-Why: Over to maintainers http://www.freebsd.org/cgi/query-pr.cgi?pr=165963