From owner-freebsd-net@FreeBSD.ORG Sun Oct 30 05:33:48 2011 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 D2A47106566C for ; Sun, 30 Oct 2011 05:33:48 +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 ABE378FC08 for ; Sun, 30 Oct 2011 05:33:48 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p9U5XdQb083230 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 29 Oct 2011 22:33:47 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4EACE1AF.7070002@freebsd.org> Date: Sat, 29 Oct 2011 22:33:35 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: "nyoman.bogi@gmail.com" References: <4EAB3E0C.3020203@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: multiple ISP 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, 30 Oct 2011 05:33:48 -0000 On 10/29/11 5:27 AM, nyoman.bogi@gmail.com wrote: > thanks Julian, > but I think fwd in ipfw will use round robin mechanism > instead of load balancing, which I prefer. > or perhaps my knowledge about fwd is a little bit old > maybe fwd can do the load balancing? the problem is not load balancing the outgoing traffic, but the incoming traffic. > > > > On Sat, Oct 29, 2011 at 6:43 AM, Julian Elischer > wrote: > > On 10/28/11 7:22 AM, nyoman.bogi@gmail.com > wrote: > > dear all, > > I need to set up a router (using FreeBSD) > that connect to the Internet > to accomodate multiple ISP, > so users can be load balanced through > those several ISP lines. > > how can I do that? > > > Is it ok for you to NAT the connecitons? You pretty much have to > unless > you can convince your ISPs > to call you a peer (unlikely). > > Basically NAT both outgoing interfaces (see descriptions elsewhere > on how to run natd on two interfaces), and then use the setfib > rule in ipfw to select which routing table to use for each session > and then set up the tables to use different outgoing interfaces. > > you could also use the 'fwd' ipfw rule instead of the setfib rule. > > > thanks in advance > > ------------------------------- > Bogi Aditya > Sisfo - IMTelkom > http://bogi.blog.imtelkom.ac.id > _______________________________________________ > 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 > " > > > > > > -- > ------------------------------- > Bogi Aditya > Sisfo - IMTelkom > http://bogi.blog.imtelkom.ac.id > From owner-freebsd-net@FreeBSD.ORG Sun Oct 30 08:10:13 2011 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 AEBA0106566B for ; Sun, 30 Oct 2011 08:10:13 +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 814418FC0A for ; Sun, 30 Oct 2011 08:10:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9U8ADXP010762 for ; Sun, 30 Oct 2011 08:10:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9U8ADgu010761; Sun, 30 Oct 2011 08:10:13 GMT (envelope-from gnats) Date: Sun, 30 Oct 2011 08:10:13 GMT Message-Id: <201110300810.p9U8ADgu010761@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Hooman Fazaeli Cc: Subject: Re: kern/162028: [ixgbe] [patch] misplaced #endif in ixgbe.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Hooman Fazaeli List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 08:10:13 -0000 The following reply was made to PR kern/162028; it has been noted by GNATS. From: Hooman Fazaeli To: Sergey Kandaurov Cc: bug-followup@FreeBSD.org Subject: Re: kern/162028: [ixgbe] [patch] misplaced #endif in ixgbe.c Date: Sun, 30 Oct 2011 11:03:44 +0330 On 10/29/2011 4:28 PM, Sergey Kandaurov wrote: > I have a more complete patch. Can you test it please? > > Index: sys/dev/ixgbe/ixgbe.c > =================================================================== > --- sys/dev/ixgbe/ixgbe.c (revision 226068) > +++ sys/dev/ixgbe/ixgbe.c (working copy) > @@ -867,16 +867,15 @@ static int > ixgbe_ioctl(struct ifnet * ifp, u_long command, caddr_t data) > { > struct adapter *adapter = ifp->if_softc; > - struct ifreq *ifr = (struct ifreq *) data; > + struct ifreq *ifr = (struct ifreq *)data; > #if defined(INET) || defined(INET6) > - struct ifaddr *ifa = (struct ifaddr *)data; > - bool avoid_reset = FALSE; > + struct ifaddr *ifa = (struct ifaddr *)data; > #endif > - int error = 0; > + bool avoid_reset = FALSE; > + int error = 0; > > switch (command) { > - > - case SIOCSIFADDR: > + case SIOCSIFADDR: > #ifdef INET > if (ifa->ifa_addr->sa_family == AF_INET) > avoid_reset = TRUE; > @@ -885,7 +884,6 @@ ixgbe_ioctl(struct ifnet * ifp, u_long command, ca > if (ifa->ifa_addr->sa_family == AF_INET6) > avoid_reset = TRUE; > #endif > -#if defined(INET) || defined(INET6) > /* > ** Calling init results in link renegotiation, > ** so we avoid doing it when possible. > @@ -894,12 +892,13 @@ ixgbe_ioctl(struct ifnet * ifp, u_long command, ca > ifp->if_flags |= IFF_UP; > if (!(ifp->if_drv_flags& IFF_DRV_RUNNING)) > ixgbe_init(adapter); > +#ifdef INET > if (!(ifp->if_flags& IFF_NOARP)) > arp_ifinit(ifp, ifa); > +#endif > } else > error = ether_ioctl(ifp, command, data); > break; > -#endif > case SIOCSIFMTU: > IOCTL_DEBUGOUT("ioctl: SIOCSIFMTU (Set Interface MTU)"); > if (ifr->ifr_mtu> IXGBE_MAX_FRAME_SIZE - ETHER_HDR_LEN) { > > sure. I am very busy right now. Will test as soon as I can. From owner-freebsd-net@FreeBSD.ORG Sun Oct 30 08:57:30 2011 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 0BA92106564A for ; Sun, 30 Oct 2011 08:57:30 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 81B288FC13 for ; Sun, 30 Oct 2011 08:57:29 +0000 (UTC) Received: by bkbzs2 with SMTP id zs2so2383454bkb.13 for ; Sun, 30 Oct 2011 01:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=P0rRiNdx/2uRzMNd3GbJP1y1WrysrtSjb7ZFsA/pg3I=; b=p5JlthD1bxSM/7a743mxxIbXi0JsIb3AOEe7MKIQLGRC/w8w8WgU6W3EicTl4TodLq AgJycs2q0FZcMDOfFQyYslu38kqIt80q/RmYKIgh7MULklGMKn6qYjyStQ/tz6hAYXaj EXkySy9pPU6zmlEteaXzzCqwL6gGHFVNs6biQ= Received: by 10.204.38.16 with SMTP id z16mr7095799bkd.66.1319965048102; Sun, 30 Oct 2011 01:57:28 -0700 (PDT) Received: from [127.0.0.1] ([84.241.57.181]) by mx.google.com with ESMTPS id r12sm13113130bkw.5.2011.10.30.01.57.23 (version=SSLv3 cipher=OTHER); Sun, 30 Oct 2011 01:57:27 -0700 (PDT) Message-ID: <4EAD116A.8090006@gmail.com> Date: Sun, 30 Oct 2011 12:27:14 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Emil Muratov References: <4E8F157A.40702@sentex.net> <4E8F51D4.1060509@sentex.net> <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> In-Reply-To: <4EA959EE.2070806@hotplug.ru> Content-Type: multipart/mixed; boundary="------------050508060206020700010506" Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Jack Vogel , Jason Wolfe Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 30 Oct 2011 08:57:30 -0000 This is a multi-part message in MIME format. --------------050508060206020700010506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I finally managed to re-produce an affect similar to Jason's case. It may not be the exact same issue, but it is a serious problem and must be addressed. 1. Push out packet on em/igb with high rate. 2. Disconnect cable and wait for a few seconds. "netstat -ind" shows that Drops are increasing. 3. Re-connect the cable. Both sides of like re-negotiate and the links comes up. 4. But ..., no packets is ever transmitted again and Drops still increasing! This is because em/lem/igb and some other interfaces (i.e., bce) have a check at the very beginning of their _start function which checks link status and immediately returns if it is inactive. This behavior causes if_snd to fills up in step 2 and when this happens, IFQ_HANDOFF never calls if_start again, even when the link becomes active again. A cable unplug is not necessary to trigger the issue. Any temporary link loss (e.i., during re-negotiation) can potentially lead to aforementioned problem. IMHO, this is not a driver issue and the real fix would be to change IFQ_HANDOFF to call if_start when the queue is full. Jason, If you are interested, I can prepare a patch for you to address this issue in if_em and see if it helps. --------------050508060206020700010506 Content-Type: text/plain; name="if_em.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="if_em.c.patch" --- if_em.c.orig 2011-10-27 21:09:33.000000000 +0330 +++ if_em.c 2011-10-27 21:46:18.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 *********************************************************************/ @@ -399,6 +407,12 @@ /* Global used in WOL setup with multiport cards */ static int global_quad_port_a = 0; +#ifndef DISABLE_FIXUPS +static int em_rx_hang_fixup = 0; +SYSCTL_INT(_hw_em, OID_AUTO, rx_hang_fixup, CTLFLAG_RW, &em_rx_hang_fixup, 0, + "Enable/disable r1.69 RX hang fixup code"); +#endif + /********************************************************************* * Device identification routine * @@ -864,7 +878,11 @@ int err = 0, enq = 0; if ((ifp->if_drv_flags & (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) != +#ifdef DISABLE_FIXUPS IFF_DRV_RUNNING || adapter->link_active == 0) { +#else + IFF_DRV_RUNNING) { +#endif if (m != NULL) err = drbr_enqueue(ifp, txr->br, m); return (err); @@ -963,8 +981,10 @@ IFF_DRV_RUNNING) return; +#ifdef DISABLE_FIXUPS if (!adapter->link_active) return; +#endif while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { /* Call cleanup if number of TX descriptors low */ @@ -1414,7 +1434,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 +1450,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 +1480,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 */ @@ -2213,6 +2244,16 @@ e1000_get_laa_state_82571(&adapter->hw)) e1000_rar_set(&adapter->hw, adapter->hw.mac.addr, 0); +#ifndef DISABLE_FIXUPS + if (em_rx_hang_fixup) { + /* trigger tq to refill rx ring queue if it is empty */ + for (int i = 0; i < adapter->num_queues; i++, rxr++) { + if (rxr->next_to_check == rxr->next_to_refresh) { + taskqueue_enqueue(rxr->tq, &rxr->rx_task); + } + } + } +#endif /* Mask to use in the irq trigger */ if (adapter->msix_mem) trigger = rxr->ims; /* RX for 82574 */ @@ -3766,7 +3807,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 */ @@ -5553,4 +5594,8 @@ 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 } --------------050508060206020700010506-- From owner-freebsd-net@FreeBSD.ORG Sun Oct 30 14:33:32 2011 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 1AC7D106566B for ; Sun, 30 Oct 2011 14:33:32 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9D3F08FC15 for ; Sun, 30 Oct 2011 14:33:31 +0000 (UTC) Received: by wyh11 with SMTP id 11so1065334wyh.13 for ; Sun, 30 Oct 2011 07:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ftQy1WuwRrQXsrhk//yCMoL0J0+bQMD/kS8WunBOvr8=; b=INjuGD5EPo+ACOPEq8mKcHbcnVnrpVVFqVPWC5sE5Encm2hRo1v9m87eTATzgoTp1y 9LIF1igHEVqIf+Etq6OxJMr4qaYzLJ4txNR7BKsTP1lLucSYOE2iACdTv2iDQB2IZRAu x/Dha8cUeQAaTxKE02I8y+WpGJKMsHPeFq20A= MIME-Version: 1.0 Received: by 10.227.60.3 with SMTP id n3mr13357029wbh.25.1319985210494; Sun, 30 Oct 2011 07:33:30 -0700 (PDT) Received: by 10.180.8.34 with HTTP; Sun, 30 Oct 2011 07:33:30 -0700 (PDT) In-Reply-To: <4EAD116A.8090006@gmail.com> References: <4E8F157A.40702@sentex.net> <4E8F51D4.1060509@sentex.net> <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> Date: Sun, 30 Oct 2011 10:33:30 -0400 Message-ID: From: Ryan Stone To: Hooman Fazaeli Content-Type: text/plain; charset=ISO-8859-1 Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Jason Wolfe , Jack Vogel , Emil Muratov Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 30 Oct 2011 14:33:32 -0000 On Sun, Oct 30, 2011 at 4:57 AM, Hooman Fazaeli wrote: > IMHO, this is not a driver issue and the real fix would be to change > IFQ_HANDOFF to call if_start when the queue is full. I'm not sure that's the right approach. 99% of the time, calling if_start when the queue is full will be a waste of time. It seems to me that the link interrupt handler needs to kick off the tx task to drain the tx queue instead. From owner-freebsd-net@FreeBSD.ORG Sun Oct 30 16:00:26 2011 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 1DC401065754 for ; Sun, 30 Oct 2011 16:00:26 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id EB8EB8FC16 for ; Sun, 30 Oct 2011 16:00:22 +0000 (UTC) Received: by bkbzs2 with SMTP id zs2so2588794bkb.13 for ; Sun, 30 Oct 2011 09:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WBxLUUYoBpEQUXUjaVuCpHTW+8YY5h+1ehYxlWNgFmQ=; b=imQCpsycAk4KEw+MbFNPl/l+Od9/s/qL2hjGqPRhGBbxyBKSLUPOzTauKtjPAknQG/ ppOo3bjAPCkSeI9DKs4zfYUStAIGF2fH/nu35q6pzJQp3M6a7Pqylfz24o9T5Y05jftG 2vMGTp5hwuizOch+1qySdhE8Iw2NyZJKQOIL4= Received: by 10.204.141.8 with SMTP id k8mr8153858bku.14.1319990421766; Sun, 30 Oct 2011 09:00:21 -0700 (PDT) Received: from [192.168.1.180] ([84.241.57.181]) by mx.google.com with ESMTPS id w8sm14101548bks.11.2011.10.30.09.00.18 (version=SSLv3 cipher=OTHER); Sun, 30 Oct 2011 09:00:21 -0700 (PDT) Message-ID: <4EAD7490.4040108@gmail.com> Date: Sun, 30 Oct 2011 19:30:16 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Ryan Stone References: <4E8F157A.40702@sentex.net> <4E8F51D4.1060509@sentex.net> <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Jason Wolfe , Jack Vogel , Emil Muratov Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 30 Oct 2011 16:00:26 -0000 On 10/30/2011 6:03 PM, Ryan Stone wrote: > On Sun, Oct 30, 2011 at 4:57 AM, Hooman Fazaeli wrote: >> IMHO, this is not a driver issue and the real fix would be to change >> IFQ_HANDOFF to call if_start when the queue is full. > I'm not sure that's the right approach. 99% of the time, calling > if_start when the queue is full will be a waste of time. It seems to > me that the link interrupt handler needs to kick off the tx task to > drain the tx queue instead. If the queue were not full, system would consume the CPU for sending packets. Now, that it is full, a much little time is used to recover from a (temporary) problem. Not a big deal! Furthermore, the most common case for queue being full is stack sending packets too fast. In this case OACTIVE is set and if_start is not called at all. Changing HANDOFF has the benefit that it is simple, can be implemented fast and fixes the problem once for all drivers and for all such dangerous bugs not yet discovered. It also makes drivers' code simpler. From owner-freebsd-net@FreeBSD.ORG Sun Oct 30 17:54:36 2011 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 51C23106566B for ; Sun, 30 Oct 2011 17:54:36 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id CB4328FC08 for ; Sun, 30 Oct 2011 17:54:35 +0000 (UTC) Received: by wyh11 with SMTP id 11so1176227wyh.13 for ; Sun, 30 Oct 2011 10:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n0ZznAjjit9oNMKBU/8qvkyBpLSY3YAt+OYDm++cJ74=; b=FTD+ZdBZPeBfsq2tIB/pP5XMu1xe8tuNsI1jVN2/vlQuzmczmee/cYpMOAC/UkhVBO ck5snCd/rzVkUs5ImksCmRR4z2nq1jJaLn+5IggCffL9rhd459nkJ+XHieYfIW5ZPe++ JBwwI8IQT00wEi39X8APw2BZvfCeveGoQs/Ro= MIME-Version: 1.0 Received: by 10.227.205.76 with SMTP id fp12mr15362801wbb.17.1319997274610; Sun, 30 Oct 2011 10:54:34 -0700 (PDT) Received: by 10.180.24.232 with HTTP; Sun, 30 Oct 2011 10:54:34 -0700 (PDT) In-Reply-To: <4EAD7490.4040108@gmail.com> References: <4E8F157A.40702@sentex.net> <4E8F51D4.1060509@sentex.net> <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> <4EAD7490.4040108@gmail.com> Date: Sun, 30 Oct 2011 10:54:34 -0700 Message-ID: From: Jack Vogel To: Hooman Fazaeli Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Ryan Stone , Jason Wolfe , Emil Muratov Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 30 Oct 2011 17:54:36 -0000 I have a delta to em that is coming, it has some changes that effect 82574 anyway and everyone with issues should test it. I'll give this issue some thought tomorrow. Jack On Sun, Oct 30, 2011 at 9:00 AM, Hooman Fazaeli wrote: > On 10/30/2011 6:03 PM, Ryan Stone wrote: > >> On Sun, Oct 30, 2011 at 4:57 AM, Hooman Fazaeli> >> wrote: >> >>> IMHO, this is not a driver issue and the real fix would be to change >>> IFQ_HANDOFF to call if_start when the queue is full. >>> >> I'm not sure that's the right approach. 99% of the time, calling >> if_start when the queue is full will be a waste of time. It seems to >> me that the link interrupt handler needs to kick off the tx task to >> drain the tx queue instead. >> > If the queue were not full, system would consume the CPU for sending > packets. Now, that it is full, a much little time is used to recover > from a (temporary) problem. Not a big deal! > > Furthermore, the most common case for queue being full is stack > sending packets too fast. In this case OACTIVE is set and if_start > is not called at all. > > Changing HANDOFF has the benefit that it is simple, can be implemented > fast and > fixes the problem once for all drivers and for all such dangerous bugs not > yet > discovered. It also makes drivers' code simpler. > > > From owner-freebsd-net@FreeBSD.ORG Mon Oct 31 00:25:28 2011 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 5CF55106564A for ; Mon, 31 Oct 2011 00:25:28 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id DAB098FC0A for ; Mon, 31 Oct 2011 00:25:27 +0000 (UTC) Received: by wwi18 with SMTP id 18so7763883wwi.31 for ; Sun, 30 Oct 2011 17:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=7uA/KwtvLWugU+2xQYFHX9hss+4m5FNi1rp/7dDnKpw=; b=kCJuBoBVBU6+vBOUNqmV0qARj/k5oNksC9Csd6y/X4ksQPiyh4yBOQZ3/lGmKeW43h WQVCDh8NprvzlgvGDO6bDNtSRbcCsNX/ejKGu8tpK2gyn5LD2fZoeU6QBLrLrob99XR9 yaswh6POBVfOXoegjCw/PuSU/zXIZcrpw0Jjc= Received: by 10.227.198.140 with SMTP id eo12mr14917598wbb.20.1320020726755; Sun, 30 Oct 2011 17:25:26 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id b5sm29424131wbh.4.2011.10.30.17.25.22 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 30 Oct 2011 17:25:25 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 30 Oct 2011 17:23:49 -0700 From: YongHyeon PYUN Date: Sun, 30 Oct 2011 17:23:49 -0700 To: Hooman Fazaeli Message-ID: <20111031002349.GA1679@michelle.cdnetworks.com> References: <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EAD116A.8090006@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Jason Wolfe , Emil Muratov , Jack Vogel Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 31 Oct 2011 00:25:28 -0000 On Sun, Oct 30, 2011 at 12:27:14PM +0330, Hooman Fazaeli wrote: > > I finally managed to re-produce an affect similar to Jason's case. It > may not be the exact same issue, but it is a serious problem and must > be addressed. > > 1. Push out packet on em/igb with high rate. > 2. Disconnect cable and wait for a few seconds. "netstat -ind" shows that > Drops are increasing. > 3. Re-connect the cable. Both sides of like re-negotiate and the links > comes up. > 4. But ..., no packets is ever transmitted again and Drops still increasing! > > This is because em/lem/igb and some other interfaces (i.e., bce) have > a check at the very beginning of their _start function > which checks link status and immediately returns if it is inactive. > This behavior causes if_snd to fills up in step 2 and when this happens, > IFQ_HANDOFF never calls if_start again, even when the link becomes > active again. > > A cable unplug is not necessary to trigger the issue. Any temporary > link loss (e.i., during re-negotiation) can potentially lead to > aforementioned problem. > > IMHO, this is not a driver issue and the real fix would be to change > IFQ_HANDOFF to call if_start when the queue is full. > It would be normal not to call IFQ_HANDOFF when driver queue is full since it would be waste of time to invoke driver TX routine again. If driver fails to send queued frames again when it re-established a link it sounds like a driver bug. Of course, there is a problem here as driver can send queued frames without knowing how much time the frame queued in TX queue. Depending on application this behavior may or may not useful. > Jason, If you are interested, I can prepare a patch for you > to address this issue in if_em and see if it helps. > From owner-freebsd-net@FreeBSD.ORG Mon Oct 31 00:44:56 2011 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 13BDB1065678; Mon, 31 Oct 2011 00:44:56 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 049438FC18; Mon, 31 Oct 2011 00:44:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9V0itIk047194; Mon, 31 Oct 2011 00:44:55 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9V0it5b047190; Mon, 31 Oct 2011 00:44:55 GMT (envelope-from yongari) Date: Mon, 31 Oct 2011 00:44:55 GMT Message-Id: <201110310044.p9V0it5b047190@freefall.freebsd.org> To: koscak.gregor@gmail.com, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/162068: [msk] Marvell Yukon GE onboard card does not work in 1000baseTX mode 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, 31 Oct 2011 00:44:56 -0000 Synopsis: [msk] Marvell Yukon GE onboard card does not work in 1000baseTX mode State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon Oct 31 00:44:18 UTC 2011 State-Changed-Why: There was an important change in msk(4) and that change requires "cold boot" to make the change effect. So did you try to "cold boot" on 9.0-RC1? Cold boot means you have to power off your box and unplug power cord and wait 1-2 minutes then boot your box. Let me know whether that makes any differences. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Oct 31 00:44:18 UTC 2011 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=162068 From owner-freebsd-net@FreeBSD.ORG Mon Oct 31 00:56:57 2011 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 0F0D81065670 for ; Mon, 31 Oct 2011 00:56:57 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 95A188FC0A for ; Mon, 31 Oct 2011 00:56:56 +0000 (UTC) Received: by wwp14 with SMTP id 14so5167wwp.31 for ; Sun, 30 Oct 2011 17:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Cc/IXUteiHdwP8EazIb9HM6JyBApBi2hhsuOEGNW0QI=; b=ByMNuA6u5WPMBxovKwhD7ITB54jsVR46SiR/EdGVzJpSlatVmlZ/I293dTOrKWKJzn WcxgfGKy6g2j0GlauSAT46MVnhpVLy0mrWQDLc8Nj0PsPJcCZneRlcHgsBkNs37KOjoK tzWZT+iFGlhuwIyGxk/2JB/YHECFYw1p4FNws= Received: by 10.227.202.70 with SMTP id fd6mr14966835wbb.27.1320022615533; Sun, 30 Oct 2011 17:56:55 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id l20sm29515756wbo.6.2011.10.30.17.56.52 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 30 Oct 2011 17:56:54 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 30 Oct 2011 17:55:19 -0700 From: YongHyeon PYUN Date: Sun, 30 Oct 2011 17:55:19 -0700 To: Andrey Smagin Message-ID: <20111031005519.GC1679@michelle.cdnetworks.com> References: <20111026164800.GA13234@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: PCI-E VT6130 NIC (if_vge) hang system with gigabit link 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, 31 Oct 2011 00:56:57 -0000 On Sat, Oct 29, 2011 at 09:57:30AM +0400, Andrey Smagin wrote: > > Ok. With autonegotiation ifconfig show speed 100MBit. And vge(4) work without problems with the resolved speed/duplex of auto-negotiation? > with manual 1000baseT full-duplex settings in dmesg: > vge0: failed to start MII autopoll > vge0: MII read timed out > vge0: failed to start MII autopoll > vge0: link state changed to UP > vge0: MII read timed out [...] Did vge(4) ever work with 1000baseT on your box? And why you have to manually configure 1000baseT link? Does link partner(switch) also use auto-negotiation? From owner-freebsd-net@FreeBSD.ORG Mon Oct 31 02:28:15 2011 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 6D540106564A for ; Mon, 31 Oct 2011 02:28:15 +0000 (UTC) (envelope-from remy.sanchez@hyperthese.net) Received: from slow3-v.mail.gandi.net (slow3-v.mail.gandi.net [217.70.178.89]) by mx1.freebsd.org (Postfix) with ESMTP id E6A4C8FC16 for ; Mon, 31 Oct 2011 02:28:14 +0000 (UTC) X-WhiteListed: mail was accepted with no delay X-WhiteListed: mail was accepted with no delay Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by slow3-v.mail.gandi.net (Postfix) with ESMTP id 3A7C338203 for ; Mon, 31 Oct 2011 03:02:20 +0100 (CET) Received: from magi.localnet (unknown [IPv6:2a01:e35:2e3d:8820:21f:16ff:feb6:9aac]) (Authenticated sender: remy.sanchez@hyperthese.net) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 24986A8281 for ; Mon, 31 Oct 2011 03:02:08 +0100 (CET) From: =?iso-8859-1?q?R=E9my_Sanchez?= To: freebsd-net@freebsd.org Date: Mon, 31 Oct 2011 03:01:53 +0100 User-Agent: KMail/1.13.7 (Linux/3.0.0-2-amd64; KDE/4.6.5; x86_64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart11913474.car13WglQ2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201110310301.59604.remy.sanchez@hyperthese.net> Subject: Re: multiple ISP 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, 31 Oct 2011 02:28:15 -0000 --nextPart11913474.car13WglQ2 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Friday 28 October 2011 16:22:25 nyoman.bogi@gmail.com wrote: > dear all, >=20 > I need to set up a router (using FreeBSD) > that connect to the Internet > to accomodate multiple ISP, > so users can be load balanced through > those several ISP lines. >=20 > how can I do that? >=20 > thanks in advance Well, let's suppose that your ISP interfaces have respectively $ispN_ip and= =20 $ispN_router as interface IP and ISP router IP. And that $natN is the diver= t=20 port corresponding to the NAT for the given ISP. Then you get something like # This treats incoming trafic ipfw add 1310 divert $nat1 ip from any to any in via $if1 ipfw add 1320 divert $nat2 ip from any to any in via $if2 =2E.. ipfw add 13N0 divert $natN ip from any to any in via $ifN # Check states ipfw add 3000 check-state # Load balance outgoing trafic # Note: change 1/N, 1/(N-1), etc by actual values for your N ipfw add 10100 prob 1/N skipto 20100 ip from $internal to any keep-state ipfw add 10200 prob 1/(N-1) skipto 20200 ip from $internal to any keep-state =2E.. ipfw add 10N00 skipto 20N00 ip from $internal to any keep-state # Do outgoing NAT ipfw add 20100 divert $nat1 from $internal to any out ipfw add 20110 fwd $isp1_router ip from $isp1_ip ipfw add 20200 divert $nat2 from $internal to any out ipfw add 20210 fwd $isp2_router ip from $isp2_ip =2E.. ipfw add 20N00 divert $natN from $internal to any out ipfw add 20N10 fwd $ispN_router ip from $ispN_ip And here is what the natd.conf would look like ### ISP 1 ### port 8868 dynamic yes interface re1 ### ISP 2 ### instance dsl2 port 8869 dynamic yes interface re2 ### ISP N ### instance dsl3 port 8870 dynamic yes interface re You'll notice that the load balancing rules are skipto to NAT rules instead= of=20 directly being NAT rules. This is because this way you can factorize your N= AT=20 rules with several sets of load-balancing rules (like having different=20 patterns for TCP and UDP, or depending on the users, etc). Also note that those lines are inspired by my actual configuration file, th= at=20 is much more complex than this, and I didn't test anything, so it might not= =20 work out-of-the-box, however this gives you a good preview of what it shoul= d=20 be. One last important thing : this kind of load-balancing can be relatively=20 complex to get correctly working if you do have different bitrates from you= r=20 ISPs. You might also want to try protocols like MLPPP (with mpd for example= ),=20 but this is more complex to setup and you need a server on "the other side"= to=20 get it working. Well, have fun :) =2D-=20 R=E9my Sanchez http://hyperthese.net/ --nextPart11913474.car13WglQ2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk6uAZIACgkQpMMQ4XyIN1bgSQCg2N0HZikMBLLxo4LRMbgMQmZz uYkAoK8BLMDUG4bzVu1GPWZbmFBtjHxU =9yWk -----END PGP SIGNATURE----- --nextPart11913474.car13WglQ2-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 31 04:03:06 2011 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 A44E21065673 for ; Mon, 31 Oct 2011 04:03:06 +0000 (UTC) (envelope-from nitroboost@gmail.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 56D758FC17 for ; Mon, 31 Oct 2011 04:03:06 +0000 (UTC) Received: by ywt32 with SMTP id 32so7276145ywt.13 for ; Sun, 30 Oct 2011 21:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3Xfj0aPsLJMitNnEXOOZCNHeXL7sULiErvsBfbmXO+w=; b=gE+SkZi5bavyuuOgc4r3SuOKWnnmIcx3mdFU9JkgTxWutt9/VSGu+/nRbEFkjvJgFE 0AHkrU1GoN/WiXExRcUnfsq67zXNVQ8GcSzIJLVHF/Cm76ojlPIpcCD1z0D5+SlFTQnP OVXvfjvzkQj0bkq7rTUb+Wyd/380dhPiYijPk= MIME-Version: 1.0 Received: by 10.182.17.103 with SMTP id n7mr2521686obd.68.1320033785354; Sun, 30 Oct 2011 21:03:05 -0700 (PDT) Received: by 10.182.35.193 with HTTP; Sun, 30 Oct 2011 21:03:05 -0700 (PDT) In-Reply-To: <4EAD116A.8090006@gmail.com> References: <4E8F157A.40702@sentex.net> <4E8F51D4.1060509@sentex.net> <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> Date: Sun, 30 Oct 2011 21:03:05 -0700 Message-ID: From: Jason Wolfe To: Hooman Fazaeli Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Jack Vogel , Emil Muratov Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 31 Oct 2011 04:03:06 -0000 On Sun, Oct 30, 2011 at 1:57 AM, Hooman Fazaeli wrote: > > I finally managed to re-produce an affect similar to Jason's case. It > may not be the exact same issue, but it is a serious problem and must > be addressed. > > 1. Push out packet on em/igb with high rate. > 2. Disconnect cable and wait for a few seconds. "netstat -ind" shows that > Drops are increasing. > 3. Re-connect the cable. Both sides of like re-negotiate and the links > comes up. > 4. But ..., no packets is ever transmitted again and Drops still > increasing! > > This is because em/lem/igb and some other interfaces (i.e., bce) have > a check at the very beginning of their _start function > which checks link status and immediately returns if it is inactive. > This behavior causes if_snd to fills up in step 2 and when this happens, > IFQ_HANDOFF never calls if_start again, even when the link becomes > active again. > > A cable unplug is not necessary to trigger the issue. Any temporary > link loss (e.i., during re-negotiation) can potentially lead to > aforementioned problem. > > IMHO, this is not a driver issue and the real fix would be to change > IFQ_HANDOFF to call if_start when the queue is full. > > Jason, If you are interested, I can prepare a patch for you > to address this issue in if_em and see if it helps. > Hooman, Thanks for looking into this. I'd be happy to test any patch thrown my way, but keep in mind my issue is only tickled when MSI-X is enabled. My interfaces aren't bouncing, though it might be possible some unique path in the MSI-X code is causing a throughput hang akin to connectivity loss? Jack is the delta your speaking to the 7.2.4 code? I did manage to get the code from Intel compiled with a couple minutes of work, but haven't loaded it up yet as I didn't see anything that caught my untrained eye in the diffs. I'll wait until its ported over and would be happy to test if needed. Conveniently enough I just received another report from my test boxes with a pretty stock loader.conf. I had forgotten to remove the advanced options from the interfaces after I cycled them to pick up the fc_setting=0. Fixed that up just meow. hw.em.fc_setting="0" cc_cubic_load="YES" I bounced em0 because dropped packets incremented 368756 to 369124 and the interface is not incrementing packets out. 5:35PM up 2 days, 17:45, 0 users, load averages: 0.34, 0.45, 0.48 em0: flags=8843 metric 0 mtu 1500 options=219b ether X inet6 X%em0 prefixlen 64 scopeid 0x1 nd6 options=1 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 1500 options=219b ether X inet6 X%em1 prefixlen 64 scopeid 0x2 inet6 X prefixlen 64 autoconf nd6 options=3 media: Ethernet autoselect (1000baseT ) status: active ipfw0: flags=8801 metric 0 mtu 65536 lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet X.X.X.X netmask 0xffffffff inet X.X.X.X netmask 0xffffffff inet X.X.X.X netmask 0xffffffff inet X.X.X.X netmask 0xffffffff inet X.X.X.X netmask 0xffffffff inet X.X.X.X netmask 0xffffffff inet X.X.X.X netmask 0xffffffff inet X.X.X.X netmask 0xffffffff nd6 options=3 lagg0: flags=8843 metric 0 mtu 1500 options=219b ether X inet X.X.X.X netmask 0xffffff00 broadcast X.X.X.X inet6 X%lagg0 prefixlen 64 scopeid 0x5 nd6 options=3 media: Ethernet autoselect status: active laggproto loadbalance laggport: em0 flags=4 laggport: em1 flags=4 interrupt total rate irq3: uart1 3456 0 cpu0: timer 473404250 2000 irq256: em0:rx 0 24614350 103 irq257: em0:tx 0 1220810972 5157 irq258: em0:link 1 0 irq259: em1:rx 0 1533295149 6477 irq260: em1:tx 0 1194032538 5044 irq261: em1:link 3272 0 irq262: mps0 189602667 801 cpu3: timer 473396089 2000 cpu1: timer 473396089 2000 cpu2: timer 473396081 2000 Total 6055954914 25585 32999/8476/41475 mbufs in use (current/cache/total) 4064/3398/7462/5872038 mbuf clusters in use (current/cache/total/max) 4064/800 mbuf+clusters out of packet secondary zone in use (current/cache) 24900/669/25569/2936019 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) 115977K/11591K/127568K 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 61 requests for I/O initiated by sendfile 0 calls to protocol drain routines Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop em0 1500 00:25:90:2a:a2:d7 24946787 0 0 5734180355 0 0 369844 em0 1500 fe80:1::225:9 fe80:1::225:90ff: 0 - - 2 - - - em1 1500 00:25:90:2a:a2:d7 5220869518 15996 0 5429971995 0 0 37009 em1 1500 fe80:2::225:9 fe80:2::225:90ff: 0 - - 1 - - - em1 1500 2607:f4e8:310 2607:f4e8:310:12: 0 - - 0 - - - lagg0 1500 00:25:90:2a:a2:d7 5245767782 0 0 11162877037 406853 0 0 lagg0 1500 69.164.38.0/2 69.164.38.69 4776881809 - - 11164303625 - - - lagg0 1500 fe80:5::225:9 fe80:5::225:90ff: 0 - - 3 - - - kern.msgbuf: Oct 30 17:08:38 cds1019 kernel: ifa_add_loopback_route: insertion failed Oct 30 17:12:10 cds1019 kernel: ifa_add_loopback_route: insertion failed Oct 30 17:20:20 cds1019 last message repeated 3 times Oct 30 17:32:13 cds1019 last message repeated 4 times Oct 30 17:34:27 cds1019 kernel: ifa_add_loopback_route: insertion failed Oct 30 17:35:03 cds1019 kernel: Interface is RUNNING and INACTIVE Oct 30 17:35:03 cds1019 kernel: em0: hw tdh = 818, hw tdt = 818 Oct 30 17:35:03 cds1019 kernel: em0: hw rdh = 99, hw rdt = 98 Oct 30 17:35:03 cds1019 kernel: em0: Tx Queue Status = 0 Oct 30 17:35:03 cds1019 kernel: em0: TX descriptors avail = 1024 Oct 30 17:35:03 cds1019 kernel: em0: Tx Descriptors avail failure = 0 Oct 30 17:35:03 cds1019 kernel: em0: RX discarded packets = 0 Oct 30 17:35:03 cds1019 kernel: em0: RX Next to Check = 110 Oct 30 17:35:03 cds1019 kernel: em0: RX Next to Refresh = 109 Oct 30 17:35:03 cds1019 kernel: em0: Link state: active Oct 30 17:35:03 cds1019 kernel: Interface is RUNNING and INACTIVE Oct 30 17:35:03 cds1019 kernel: em1: hw tdh = 688, hw tdt = 688 Oct 30 17:35:03 cds1019 kernel: em1: hw rdh = 861, hw rdt = 860 Oct 30 17:35:03 cds1019 kernel: em1: Tx Queue Status = 1 Oct 30 17:35:03 cds1019 kernel: em1: TX descriptors avail = 1024 Oct 30 17:35:03 cds1019 kernel: em1: Tx Descriptors avail failure = 0 Oct 30 17:35:03 cds1019 kernel: em1: RX discarded packets = 0 Oct 30 17:35:03 cds1019 kernel: em1: RX Next to Check = 19 Oct 30 17:35:03 cds1019 kernel: em1: RX Next to Refresh = 85 Oct 30 17:35:03 cds1019 kernel: em1: Link state: active net.inet.ip.intr_queue_maxlen: 512 net.inet.ip.intr_queue_drops: 0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 subdevice=0x10d3 class=0x020000 dev.em.0.%parent: pci1 dev.em.0.nvm: -1 dev.em.0.debug: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.0.flow_control: 0 dev.em.0.eee_control: 0 dev.em.0.link_irq: 1 dev.em.0.mbuf_alloc_fail: 0 dev.em.0.cluster_alloc_fail: 0 dev.em.0.dropped: 0 dev.em.0.tx_dma_fail: 0 dev.em.0.rx_overruns: 0 dev.em.0.watchdog_timeouts: 0 dev.em.0.device_control: 1074790984 dev.em.0.rx_control: 67141634 dev.em.0.fc_high_water: 18432 dev.em.0.fc_low_water: 16932 dev.em.0.queue0.txd_head: 818 dev.em.0.queue0.txd_tail: 818 dev.em.0.queue0.tx_irq: 1220810942 dev.em.0.queue0.no_desc_avail: 0 dev.em.0.queue0.rxd_head: 314 dev.em.0.queue0.rxd_tail: 313 dev.em.0.queue0.rx_irq: 24614539 dev.em.0.mac_stats.excess_coll: 0 dev.em.0.mac_stats.single_coll: 0 dev.em.0.mac_stats.multiple_coll: 0 dev.em.0.mac_stats.late_coll: 0 dev.em.0.mac_stats.collision_count: 0 dev.em.0.mac_stats.symbol_errors: 0 dev.em.0.mac_stats.sequence_errors: 0 dev.em.0.mac_stats.defer_count: 0 dev.em.0.mac_stats.missed_packets: 0 dev.em.0.mac_stats.recv_no_buff: 0 dev.em.0.mac_stats.recv_undersize: 0 dev.em.0.mac_stats.recv_fragmented: 0 dev.em.0.mac_stats.recv_oversize: 0 dev.em.0.mac_stats.recv_jabber: 0 dev.em.0.mac_stats.recv_errs: 0 dev.em.0.mac_stats.crc_errs: 0 dev.em.0.mac_stats.alignment_errs: 0 dev.em.0.mac_stats.coll_ext_errs: 0 dev.em.0.mac_stats.xon_recvd: 0 dev.em.0.mac_stats.xon_txd: 0 dev.em.0.mac_stats.xoff_recvd: 0 dev.em.0.mac_stats.xoff_txd: 0 dev.em.0.mac_stats.total_pkts_recvd: 24955229 dev.em.0.mac_stats.good_pkts_recvd: 24955229 dev.em.0.mac_stats.bcast_pkts_recvd: 24945466 dev.em.0.mac_stats.mcast_pkts_recvd: 1377 dev.em.0.mac_stats.rx_frames_64: 24945502 dev.em.0.mac_stats.rx_frames_65_127: 1606 dev.em.0.mac_stats.rx_frames_128_255: 7963 dev.em.0.mac_stats.rx_frames_256_511: 157 dev.em.0.mac_stats.rx_frames_512_1023: 1 dev.em.0.mac_stats.rx_frames_1024_1522: 0 dev.em.0.mac_stats.good_octets_recvd: 1597800626 dev.em.0.mac_stats.good_octets_txd: 7770925595880 dev.em.0.mac_stats.total_pkts_txd: 5734191501 dev.em.0.mac_stats.good_pkts_txd: 5734191501 dev.em.0.mac_stats.bcast_pkts_txd: 4 dev.em.0.mac_stats.mcast_pkts_txd: 1584 dev.em.0.mac_stats.tx_frames_64: 25504167 dev.em.0.mac_stats.tx_frames_65_127: 485744914 dev.em.0.mac_stats.tx_frames_128_255: 5963478 dev.em.0.mac_stats.tx_frames_256_511: 9021090 dev.em.0.mac_stats.tx_frames_512_1023: 55803019 dev.em.0.mac_stats.tx_frames_1024_1522: 5152154833 dev.em.0.mac_stats.tso_txd: 0 dev.em.0.mac_stats.tso_ctx_fail: 0 dev.em.0.interrupts.asserts: 3 dev.em.0.interrupts.rx_pkt_timer: 0 dev.em.0.interrupts.rx_abs_timer: 0 dev.em.0.interrupts.tx_pkt_timer: 0 dev.em.0.interrupts.tx_abs_timer: 0 dev.em.0.interrupts.tx_queue_empty: 0 dev.em.0.interrupts.tx_queue_min_thresh: 0 dev.em.0.interrupts.rx_desc_min_thresh: 0 dev.em.0.interrupts.rx_overrun: 0 dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=0 dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 subdevice=0x10d3 class=0x020000 dev.em.1.%parent: pci2 dev.em.1.nvm: -1 dev.em.1.debug: -1 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 100 dev.em.1.flow_control: 0 dev.em.1.eee_control: 0 dev.em.1.link_irq: 3272 dev.em.1.mbuf_alloc_fail: 0 dev.em.1.cluster_alloc_fail: 0 dev.em.1.dropped: 0 dev.em.1.tx_dma_fail: 0 dev.em.1.rx_overruns: 0 dev.em.1.watchdog_timeouts: 0 dev.em.1.device_control: 1074790984 dev.em.1.rx_control: 67141634 dev.em.1.fc_high_water: 18432 dev.em.1.fc_low_water: 16932 dev.em.1.queue0.txd_head: 9 dev.em.1.queue0.txd_tail: 14 dev.em.1.queue0.tx_irq: 1194045687 dev.em.1.queue0.no_desc_avail: 0 dev.em.1.queue0.rxd_head: 317 dev.em.1.queue0.rxd_tail: 315 dev.em.1.queue0.rx_irq: 1528821076 dev.em.1.mac_stats.excess_coll: 0 dev.em.1.mac_stats.single_coll: 0 dev.em.1.mac_stats.multiple_coll: 0 dev.em.1.mac_stats.late_coll: 0 dev.em.1.mac_stats.collision_count: 0 dev.em.1.mac_stats.symbol_errors: 0 dev.em.1.mac_stats.sequence_errors: 0 dev.em.1.mac_stats.defer_count: 0 dev.em.1.mac_stats.missed_packets: 15996 dev.em.1.mac_stats.recv_no_buff: 1035 dev.em.1.mac_stats.recv_undersize: 0 dev.em.1.mac_stats.recv_fragmented: 0 dev.em.1.mac_stats.recv_oversize: 0 dev.em.1.mac_stats.recv_jabber: 0 dev.em.1.mac_stats.recv_errs: 0 dev.em.1.mac_stats.crc_errs: 0 dev.em.1.mac_stats.alignment_errs: 0 dev.em.1.mac_stats.coll_ext_errs: 0 dev.em.1.mac_stats.xon_recvd: 0 dev.em.1.mac_stats.xon_txd: 0 dev.em.1.mac_stats.xoff_recvd: 0 dev.em.1.mac_stats.xoff_txd: 0 dev.em.1.mac_stats.total_pkts_recvd: 5220907923 dev.em.1.mac_stats.good_pkts_recvd: 5220891927 dev.em.1.mac_stats.bcast_pkts_recvd: 24943828 dev.em.1.mac_stats.mcast_pkts_recvd: 1375 dev.em.1.mac_stats.rx_frames_64: 1897964107 dev.em.1.mac_stats.rx_frames_65_127: 2457591621 dev.em.1.mac_stats.rx_frames_128_255: 5971619 dev.em.1.mac_stats.rx_frames_256_511: 11235726 dev.em.1.mac_stats.rx_frames_512_1023: 32267871 dev.em.1.mac_stats.rx_frames_1024_1522: 815860983 dev.em.1.mac_stats.good_octets_recvd: 1562681996232 dev.em.1.mac_stats.good_octets_txd: 7334946827215 dev.em.1.mac_stats.total_pkts_txd: 5430018684 dev.em.1.mac_stats.good_pkts_txd: 5430018682 dev.em.1.mac_stats.bcast_pkts_txd: 940 dev.em.1.mac_stats.mcast_pkts_txd: 12 dev.em.1.mac_stats.tx_frames_64: 24843579 dev.em.1.mac_stats.tx_frames_65_127: 483343565 dev.em.1.mac_stats.tx_frames_128_255: 5819327 dev.em.1.mac_stats.tx_frames_256_511: 7998506 dev.em.1.mac_stats.tx_frames_512_1023: 44787728 dev.em.1.mac_stats.tx_frames_1024_1522: 4863225979 dev.em.1.mac_stats.tso_txd: 0 dev.em.1.mac_stats.tso_ctx_fail: 0 dev.em.1.interrupts.asserts: 2398 dev.em.1.interrupts.rx_pkt_timer: 1 dev.em.1.interrupts.rx_abs_timer: 0 dev.em.1.interrupts.tx_pkt_timer: 0 dev.em.1.interrupts.tx_abs_timer: 0 dev.em.1.interrupts.tx_queue_empty: 0 dev.em.1.interrupts.tx_queue_min_thresh: 0 dev.em.1.interrupts.rx_desc_min_thresh: 0 dev.em.1.interrupts.rx_overrun: 2 hw.em.eee_setting: 0 hw.em.fc_setting: 0 hw.em.rx_process_limit: 100 hw.em.enable_msix: 1 hw.em.sbp: 0 hw.em.smart_pwr_down: 0 hw.em.txd: 1024 hw.em.rxd: 1024 hw.em.rx_abs_int_delay: 66 hw.em.tx_abs_int_delay: 66 hw.em.rx_int_delay: 0 hw.em.tx_int_delay: 66 Jason From owner-freebsd-net@FreeBSD.ORG Mon Oct 31 05:27:13 2011 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 76A3F106566B for ; Mon, 31 Oct 2011 05:27:13 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id F02378FC18 for ; Mon, 31 Oct 2011 05:27:12 +0000 (UTC) Received: by wwp14 with SMTP id 14so138592wwp.31 for ; Sun, 30 Oct 2011 22:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yl97TxWAi3sQ19UxzpkEt0Pcc/WbS07adJP0pZdT3fI=; b=ADFaP9IC3ScEvf6N7wsCyNL9InyvjXCKSOanrck3hzAwTu5B35Ij4LoLdyVWn2+Jhw EkQ3puRFhYzO1xXoOiaJqGdkZMQyrKKU2S3XFGv0CcnXHQ6wFNgseG5ECRSAOXtFi53+ ujnmUPIxdK1m+Qhv3FF/CdgSeXwXkg5fQjLfE= MIME-Version: 1.0 Received: by 10.227.205.130 with SMTP id fq2mr17954479wbb.17.1320038831722; Sun, 30 Oct 2011 22:27:11 -0700 (PDT) Received: by 10.180.24.232 with HTTP; Sun, 30 Oct 2011 22:27:11 -0700 (PDT) In-Reply-To: References: <4E8F157A.40702@sentex.net> <4E8F51D4.1060509@sentex.net> <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> Date: Sun, 30 Oct 2011 22:27:11 -0700 Message-ID: From: Jack Vogel To: Jason Wolfe Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Emil Muratov , Hooman Fazaeli Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 31 Oct 2011 05:27:13 -0000 On Sun, Oct 30, 2011 at 9:03 PM, Jason Wolfe wrote: ... > > > Jack is the delta your speaking to the 7.2.4 code? I did manage to get > the code from Intel compiled with a couple minutes of work, but haven't > loaded it up yet as I didn't see anything that caught my untrained eye in > the diffs. I'll wait until its ported over and would be happy to test if > needed. > > The "code from Intel" is just my code channeled thru internal release processes :) the code at the tip of HEAD should be as current as you would ever find. This delta is actually got a shared code change that is specifically for 82574, it address a TX problem that was found either using Windows or Linux, I'm not sure, so its unknown whether its going to fix what those still having issues are seeing or not. Even so, its a "service" type fix in the shared code, everyone should have it. There are a couple other changes in my core code as well, I will send it as a standalone tarball, do NOT try to drop this code into the kernel tree, it will break things, you will need to build and use this seperately for the moment, I will merge it into the kernel properly subsequently. Anyway, I'll send it out tomorrow sometime. Cheers, Jack From owner-freebsd-net@FreeBSD.ORG Mon Oct 31 08:13:32 2011 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 753F0106564A for ; Mon, 31 Oct 2011 08:13:32 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B07618FC14 for ; Mon, 31 Oct 2011 08:13:31 +0000 (UTC) Received: by bkbzs2 with SMTP id zs2so3086286bkb.13 for ; Mon, 31 Oct 2011 01:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=CZMtgeiRQY/t+xYD6atxSpitBlE+hSBmQbYf/5jafrQ=; b=ff8Vq0WDEsyuo+Eb8EEXW2DYiXFGn7oIk3Sz5cT4ZEAApXAhVP65VUJdzvwtyyjMu+ +2Q3QSGJAOULzL2lhrDvBWtiH43ImK7FWp5etElr3m9D9/F6K9I0p8vafQAp74NSGyEH 6N+kTS7uCLAKOpqcEKW6n1StPKpjat+Qnilqw= Received: by 10.204.129.88 with SMTP id n24mr1647894bks.62.1320048810062; Mon, 31 Oct 2011 01:13:30 -0700 (PDT) Received: from [127.0.0.1] ([84.241.57.181]) by mx.google.com with ESMTPS id w8sm16184542bks.11.2011.10.31.01.13.26 (version=SSLv3 cipher=OTHER); Mon, 31 Oct 2011 01:13:28 -0700 (PDT) Message-ID: <4EAE58A2.9040803@gmail.com> Date: Mon, 31 Oct 2011 11:43:22 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Jason Wolfe References: <4E8F157A.40702@sentex.net> <4E8F51D4.1060509@sentex.net> <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------040503030709030405090900" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Jack Vogel , Emil Muratov Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 31 Oct 2011 08:13:32 -0000 This is a multi-part message in MIME format. --------------040503030709030405090900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/31/2011 7:33 AM, Jason Wolfe wrote: > > > Thanks for looking into this. I'd be happy to test any patch thrown my way, but keep in mind my issue is only tickled when MSI-X is enabled. My interfaces aren't bouncing, though it might be > possible some unique path in the MSI-X code is causing a throughput hang akin to connectivity loss? > > Jack is the delta your speaking to the 7.2.4 code? I did manage to get the code from Intel compiled with a couple minutes of work, but haven't loaded it up yet as I didn't see anything that caught > my untrained eye in the diffs. I'll wait until its ported over and would be happy to test if needed. > > Conveniently enough I just received another report from my test boxes with a pretty stock loader.conf. I had forgotten to remove the advanced options from the interfaces after I cycled them to pick > up the fc_setting=0. Fixed that up just meow. > > hw.em.fc_setting="0" > cc_cubic_load="YES" > > I bounced em0 because dropped packets incremented 368756 to 369124 and the interface is not incrementing packets out. > > 5:35PM up 2 days, 17:45, 0 users, load averages: 0.34, 0.45, 0.48 > > em0: flags=8843 metric 0 mtu 1500 > options=219b > ether X > inet6 X%em0 prefixlen 64 scopeid 0x1 > nd6 options=1 > media: Ethernet autoselect (1000baseT ) > status: active > > em1: flags=8843 metric 0 mtu 1500 > options=219b > ether X > inet6 X%em1 prefixlen 64 scopeid 0x2 > inet6 X prefixlen 64 autoconf > nd6 options=3 > media: Ethernet autoselect (1000baseT ) > status: active > > ipfw0: flags=8801 metric 0 mtu 65536 > > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet 127.0.0.1 netmask 0xff000000 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 > inet X.X.X.X netmask 0xffffffff > inet X.X.X.X netmask 0xffffffff > inet X.X.X.X netmask 0xffffffff > inet X.X.X.X netmask 0xffffffff > inet X.X.X.X netmask 0xffffffff > inet X.X.X.X netmask 0xffffffff > inet X.X.X.X netmask 0xffffffff > inet X.X.X.X netmask 0xffffffff > nd6 options=3 > > lagg0: flags=8843 metric 0 mtu 1500 > options=219b > ether X > inet X.X.X.X netmask 0xffffff00 broadcast X.X.X.X > inet6 X%lagg0 prefixlen 64 scopeid 0x5 > nd6 options=3 > media: Ethernet autoselect > status: active > laggproto loadbalance > laggport: em0 flags=4 > laggport: em1 flags=4 > > interrupt total rate > irq3: uart1 3456 0 > cpu0: timer 473404250 2000 > irq256: em0:rx 0 24614350 103 > irq257: em0:tx 0 1220810972 5157 > irq258: em0:link 1 0 > irq259: em1:rx 0 1533295149 6477 > irq260: em1:tx 0 1194032538 5044 > irq261: em1:link 3272 0 > irq262: mps0 189602667 801 > cpu3: timer 473396089 2000 > cpu1: timer 473396089 2000 > cpu2: timer 473396081 2000 > Total 6055954914 25585 > > 32999/8476/41475 mbufs in use (current/cache/total) > 4064/3398/7462/5872038 mbuf clusters in use (current/cache/total/max) > 4064/800 mbuf+clusters out of packet secondary zone in use (current/cache) > 24900/669/25569/2936019 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) > 115977K/11591K/127568K 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 > 61 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop > em0 1500 00:25:90:2a:a2:d7 24946787 0 0 5734180355 0 0 369844 > em0 1500 fe80:1::225:9 fe80:1::225:90ff: 0 - - 2 - - - > em1 1500 00:25:90:2a:a2:d7 5220869518 15996 0 5429971995 0 0 37009 > em1 1500 fe80:2::225:9 fe80:2::225:90ff: 0 - - 1 - - - > em1 1500 2607:f4e8:310 2607:f4e8:310:12: 0 - - 0 - - - > lagg0 1500 00:25:90:2a:a2:d7 5245767782 0 0 11162877037 406853 0 0 > lagg0 1500 69.164.38.0/2 69.164.38.69 4776881809 - - 11164303625 - - - > lagg0 1500 fe80:5::225:9 fe80:5::225:90ff: 0 - - 3 - - - > > kern.msgbuf: > > Oct 30 17:08:38 cds1019 kernel: ifa_add_loopback_route: insertion failed > Oct 30 17:12:10 cds1019 kernel: ifa_add_loopback_route: insertion failed > Oct 30 17:20:20 cds1019 last message repeated 3 times > Oct 30 17:32:13 cds1019 last message repeated 4 times > Oct 30 17:34:27 cds1019 kernel: ifa_add_loopback_route: insertion failed > Oct 30 17:35:03 cds1019 kernel: Interface is RUNNING and INACTIVE > Oct 30 17:35:03 cds1019 kernel: em0: hw tdh = 818, hw tdt = 818 > Oct 30 17:35:03 cds1019 kernel: em0: hw rdh = 99, hw rdt = 98 > Oct 30 17:35:03 cds1019 kernel: em0: Tx Queue Status = 0 > Oct 30 17:35:03 cds1019 kernel: em0: TX descriptors avail = 1024 > Oct 30 17:35:03 cds1019 kernel: em0: Tx Descriptors avail failure = 0 > Oct 30 17:35:03 cds1019 kernel: em0: RX discarded packets = 0 > Oct 30 17:35:03 cds1019 kernel: em0: RX Next to Check = 110 > Oct 30 17:35:03 cds1019 kernel: em0: RX Next to Refresh = 109 > Oct 30 17:35:03 cds1019 kernel: em0: Link state: active > Oct 30 17:35:03 cds1019 kernel: Interface is RUNNING and INACTIVE > Oct 30 17:35:03 cds1019 kernel: em1: hw tdh = 688, hw tdt = 688 > Oct 30 17:35:03 cds1019 kernel: em1: hw rdh = 861, hw rdt = 860 > Oct 30 17:35:03 cds1019 kernel: em1: Tx Queue Status = 1 > Oct 30 17:35:03 cds1019 kernel: em1: TX descriptors avail = 1024 > Oct 30 17:35:03 cds1019 kernel: em1: Tx Descriptors avail failure = 0 > Oct 30 17:35:03 cds1019 kernel: em1: RX discarded packets = 0 > Oct 30 17:35:03 cds1019 kernel: em1: RX Next to Check = 19 > Oct 30 17:35:03 cds1019 kernel: em1: RX Next to Refresh = 85 > Oct 30 17:35:03 cds1019 kernel: em1: Link state: active > > net.inet.ip.intr_queue_maxlen: 512 > net.inet.ip.intr_queue_drops: 0 > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 > dev.em.0.%driver: em > dev.em.0.%location: slot=0 function=0 > dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 subdevice=0x10d3 class=0x020000 > dev.em.0.%parent: pci1 > dev.em.0.nvm: -1 > dev.em.0.debug: -1 > dev.em.0.rx_int_delay: 0 > dev.em.0.tx_int_delay: 66 > dev.em.0.rx_abs_int_delay: 66 > dev.em.0.tx_abs_int_delay: 66 > dev.em.0.rx_processing_limit: 100 > dev.em.0.flow_control: 0 > dev.em.0.eee_control: 0 > dev.em.0.link_irq: 1 > dev.em.0.mbuf_alloc_fail: 0 > dev.em.0.cluster_alloc_fail: 0 > dev.em.0.dropped: 0 > dev.em.0.tx_dma_fail: 0 > dev.em.0.rx_overruns: 0 > dev.em.0.watchdog_timeouts: 0 > dev.em.0.device_control: 1074790984 > dev.em.0.rx_control: 67141634 > dev.em.0.fc_high_water: 18432 > dev.em.0.fc_low_water: 16932 > dev.em.0.queue0.txd_head: 818 > dev.em.0.queue0.txd_tail: 818 > dev.em.0.queue0.tx_irq: 1220810942 > dev.em.0.queue0.no_desc_avail: 0 > dev.em.0.queue0.rxd_head: 314 > dev.em.0.queue0.rxd_tail: 313 > dev.em.0.queue0.rx_irq: 24614539 > dev.em.0.mac_stats.excess_coll: 0 > dev.em.0.mac_stats.single_coll: 0 > dev.em.0.mac_stats.multiple_coll: 0 > dev.em.0.mac_stats.late_coll: 0 > dev.em.0.mac_stats.collision_count: 0 > dev.em.0.mac_stats.symbol_errors: 0 > dev.em.0.mac_stats.sequence_errors: 0 > dev.em.0.mac_stats.defer_count: 0 > dev.em.0.mac_stats.missed_packets: 0 > dev.em.0.mac_stats.recv_no_buff: 0 > dev.em.0.mac_stats.recv_undersize: 0 > dev.em.0.mac_stats.recv_fragmented: 0 > dev.em.0.mac_stats.recv_oversize: 0 > dev.em.0.mac_stats.recv_jabber: 0 > dev.em.0.mac_stats.recv_errs: 0 > dev.em.0.mac_stats.crc_errs: 0 > dev.em.0.mac_stats.alignment_errs: 0 > dev.em.0.mac_stats.coll_ext_errs: 0 > dev.em.0.mac_stats.xon_recvd: 0 > dev.em.0.mac_stats.xon_txd: 0 > dev.em.0.mac_stats.xoff_recvd: 0 > dev.em.0.mac_stats.xoff_txd: 0 > dev.em.0.mac_stats.total_pkts_recvd: 24955229 > dev.em.0.mac_stats.good_pkts_recvd: 24955229 > dev.em.0.mac_stats.bcast_pkts_recvd: 24945466 > dev.em.0.mac_stats.mcast_pkts_recvd: 1377 > dev.em.0.mac_stats.rx_frames_64: 24945502 > dev.em.0.mac_stats.rx_frames_65_127: 1606 > dev.em.0.mac_stats.rx_frames_128_255: 7963 > dev.em.0.mac_stats.rx_frames_256_511: 157 > dev.em.0.mac_stats.rx_frames_512_1023: 1 > dev.em.0.mac_stats.rx_frames_1024_1522: 0 > dev.em.0.mac_stats.good_octets_recvd: 1597800626 > dev.em.0.mac_stats.good_octets_txd: 7770925595880 > dev.em.0.mac_stats.total_pkts_txd: 5734191501 > dev.em.0.mac_stats.good_pkts_txd: 5734191501 > dev.em.0.mac_stats.bcast_pkts_txd: 4 > dev.em.0.mac_stats.mcast_pkts_txd: 1584 > dev.em.0.mac_stats.tx_frames_64: 25504167 > dev.em.0.mac_stats.tx_frames_65_127: 485744914 > dev.em.0.mac_stats.tx_frames_128_255: 5963478 > dev.em.0.mac_stats.tx_frames_256_511: 9021090 > dev.em.0.mac_stats.tx_frames_512_1023: 55803019 > dev.em.0.mac_stats.tx_frames_1024_1522: 5152154833 > dev.em.0.mac_stats.tso_txd: 0 > dev.em.0.mac_stats.tso_ctx_fail: 0 > dev.em.0.interrupts.asserts: 3 > dev.em.0.interrupts.rx_pkt_timer: 0 > dev.em.0.interrupts.rx_abs_timer: 0 > dev.em.0.interrupts.tx_pkt_timer: 0 > dev.em.0.interrupts.tx_abs_timer: 0 > dev.em.0.interrupts.tx_queue_empty: 0 > dev.em.0.interrupts.tx_queue_min_thresh: 0 > dev.em.0.interrupts.rx_desc_min_thresh: 0 > dev.em.0.interrupts.rx_overrun: 0 > dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 > dev.em.1.%driver: em > dev.em.1.%location: slot=0 function=0 > dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 subdevice=0x10d3 class=0x020000 > dev.em.1.%parent: pci2 > dev.em.1.nvm: -1 > dev.em.1.debug: -1 > dev.em.1.rx_int_delay: 0 > dev.em.1.tx_int_delay: 66 > dev.em.1.rx_abs_int_delay: 66 > dev.em.1.tx_abs_int_delay: 66 > dev.em.1.rx_processing_limit: 100 > dev.em.1.flow_control: 0 > dev.em.1.eee_control: 0 > dev.em.1.link_irq: 3272 > dev.em.1.mbuf_alloc_fail: 0 > dev.em.1.cluster_alloc_fail: 0 > dev.em.1.dropped: 0 > dev.em.1.tx_dma_fail: 0 > dev.em.1.rx_overruns: 0 > dev.em.1.watchdog_timeouts: 0 > dev.em.1.device_control: 1074790984 > dev.em.1.rx_control: 67141634 > dev.em.1.fc_high_water: 18432 > dev.em.1.fc_low_water: 16932 > dev.em.1.queue0.txd_head: 9 > dev.em.1.queue0.txd_tail: 14 > dev.em.1.queue0.tx_irq: 1194045687 > dev.em.1.queue0.no_desc_avail: 0 > dev.em.1.queue0.rxd_head: 317 > dev.em.1.queue0.rxd_tail: 315 > dev.em.1.queue0.rx_irq: 1528821076 > dev.em.1.mac_stats.excess_coll: 0 > dev.em.1.mac_stats.single_coll: 0 > dev.em.1.mac_stats.multiple_coll: 0 > dev.em.1.mac_stats.late_coll: 0 > dev.em.1.mac_stats.collision_count: 0 > dev.em.1.mac_stats.symbol_errors: 0 > dev.em.1.mac_stats.sequence_errors: 0 > dev.em.1.mac_stats.defer_count: 0 > dev.em.1.mac_stats.missed_packets: 15996 > dev.em.1.mac_stats.recv_no_buff: 1035 > dev.em.1.mac_stats.recv_undersize: 0 > dev.em.1.mac_stats.recv_fragmented: 0 > dev.em.1.mac_stats.recv_oversize: 0 > dev.em.1.mac_stats.recv_jabber: 0 > dev.em.1.mac_stats.recv_errs: 0 > dev.em.1.mac_stats.crc_errs: 0 > dev.em.1.mac_stats.alignment_errs: 0 > dev.em.1.mac_stats.coll_ext_errs: 0 > dev.em.1.mac_stats.xon_recvd: 0 > dev.em.1.mac_stats.xon_txd: 0 > dev.em.1.mac_stats.xoff_recvd: 0 > dev.em.1.mac_stats.xoff_txd: 0 > dev.em.1.mac_stats.total_pkts_recvd: 5220907923 > dev.em.1.mac_stats.good_pkts_recvd: 5220891927 > dev.em.1.mac_stats.bcast_pkts_recvd: 24943828 > dev.em.1.mac_stats.mcast_pkts_recvd: 1375 > dev.em.1.mac_stats.rx_frames_64: 1897964107 > dev.em.1.mac_stats.rx_frames_65_127: 2457591621 > dev.em.1.mac_stats.rx_frames_128_255: 5971619 > dev.em.1.mac_stats.rx_frames_256_511: 11235726 > dev.em.1.mac_stats.rx_frames_512_1023: 32267871 > dev.em.1.mac_stats.rx_frames_1024_1522: 815860983 > dev.em.1.mac_stats.good_octets_recvd: 1562681996232 > dev.em.1.mac_stats.good_octets_txd: 7334946827215 > dev.em.1.mac_stats.total_pkts_txd: 5430018684 > dev.em.1.mac_stats.good_pkts_txd: 5430018682 > dev.em.1.mac_stats.bcast_pkts_txd: 940 > dev.em.1.mac_stats.mcast_pkts_txd: 12 > dev.em.1.mac_stats.tx_frames_64: 24843579 > dev.em.1.mac_stats.tx_frames_65_127: 483343565 > dev.em.1.mac_stats.tx_frames_128_255: 5819327 > dev.em.1.mac_stats.tx_frames_256_511: 7998506 > dev.em.1.mac_stats.tx_frames_512_1023: 44787728 > dev.em.1.mac_stats.tx_frames_1024_1522: 4863225979 > dev.em.1.mac_stats.tso_txd: 0 > dev.em.1.mac_stats.tso_ctx_fail: 0 > dev.em.1.interrupts.asserts: 2398 > dev.em.1.interrupts.rx_pkt_timer: 1 > dev.em.1.interrupts.rx_abs_timer: 0 > dev.em.1.interrupts.tx_pkt_timer: 0 > dev.em.1.interrupts.tx_abs_timer: 0 > dev.em.1.interrupts.tx_queue_empty: 0 > dev.em.1.interrupts.tx_queue_min_thresh: 0 > dev.em.1.interrupts.rx_desc_min_thresh: 0 > dev.em.1.interrupts.rx_overrun: 2 > hw.em.eee_setting: 0 > hw.em.fc_setting: 0 > hw.em.rx_process_limit: 100 > hw.em.enable_msix: 1 > hw.em.sbp: 0 > hw.em.smart_pwr_down: 0 > hw.em.txd: 1024 > hw.em.rxd: 1024 > hw.em.rx_abs_int_delay: 66 > hw.em.tx_abs_int_delay: 66 > hw.em.rx_int_delay: 0 > hw.em.tx_int_delay: 66 > > Jason Jason Attached is a patch for if_em.c. It flushes interface queue when it is full and link is not active. Please note that when this happens, drops are increasing on interface and this will trigger your scripts as before. You need to change a little the scripts as follows: check interface TX status if (interface TX seems hung) { sleep 5 check interface TX status if (interface TX seems hung) { reset the interface. } } For MULTIQUEUE, it just disables the check for link status (which is not good). so pls. test in non-MULTIQUEUE mode. The patch also contains some minor fixups to compile on 7 plus a fix from r1.69 which addressed RX hang problem (the fix was later removed in r1.70). I included it for Emil to give it a try. Pls. let me know if you have any problems with patch. --------------040503030709030405090900 Content-Type: text/plain; name="if_em.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="if_em.c.patch" --- if_em.c.orig 2011-10-31 11:43:35.000000000 +0330 +++ if_em.c 2011-10-31 11:43:35.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 @@ -399,6 +411,12 @@ /* Global used in WOL setup with multiport cards */ static int global_quad_port_a = 0; +#ifndef DISABLE_FIXUPS +static int em_rx_hang_fixup = 0; +SYSCTL_INT(_hw_em, OID_AUTO, rx_hang_fixup, CTLFLAG_RW, &em_rx_hang_fixup, 0, + "Enable/disable r1.69 RX hang fixup code"); +#endif + /********************************************************************* * Device identification routine * @@ -411,7 +429,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 +886,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) { +#endif if (m != NULL) err = drbr_enqueue(ifp, txr->br, m); return (err); @@ -963,8 +989,17 @@ IFF_DRV_RUNNING) return; - if (!adapter->link_active) + if (!adapter->link_active) { +#ifndef DISABLE_FIXUPS + IF_LOCK(&ifp->if_snd); + if (_IF_QFULL(&ifp->if_snd)) { + ifp->if_snd.ifq_drops += _IF_QLEN(&ifp->if_snd); + _IF_DRAIN(&ifp->if_snd); + } + IF_UNLOCK(&ifp->if_snd); +#endif return; + } while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { /* Call cleanup if number of TX descriptors low */ @@ -1414,7 +1449,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 +1465,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 +1495,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 */ @@ -2213,6 +2259,16 @@ e1000_get_laa_state_82571(&adapter->hw)) e1000_rar_set(&adapter->hw, adapter->hw.mac.addr, 0); +#ifndef DISABLE_FIXUPS + if (em_rx_hang_fixup) { + /* trigger tq to refill rx ring queue if it is empty */ + for (int i = 0; i < adapter->num_queues; i++, rxr++) { + if (rxr->next_to_check == rxr->next_to_refresh) { + taskqueue_enqueue(rxr->tq, &rxr->rx_task); + } + } + } +#endif /* Mask to use in the irq trigger */ if (adapter->msix_mem) trigger = rxr->ims; /* RX for 82574 */ @@ -2311,6 +2367,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 +2379,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 +3828,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 +5193,12 @@ 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"); +#endif + SYSCTL_ADD_PROC(ctx, child, OID_AUTO, "device_control", CTLTYPE_UINT | CTLFLAG_RD, adapter, E1000_CTRL, em_sysctl_reg_handler, "IU", @@ -5553,4 +5620,8 @@ 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 } --------------040503030709030405090900 Content-Type: text/plain; name="if_em.h.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="if_em.h.patch" --- if_em.h.orig 2011-10-31 11:43:34.000000000 +0330 +++ if_em.h 2011-10-31 11:43:35.000000000 +0330 @@ -438,7 +438,9 @@ unsigned long rx_overruns; unsigned long watchdog_events; unsigned long link_irq; - +#ifndef DISABLE_FIXUPS + unsigned long link_toggles; +#endif struct e1000_hw_stats stats; }; --------------040503030709030405090900-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 31 08:14:47 2011 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 8737B106564A for ; Mon, 31 Oct 2011 08:14:47 +0000 (UTC) (envelope-from gpm@hotplug.ru) Received: from gate.pikinvest.ru (gate.pikinvest.ru [87.245.155.170]) by mx1.freebsd.org (Postfix) with ESMTP id E425A8FC16 for ; Mon, 31 Oct 2011 08:14:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailgate.pik.ru (Postfix) with ESMTP id DDB301C085B; Mon, 31 Oct 2011 11:14:43 +0300 (MSK) Received: from EX03PIK.PICompany.ru (unknown [192.168.156.51]) by mailgate.pik.ru (Postfix) with ESMTP id CB2481C083B; Mon, 31 Oct 2011 11:14:43 +0300 (MSK) Received: from EX21PIK.PICompany.ru ([192.168.156.131]) by EX03PIK.PICompany.ru with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 12:14:08 +0400 Received: from [192.168.148.9] (192.168.148.9) by EX21PIK.PICompany.ru (192.168.156.131) with Microsoft SMTP Server id 14.1.218.12; Mon, 31 Oct 2011 12:14:07 +0400 Message-ID: <4EAE58BC.2090000@hotplug.ru> Date: Mon, 31 Oct 2011 12:13:48 +0400 From: Emil Muratov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: Hooman Fazaeli References: <4E8F157A.40702@sentex.net> <4E8F51D4.1060509@sentex.net> <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> In-Reply-To: <4EA91836.2040508@gmail.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2011 08:14:08.0338 (UTC) FILETIME=[10285B20:01CC97A5] Cc: freebsd-net@freebsd.org, Jack Vogel , Jason Wolfe Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 31 Oct 2011 08:14:47 -0000 > > You may try these settings and see if they help: > > - hw.em.fc_setting=0 (in /boot/loader.conf) > - hw.em.rxd="4096" (in /boot/loader.conf) > - hw.em.txd="4096" (in /boot/loader.conf) > - Fix speed and duplex at both link sides. After doing that, confirm > on the freebsd > box (with ifconfig) and the other device (with whatever command it > provides) that > the same speed and duplex is used by both devices. > > you also have high values for dev.em.0.rx/tx_[abs]_int_delay. If you > have set them manually, remove them or replace them with these in > loader.conf: > > hw.em.rx_int_delay=0 > hw.em.tx_int_delay=66 > hw.em.tx_abs_int_delay=66 > hw.em.rx_abs_int_delay=66 > > these may be set via corresponding sysctls too. > Still no luck with the above settings, I've got another lockups a couple of times. Here is the recent details ================================= 11.10.30-23:43:06 ... interface em0 is down... we have Ierrs and no ingoing packets for 5 secs, interface em0 must be toggled 11:43PM up 1 day, 3:01, 2 users, load averages: 0.76, 0.64, 0.70 == vmstat -i == interrupt total rate irq18: ehci0 1145540 11 irq22: nfe0 473895599 4872 cpu0: timer 195004026 2005 irq256: ahci0 12832958 131 irq257: em0:rx 0 95571051 982 irq258: em0:tx 0 88777545 912 irq259: em0:link 946 0 cpu3: timer 195003397 2005 cpu1: timer 195003398 2005 cpu2: timer 195003399 2005 Total 1452237859 14932 == netstat -m == 5424/1701/7125 mbufs in use (current/cache/total) 719/1185/1904/51200 mbuf clusters in use (current/cache/total/max) 719/582 mbuf+clusters out of packet secondary zone in use (current/cache) 329/583/912/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 4095/342/4437/12800 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 40978K/8205K/49183K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/6663503/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 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines == netstat -ind == Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 nfe0 1500 00:25:22:21:86:89 196018201 0 0 350650768 0 0 664 nfe0 1500 fe80::225:22f fe80::225:22ff:fe 0 - - 0 - - - nfe0 1500 10.16.128.0/1 10.16.189.71 6 - - 29787707 - - - em0 9000 00:1b:21:ab:bf:4a 175676617 949 0 101627139 0 0 0 em0 9000 192.168.168.0 192.168.168.1 7628423 - - 13654747 - - - em0 9000 fe80::21b:21f fe80::21b:21ff:fe 45 - - 5747 - - - em0 9000 2002:d5xx:xxx 2002:d5xx:xxxx:x: 153 - - 159 - - - Oct 30 23:43:06 ion kernel: Interface is RUNNING and INACTIVE Oct 30 23:43:07 ion kernel: em0: hw tdh = 2656, hw tdt = 3271 Oct 30 23:43:07 ion kernel: em0: hw rdh = 2112, hw rdt = 2111 Oct 30 23:43:07 ion kernel: em0: Tx Queue Status = 1 Oct 30 23:43:07 ion kernel: em0: TX descriptors avail = 3481 Oct 30 23:43:07 ion kernel: em0: Tx Descriptors avail failure = 0 Oct 30 23:43:07 ion kernel: em0: RX discarded packets = 0 Oct 30 23:43:07 ion kernel: em0: RX Next to Check = 2112 Oct 30 23:43:07 ion kernel: em0: RX Next to Refresh = 2111 net.inet.ip.intr_queue_maxlen: 4096 net.inet.ip.intr_queue_drops: 0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 subdevice=0xa01f class=0x020000 dev.em.0.%parent: pci2 dev.em.0.nvm: -1 dev.em.0.debug: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.0.flow_control: 0 dev.em.0.eee_control: 0 dev.em.0.link_irq: 956 dev.em.0.mbuf_alloc_fail: 0 dev.em.0.cluster_alloc_fail: 0 dev.em.0.dropped: 0 dev.em.0.tx_dma_fail: 1 dev.em.0.rx_overruns: 0 dev.em.0.watchdog_timeouts: 0 dev.em.0.device_control: 1074790984 dev.em.0.rx_control: 100827170 dev.em.0.fc_high_water: 11264 dev.em.0.fc_low_water: 9764 dev.em.0.queue0.txd_head: 2656 dev.em.0.queue0.txd_tail: 3274 dev.em.0.queue0.tx_irq: 88769608 dev.em.0.queue0.no_desc_avail: 0 dev.em.0.queue0.rxd_head: 2112 dev.em.0.queue0.rxd_tail: 2111 dev.em.0.queue0.rx_irq: 95554873 dev.em.0.mac_stats.excess_coll: 0 dev.em.0.mac_stats.single_coll: 0 dev.em.0.mac_stats.multiple_coll: 0 dev.em.0.mac_stats.late_coll: 0 dev.em.0.mac_stats.collision_count: 0 dev.em.0.mac_stats.symbol_errors: 0 dev.em.0.mac_stats.sequence_errors: 0 dev.em.0.mac_stats.defer_count: 0 dev.em.0.mac_stats.missed_packets: 959 dev.em.0.mac_stats.recv_no_buff: 0 dev.em.0.mac_stats.recv_undersize: 0 dev.em.0.mac_stats.recv_fragmented: 0 dev.em.0.mac_stats.recv_oversize: 0 dev.em.0.mac_stats.recv_jabber: 0 dev.em.0.mac_stats.recv_errs: 0 dev.em.0.mac_stats.crc_errs: 0 dev.em.0.mac_stats.alignment_errs: 0 dev.em.0.mac_stats.coll_ext_errs: 0 dev.em.0.mac_stats.xon_recvd: 0 dev.em.0.mac_stats.xon_txd: 0 dev.em.0.mac_stats.xoff_recvd: 0 dev.em.0.mac_stats.xoff_txd: 0 dev.em.0.mac_stats.total_pkts_recvd: 175670049 dev.em.0.mac_stats.good_pkts_recvd: 175669090 dev.em.0.mac_stats.bcast_pkts_recvd: 2928 dev.em.0.mac_stats.mcast_pkts_recvd: 1082 dev.em.0.mac_stats.rx_frames_64: 4539426 dev.em.0.mac_stats.rx_frames_65_127: 10242159 dev.em.0.mac_stats.rx_frames_128_255: 576238 dev.em.0.mac_stats.rx_frames_256_511: 372297 dev.em.0.mac_stats.rx_frames_512_1023: 2208708 dev.em.0.mac_stats.rx_frames_1024_1522: 157730262 dev.em.0.mac_stats.good_octets_recvd: 238712986216 dev.em.0.mac_stats.good_octets_txd: 40512955499 dev.em.0.mac_stats.total_pkts_txd: 108590895 dev.em.0.mac_stats.good_pkts_txd: 108590895 dev.em.0.mac_stats.bcast_pkts_txd: 4604 dev.em.0.mac_stats.mcast_pkts_txd: 13969 dev.em.0.mac_stats.tx_frames_64: 13905445 dev.em.0.mac_stats.tx_frames_65_127: 69702633 dev.em.0.mac_stats.tx_frames_128_255: 1442225 dev.em.0.mac_stats.tx_frames_256_511: 755348 dev.em.0.mac_stats.tx_frames_512_1023: 375982 dev.em.0.mac_stats.tx_frames_1024_1522: 22409262 dev.em.0.mac_stats.tso_txd: 4695644 dev.em.0.mac_stats.tso_ctx_fail: 0 dev.em.0.interrupts.asserts: 36 dev.em.0.interrupts.rx_pkt_timer: 0 dev.em.0.interrupts.rx_abs_timer: 0 dev.em.0.interrupts.tx_pkt_timer: 0 dev.em.0.interrupts.tx_abs_timer: 0 dev.em.0.interrupts.tx_queue_empty: 0 dev.em.0.interrupts.tx_queue_min_thresh: 0 dev.em.0.interrupts.rx_desc_min_thresh: 0 dev.em.0.interrupts.rx_overrun: 0 == ifconfig em0 == em0: flags=8843 metric 0 mtu 9000 description: LAN options=219b ether 00:1b:21:ab:bf:4a inet 192.168.168.1 netmask 0xffffffc0 broadcast 192.168.168.63 inet6 fe80::21b:21ff:feab:bf4a%em0 prefixlen 64 scopeid 0x4 inet6 2002:d5xx:xxxx:1::1 prefixlen 64 nd6 options=1 media: Ethernet 1000baseT (1000baseT ) status: active From owner-freebsd-net@FreeBSD.ORG Mon Oct 31 09:04:38 2011 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 1D4B91065670 for ; Mon, 31 Oct 2011 09:04:38 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 920778FC17 for ; Mon, 31 Oct 2011 09:04:37 +0000 (UTC) Received: by wyh11 with SMTP id 11so1673351wyh.13 for ; Mon, 31 Oct 2011 02:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=NdRBb+dykEjzsMXYXZOJiWijPBi2auWqK5sAAULZieQ=; b=xyP85D2qlRnXcBk6zLtLRZ+m9sfJj638Cug0rwkHBkbQ5LJ7TgFOqHXRFYfashBvKa LATZk9WG8LnO+k4ZwzHW6+P9/ZCLDgym9lJaA6H6pHwJi91f5+J4xmdPZYJ2cKlQ1Vl/ ybRO95RXW6Xc8lb1yDhxekOsV+hYHyzGdTIBw= Received: by 10.227.208.77 with SMTP id gb13mr18619772wbb.4.1320051876158; Mon, 31 Oct 2011 02:04:36 -0700 (PDT) Received: from [127.0.0.1] ([84.241.57.181]) by mx.google.com with ESMTPS id fw16sm31189018wbb.13.2011.10.31.02.04.30 (version=SSLv3 cipher=OTHER); Mon, 31 Oct 2011 02:04:35 -0700 (PDT) Message-ID: <4EAE649C.6040106@gmail.com> Date: Mon, 31 Oct 2011 12:34:28 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Emil Muratov References: <4E8F157A.40702@sentex.net> <4E8F51D4.1060509@sentex.net> <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EAE58BC.2090000@hotplug.ru> In-Reply-To: <4EAE58BC.2090000@hotplug.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Jack Vogel , Jason Wolfe Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 31 Oct 2011 09:04:38 -0000 On 10/31/2011 11:43 AM, Emil Muratov wrote: > >> >> You may try these settings and see if they help: >> >> - hw.em.fc_setting=0 (in /boot/loader.conf) >> - hw.em.rxd="4096" (in /boot/loader.conf) >> - hw.em.txd="4096" (in /boot/loader.conf) >> - Fix speed and duplex at both link sides. After doing that, confirm on the freebsd >> box (with ifconfig) and the other device (with whatever command it provides) that >> the same speed and duplex is used by both devices. >> >> you also have high values for dev.em.0.rx/tx_[abs]_int_delay. If you >> have set them manually, remove them or replace them with these in loader.conf: >> >> hw.em.rx_int_delay=0 >> hw.em.tx_int_delay=66 >> hw.em.tx_abs_int_delay=66 >> hw.em.rx_abs_int_delay=66 >> >> these may be set via corresponding sysctls too. >> > > Still no luck with the above settings, I've got another lockups a couple of times. Here is the recent details > > > ================================= > 11.10.30-23:43:06 ... interface em0 is down... > we have Ierrs and no ingoing packets for 5 secs, interface em0 must be toggled > > 11:43PM up 1 day, 3:01, 2 users, load averages: 0.76, 0.64, 0.70 > > == vmstat -i == > interrupt total rate > irq18: ehci0 1145540 11 > irq22: nfe0 473895599 4872 > cpu0: timer 195004026 2005 > irq256: ahci0 12832958 131 > irq257: em0:rx 0 95571051 982 > irq258: em0:tx 0 88777545 912 > irq259: em0:link 946 0 > cpu3: timer 195003397 2005 > cpu1: timer 195003398 2005 > cpu2: timer 195003399 2005 > Total 1452237859 14932 > > == netstat -m == > 5424/1701/7125 mbufs in use (current/cache/total) > 719/1185/1904/51200 mbuf clusters in use (current/cache/total/max) > 719/582 mbuf+clusters out of packet secondary zone in use (current/cache) > 329/583/912/12800 4k (page size) jumbo clusters in use (current/cache/total/max) > 4095/342/4437/12800 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 40978K/8205K/49183K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/6663503/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 > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > == netstat -ind == > Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop > usbus 0 0 0 0 0 0 0 0 > usbus 0 0 0 0 0 0 0 0 > nfe0 1500 00:25:22:21:86:89 196018201 0 0 350650768 0 0 664 > nfe0 1500 fe80::225:22f fe80::225:22ff:fe 0 - - 0 - - - > nfe0 1500 10.16.128.0/1 10.16.189.71 6 - - 29787707 - - - > em0 9000 00:1b:21:ab:bf:4a 175676617 949 0 101627139 0 0 0 > em0 9000 192.168.168.0 192.168.168.1 7628423 - - 13654747 - - - > em0 9000 fe80::21b:21f fe80::21b:21ff:fe 45 - - 5747 - - - > em0 9000 2002:d5xx:xxx 2002:d5xx:xxxx:x: 153 - - 159 - - - > > Oct 30 23:43:06 ion kernel: Interface is RUNNING and INACTIVE > Oct 30 23:43:07 ion kernel: em0: hw tdh = 2656, hw tdt = 3271 > Oct 30 23:43:07 ion kernel: em0: hw rdh = 2112, hw rdt = 2111 > Oct 30 23:43:07 ion kernel: em0: Tx Queue Status = 1 > Oct 30 23:43:07 ion kernel: em0: TX descriptors avail = 3481 > Oct 30 23:43:07 ion kernel: em0: Tx Descriptors avail failure = 0 > Oct 30 23:43:07 ion kernel: em0: RX discarded packets = 0 > Oct 30 23:43:07 ion kernel: em0: RX Next to Check = 2112 > Oct 30 23:43:07 ion kernel: em0: RX Next to Refresh = 2111 > net.inet.ip.intr_queue_maxlen: 4096 > net.inet.ip.intr_queue_drops: 0 > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 > dev.em.0.%driver: em > dev.em.0.%location: slot=0 function=0 > dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 subdevice=0xa01f class=0x020000 > dev.em.0.%parent: pci2 > dev.em.0.nvm: -1 > dev.em.0.debug: -1 > dev.em.0.rx_int_delay: 0 > dev.em.0.tx_int_delay: 66 > dev.em.0.rx_abs_int_delay: 66 > dev.em.0.tx_abs_int_delay: 66 > dev.em.0.rx_processing_limit: 100 > dev.em.0.flow_control: 0 > dev.em.0.eee_control: 0 > dev.em.0.link_irq: 956 > dev.em.0.mbuf_alloc_fail: 0 > dev.em.0.cluster_alloc_fail: 0 > dev.em.0.dropped: 0 > dev.em.0.tx_dma_fail: 1 > dev.em.0.rx_overruns: 0 > dev.em.0.watchdog_timeouts: 0 > dev.em.0.device_control: 1074790984 > dev.em.0.rx_control: 100827170 > dev.em.0.fc_high_water: 11264 > dev.em.0.fc_low_water: 9764 > dev.em.0.queue0.txd_head: 2656 > dev.em.0.queue0.txd_tail: 3274 > dev.em.0.queue0.tx_irq: 88769608 > dev.em.0.queue0.no_desc_avail: 0 > dev.em.0.queue0.rxd_head: 2112 > dev.em.0.queue0.rxd_tail: 2111 > dev.em.0.queue0.rx_irq: 95554873 > dev.em.0.mac_stats.excess_coll: 0 > dev.em.0.mac_stats.single_coll: 0 > dev.em.0.mac_stats.multiple_coll: 0 > dev.em.0.mac_stats.late_coll: 0 > dev.em.0.mac_stats.collision_count: 0 > dev.em.0.mac_stats.symbol_errors: 0 > dev.em.0.mac_stats.sequence_errors: 0 > dev.em.0.mac_stats.defer_count: 0 > dev.em.0.mac_stats.missed_packets: 959 > dev.em.0.mac_stats.recv_no_buff: 0 > dev.em.0.mac_stats.recv_undersize: 0 > dev.em.0.mac_stats.recv_fragmented: 0 > dev.em.0.mac_stats.recv_oversize: 0 > dev.em.0.mac_stats.recv_jabber: 0 > dev.em.0.mac_stats.recv_errs: 0 > dev.em.0.mac_stats.crc_errs: 0 > dev.em.0.mac_stats.alignment_errs: 0 > dev.em.0.mac_stats.coll_ext_errs: 0 > dev.em.0.mac_stats.xon_recvd: 0 > dev.em.0.mac_stats.xon_txd: 0 > dev.em.0.mac_stats.xoff_recvd: 0 > dev.em.0.mac_stats.xoff_txd: 0 > dev.em.0.mac_stats.total_pkts_recvd: 175670049 > dev.em.0.mac_stats.good_pkts_recvd: 175669090 > dev.em.0.mac_stats.bcast_pkts_recvd: 2928 > dev.em.0.mac_stats.mcast_pkts_recvd: 1082 > dev.em.0.mac_stats.rx_frames_64: 4539426 > dev.em.0.mac_stats.rx_frames_65_127: 10242159 > dev.em.0.mac_stats.rx_frames_128_255: 576238 > dev.em.0.mac_stats.rx_frames_256_511: 372297 > dev.em.0.mac_stats.rx_frames_512_1023: 2208708 > dev.em.0.mac_stats.rx_frames_1024_1522: 157730262 > dev.em.0.mac_stats.good_octets_recvd: 238712986216 > dev.em.0.mac_stats.good_octets_txd: 40512955499 > dev.em.0.mac_stats.total_pkts_txd: 108590895 > dev.em.0.mac_stats.good_pkts_txd: 108590895 > dev.em.0.mac_stats.bcast_pkts_txd: 4604 > dev.em.0.mac_stats.mcast_pkts_txd: 13969 > dev.em.0.mac_stats.tx_frames_64: 13905445 > dev.em.0.mac_stats.tx_frames_65_127: 69702633 > dev.em.0.mac_stats.tx_frames_128_255: 1442225 > dev.em.0.mac_stats.tx_frames_256_511: 755348 > dev.em.0.mac_stats.tx_frames_512_1023: 375982 > dev.em.0.mac_stats.tx_frames_1024_1522: 22409262 > dev.em.0.mac_stats.tso_txd: 4695644 > dev.em.0.mac_stats.tso_ctx_fail: 0 > dev.em.0.interrupts.asserts: 36 > dev.em.0.interrupts.rx_pkt_timer: 0 > dev.em.0.interrupts.rx_abs_timer: 0 > dev.em.0.interrupts.tx_pkt_timer: 0 > dev.em.0.interrupts.tx_abs_timer: 0 > dev.em.0.interrupts.tx_queue_empty: 0 > dev.em.0.interrupts.tx_queue_min_thresh: 0 > dev.em.0.interrupts.rx_desc_min_thresh: 0 > dev.em.0.interrupts.rx_overrun: 0 > > == ifconfig em0 == > > em0: flags=8843 metric 0 mtu 9000 > description: LAN > options=219b > ether 00:1b:21:ab:bf:4a > inet 192.168.168.1 netmask 0xffffffc0 broadcast 192.168.168.63 > inet6 fe80::21b:21ff:feab:bf4a%em0 prefixlen 64 scopeid 0x4 > inet6 2002:d5xx:xxxx:1::1 prefixlen 64 > nd6 options=1 > media: Ethernet 1000baseT (1000baseT ) > status: active > > > > > The patch I prepared for Jason contains a possible fix for your problem (Cc'ed). Can you give it a try? Before that, and to rule out other possibilities, you may disable MSIX and see if it helps: hw.em.enable_msix="0" (in /boot/loader.conf) From owner-freebsd-net@FreeBSD.ORG Mon Oct 31 09:23:09 2011 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 347C31065693 for ; Mon, 31 Oct 2011 09:23:09 +0000 (UTC) (envelope-from gpm@hotplug.ru) Received: from gate.pikinvest.ru (gate.pikinvest.ru [87.245.155.170]) by mx1.freebsd.org (Postfix) with ESMTP id C19D28FC0C for ; Mon, 31 Oct 2011 09:23:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailgate.pik.ru (Postfix) with ESMTP id 4A6651C086C; Mon, 31 Oct 2011 12:23:07 +0300 (MSK) Received: from EX03PIK.PICompany.ru (unknown [192.168.156.51]) by mailgate.pik.ru (Postfix) with ESMTP id 47C661C085F; Mon, 31 Oct 2011 12:23:07 +0300 (MSK) Received: from EX21PIK.PICompany.ru ([192.168.156.131]) by EX03PIK.PICompany.ru with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 13:22:19 +0400 Received: from [192.168.148.9] (192.168.148.9) by EX21PIK.PICompany.ru (192.168.156.131) with Microsoft SMTP Server id 14.1.218.12; Mon, 31 Oct 2011 13:22:18 +0400 Message-ID: <4EAE68B7.5030000@hotplug.ru> Date: Mon, 31 Oct 2011 13:21:59 +0400 From: Emil Muratov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: Hooman Fazaeli References: <4E8F157A.40702@sentex.net> <4E8F51D4.1060509@sentex.net> <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> <4EAE58A2.9040803@gmail.com> In-Reply-To: <4EAE58A2.9040803@gmail.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2011 09:22:19.0244 (UTC) FILETIME=[968712C0:01CC97AE] Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Jack Vogel , Jason Wolfe Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 31 Oct 2011 09:23:09 -0000 On 31.10.2011 12:13, Hooman Fazaeli wrote: > >> >> >> Thanks for looking into this. I'd be happy to test any patch thrown >> my way, but keep in mind my issue is only tickled when MSI-X is >> enabled. My interfaces aren't bouncing, though it might be possible >> some unique path in the MSI-X code is causing a throughput hang akin >> to connectivity loss? >> >> Jack is the delta your speaking to the 7.2.4 code? I did manage to >> get the code from Intel compiled with a couple minutes of work, but >> haven't loaded it up yet as I didn't see anything that caught my >> untrained eye in the diffs. I'll wait until its ported over and >> would be happy to test if needed. >> >> Conveniently enough I just received another report from my test boxes >> with a pretty stock loader.conf. I had forgotten to remove the >> advanced options from the interfaces after I cycled them to pick up >> the fc_setting=0. Fixed that up just meow. >> >> hw.em.fc_setting="0" >> cc_cubic_load="YES" >> >> > > Jason > > Attached is a patch for if_em.c. It flushes interface queue when it is > full > and link is not active. Please note that when this happens, drops are > increasing > on interface and this will trigger your scripts as before. You need to > change > a little the scripts as follows: > > check interface TX status > if (interface TX seems hung) { > sleep 5 > check interface TX status > if (interface TX seems hung) { > reset the interface. > } > } > > For MULTIQUEUE, it just disables the check for link status (which is > not good). > so pls. test in non-MULTIQUEUE mode. > > The patch also contains some minor fixups to compile on 7 plus > a fix from r1.69 which addressed RX hang problem (the fix was > later removed in r1.70). I included it for Emil to give it a > try. > > Pls. let me know if you have any problems with patch. > > > Hi! Thanks for the update. But I can't make it, there is an error in build process. Can you kindly take a look at it? -emil@ion-/usr/src/sys/dev/e1000 --(0)> sudo patch < /home/emil/patches/if_em/if_em.c.patch Password: Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- if_em.c.orig 2011-10-31 11:43:35.000000000 +0330 |+++ if_em.c 2011-10-31 11:43:35.000000000 +0330 -------------------------- Patching file if_em.c using Plan A... Hunk #1 succeeded at 85. Hunk #2 succeeded at 101. Hunk #3 succeeded at 382 (offset -29 lines). Hunk #4 succeeded at 400 (offset -29 lines). Hunk #5 succeeded at 857 (offset -29 lines). Hunk #6 succeeded at 960 (offset -29 lines). Hunk #7 succeeded at 1420 (offset -29 lines). Hunk #8 succeeded at 1436 (offset -29 lines). Hunk #9 succeeded at 1466 (offset -29 lines). Hunk #10 succeeded at 2230 (offset -29 lines). Hunk #11 succeeded at 2338 (offset -29 lines). Hunk #12 succeeded at 2350 (offset -29 lines). Hunk #13 succeeded at 3799 (offset -29 lines). Hunk #14 succeeded at 5164 with fuzz 2 (offset -29 lines). Hunk #15 succeeded at 5616 (offset -4 lines). done -emil@ion-/usr/src/sys/dev/e1000 --(0)> sudo patch < /home/emil/patches/if_em/if_em.h.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- if_em.h.orig 2011-10-31 11:43:34.000000000 +0330 |+++ if_em.h 2011-10-31 11:43:35.000000000 +0330 -------------------------- Patching file if_em.h using Plan A... Hunk #1 succeeded at 438. done #root@ion-/usr/src/sys/modules/em #-(0)> make Warning: Object directory not changed from original /usr/src/sys/modules/em awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h :> opt_inet.h cc -O2 -pipe -march=nocona -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/usr/src/sys/modules/em/../../dev/e1000 -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables - ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing- prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/em/../../dev/e1000/if _em.c /usr/src/sys/modules/em/../../dev/e1000/if_em.c:387: error: 'sysctl__hw_em_children' undeclared here (not in a function) *** Error code 1 Stop in /usr/src/sys/modules/em. From owner-freebsd-net@FreeBSD.ORG Mon Oct 31 09:44:19 2011 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 00986106564A for ; Mon, 31 Oct 2011 09:44:19 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 73D248FC0C for ; Mon, 31 Oct 2011 09:44:18 +0000 (UTC) Received: by bkbzs2 with SMTP id zs2so3161688bkb.13 for ; Mon, 31 Oct 2011 02:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=Z8FUXpJfIjVMqsp7sBPzYfx/ynV2sXSjr4f30qftT5M=; b=i3iCcqS7HxlYEJa81ASLYjsULa8FczPAw69lHTBrMbcKhGQKhxxyDH5QktlnUNIvDx YocNzf0mCyTPkoecU9ONGwstMHAG81Io0ihRUGNplT/OdiYO2UJHX7zRSAV7umHSutT1 e4khbzmdI3dmjNuur3fGi0Hr3PF4vclIOxOzo= Received: by 10.204.132.211 with SMTP id c19mr4190366bkt.94.1320054257215; Mon, 31 Oct 2011 02:44:17 -0700 (PDT) Received: from [127.0.0.1] ([84.241.57.181]) by mx.google.com with ESMTPS id e14sm16480417bka.0.2011.10.31.02.44.14 (version=SSLv3 cipher=OTHER); Mon, 31 Oct 2011 02:44:16 -0700 (PDT) Message-ID: <4EAE6DEA.7040701@gmail.com> Date: Mon, 31 Oct 2011 13:14:10 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Emil Muratov References: <4E8F157A.40702@sentex.net> <4E8F51D4.1060509@sentex.net> <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> <4EAE58A2.9040803@gmail.com> <4EAE68B7.5030000@hotplug.ru> In-Reply-To: <4EAE68B7.5030000@hotplug.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Jack Vogel , Jason Wolfe Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 31 Oct 2011 09:44:19 -0000 On 10/31/2011 12:51 PM, Emil Muratov wrote: > On 31.10.2011 12:13, Hooman Fazaeli wrote: >> >>> >>> >>> Thanks for looking into this. I'd be happy to test any patch thrown my way, but keep in mind my issue is only tickled when MSI-X is enabled. My interfaces aren't bouncing, though it might be >>> possible some unique path in the MSI-X code is causing a throughput hang akin to connectivity loss? >>> >>> Jack is the delta your speaking to the 7.2.4 code? I did manage to get the code from Intel compiled with a couple minutes of work, but haven't loaded it up yet as I didn't see anything that >>> caught my untrained eye in the diffs. I'll wait until its ported over and would be happy to test if needed. >>> >>> Conveniently enough I just received another report from my test boxes with a pretty stock loader.conf. I had forgotten to remove the advanced options from the interfaces after I cycled them to >>> pick up the fc_setting=0. Fixed that up just meow. >>> >>> hw.em.fc_setting="0" >>> cc_cubic_load="YES" >>> >>> >> >> Jason >> >> Attached is a patch for if_em.c. It flushes interface queue when it is full >> and link is not active. Please note that when this happens, drops are increasing >> on interface and this will trigger your scripts as before. You need to change >> a little the scripts as follows: >> >> check interface TX status >> if (interface TX seems hung) { >> sleep 5 >> check interface TX status >> if (interface TX seems hung) { >> reset the interface. >> } >> } >> >> For MULTIQUEUE, it just disables the check for link status (which is not good). >> so pls. test in non-MULTIQUEUE mode. >> >> The patch also contains some minor fixups to compile on 7 plus >> a fix from r1.69 which addressed RX hang problem (the fix was >> later removed in r1.70). I included it for Emil to give it a >> try. >> >> Pls. let me know if you have any problems with patch. >> >> >> > > Hi! Thanks for the update. But I can't make it, there is an error in build process. Can you kindly take a look at it? > > > -emil@ion-/usr/src/sys/dev/e1000 > --(0)> sudo patch < /home/emil/patches/if_em/if_em.c.patch > Password: > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |--- if_em.c.orig 2011-10-31 11:43:35.000000000 +0330 > |+++ if_em.c 2011-10-31 11:43:35.000000000 +0330 > -------------------------- > Patching file if_em.c using Plan A... > Hunk #1 succeeded at 85. > Hunk #2 succeeded at 101. > Hunk #3 succeeded at 382 (offset -29 lines). > Hunk #4 succeeded at 400 (offset -29 lines). > Hunk #5 succeeded at 857 (offset -29 lines). > Hunk #6 succeeded at 960 (offset -29 lines). > Hunk #7 succeeded at 1420 (offset -29 lines). > Hunk #8 succeeded at 1436 (offset -29 lines). > Hunk #9 succeeded at 1466 (offset -29 lines). > Hunk #10 succeeded at 2230 (offset -29 lines). > Hunk #11 succeeded at 2338 (offset -29 lines). > Hunk #12 succeeded at 2350 (offset -29 lines). > Hunk #13 succeeded at 3799 (offset -29 lines). > Hunk #14 succeeded at 5164 with fuzz 2 (offset -29 lines). > Hunk #15 succeeded at 5616 (offset -4 lines). > done > > -emil@ion-/usr/src/sys/dev/e1000 > --(0)> sudo patch < /home/emil/patches/if_em/if_em.h.patch > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |--- if_em.h.orig 2011-10-31 11:43:34.000000000 +0330 > |+++ if_em.h 2011-10-31 11:43:35.000000000 +0330 > -------------------------- > Patching file if_em.h using Plan A... > Hunk #1 succeeded at 438. > done > > > #root@ion-/usr/src/sys/modules/em > #-(0)> make > Warning: Object directory not changed from original /usr/src/sys/modules/em > awk -f @/tools/makeobjops.awk @/kern/device_if.m -h > awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h > awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h > :> opt_inet.h > cc -O2 -pipe -march=nocona -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/usr/src/sys/modules/em/../../dev/e1000 -I. -I@ -I@/contrib/altq > -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 > -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables - ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing- prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c > /usr/src/sys/modules/em/../../dev/e1000/if _em.c > /usr/src/sys/modules/em/../../dev/e1000/if_em.c:387: error: 'sysctl__hw_em_children' undeclared here (not in a function) > *** Error code 1 > > Stop in /usr/src/sys/modules/em. > > > > Please sync your sys/dev/e1000 with HEAD and try again: setenv CVSROOT :pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs cvs login password: cd /usr/src cvs co -rHEAD sys/dev/e1000 From owner-freebsd-net@FreeBSD.ORG Mon Oct 31 11:07:08 2011 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 B1CC410657CD for ; Mon, 31 Oct 2011 11:07:08 +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 A05D38FC25 for ; Mon, 31 Oct 2011 11:07:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9VB78lj056820 for ; Mon, 31 Oct 2011 11:07:08 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9VB78bX056818 for freebsd-net@FreeBSD.org; Mon, 31 Oct 2011 11:07:08 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 31 Oct 2011 11:07:08 GMT Message-Id: <201110311107.p9VB78bX056818@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, 31 Oct 2011 11:07:08 -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/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/161908 net [netgraph] [patch] ng_vlan update for QinQ support o kern/161899 net [route] ntpd(8): Repeating RTM_MISS packets causing hi 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/155604 net [flowtable] Flowtable excessively caches dest MAC addr o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155585 net [tcp] [panic] tcp_output tcp_mtudisc loop until kernel o kern/155420 net [vlan] adding vlan break existent vlan o bin/155365 net [patch] routed(8): if.c in routed fails to compile if 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/155004 net [bce] [panic] kernel panic in bce0 driver 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 bin/145934 net [patch] add count option to netstat(1) 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 o kern/144572 net [carp] CARP preemption mode traffic partially goes to 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 bin/136661 net [patch] ndp(8) ignores -f option 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 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node 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 o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 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 382 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 31 08:58:33 2011 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 3CDD3106564A for ; Mon, 31 Oct 2011 08:58:33 +0000 (UTC) (envelope-from samspeed@mail.ru) Received: from f283.mail.ru (f283.mail.ru [217.69.128.250]) by mx1.freebsd.org (Postfix) with ESMTP id A9A2E8FC0A for ; Mon, 31 Oct 2011 08:58:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Message-Id:Content-Transfer-Encoding:Content-Type:Reply-To:In-Reply-To:References:Date:Mime-Version:Subject:Cc:To:From; bh=n6sj60S7WA+99hfddEhKHgq9WGf53RznOMLWRcOCSJc=; b=j3/uvldx92CMQHsfU2K2jw7Ld7AFXJNCev65dVwcAcPT+d7uGSOcfVCASUzoKT7DSLjR4e8XM75pRj25ZqR9OS7iOxKqeaq3iS8OT/T+0LoxOThSWszXX/jr0hRdiB5U; Received: from mail by f283.mail.ru with local id 1RKnhN-0003rb-00; Mon, 31 Oct 2011 12:58:29 +0400 Received: from [95.32.229.148] by e.mail.ru with HTTP; Mon, 31 Oct 2011 12:58:29 +0400 From: =?UTF-8?B?QW5kcmV5IFNtYWdpbg==?= To: pyunyh@gmail.com Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [95.32.229.148] Date: Mon, 31 Oct 2011 12:58:29 +0400 References: <20111031005519.GC1679@michelle.cdnetworks.com> In-Reply-To: <20111031005519.GC1679@michelle.cdnetworks.com> X-Priority: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Message-Id: X-Spam: Not detected X-Mras: Ok X-Mailman-Approved-At: Mon, 31 Oct 2011 11:50:24 +0000 Cc: freebsd-net@freebsd.org Subject: Re[2]: PCI-E VT6130 NIC (if_vge) hang system with gigabit link X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?UTF-8?B?QW5kcmV5IFNtYWdpbg==?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 08:58:33 -0000 CgoKMzEg0L7QutGC0Y/QsdGA0Y8gMjAxMSwgMDQ6NTYg0L7RgiBZb25nSHllb24gUFlVTiA8cHl1 bnloQGdtYWlsLmNvbT46Cj4gT24gU2F0LCBPY3QgMjksIDIwMTEgYXQgMDk6NTc6MzBBTSArMDQw MCwgQW5kcmV5IFNtYWdpbiB3cm90ZToKPiA+Cj4gPiBPay4gV2l0aCBhdXRvbmVnb3RpYXRpb24g aWZjb25maWcgc2hvdyBzcGVlZCAxMDBNQml0Lgo+IAo+IEFuZCB2Z2UoNCkgd29yayB3aXRob3V0 IHByb2JsZW1zIHdpdGggdGhlIHJlc29sdmVkIHNwZWVkL2R1cGxleAo+IG9mIGF1dG8tbmVnb3Rp YXRpb24/Cj4gCj4gPiB3aXRoIG1hbnVhbCAxMDAwYmFzZVQgZnVsbC1kdXBsZXggc2V0dGluZ3Mg aW4gZG1lc2c6Cj4gPiB2Z2UwOiBmYWlsZWQgdG8gc3RhcnQgTUlJIGF1dG9wb2xsCj4gPiB2Z2Uw OiBNSUkgcmVhZCB0aW1lZCBvdXQKPiA+IHZnZTA6IGZhaWxlZCB0byBzdGFydCBNSUkgYXV0b3Bv bGwKPiA+IHZnZTA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUAo+ID4gdmdlMDogTUlJIHJlYWQg dGltZWQgb3V0Cj4gCj4gWy4uLl0KPiAKPiBEaWQgdmdlKDQpIGV2ZXIgd29yayB3aXRoIDEwMDBi YXNlVCBvbiB5b3VyIGJveD8KSG0uLi4gSSBuZXZlciBzZWVuIDEwMDBiYXNlVCB3aXRoIHZnZSBv biB0aGlzIGJveCBiZWNhdXNlIAppdCBoYXZlIG9ubHkgRnJlZUJTRC4KPiBBbmQgd2h5IHlvdSBo YXZlIHRvIG1hbnVhbGx5IGNvbmZpZ3VyZSAxMDAwYmFzZVQgbGluaz8KV2l0aCBhdXRvbmVnYXRp YXRpb24gbGluayBzdGFuZCBvbiAxMDBNYml0IGZ1bGwtZHVwbGV4Cj4gRG9lcyBsaW5rIHBhcnRu ZXIoc3dpdGNoKSBhbHNvIHVzZSBhdXRvLW5lZ290aWF0aW9uPwpJbiBib3ggYWxzbyBwcmVzZW50 IEludGVsIGlmX2VtIGdpZ2FiaXQgIGFuZCBpZl9uZmUgZ2lnYWJpdCBjYXJkIHdpY2ggd29yayB3 aXRoIApzYW1lIGNhYmxlIGFuZCBwYXJ0bmVyKHN3aXRjaCkgYXQgZ2lnYWJpdCBzcGVlZC4gSSBv bmx5IHN3aXRjaCBjb25uZWN0b3IgdG8gaWZfdmdlIHNvY2tldC4KPiA= From owner-freebsd-net@FreeBSD.ORG Mon Oct 31 12:34:28 2011 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 797B6106566B for ; Mon, 31 Oct 2011 12:34:28 +0000 (UTC) (envelope-from samspeed@mail.ru) Received: from f273.mail.ru (f273.mail.ru [217.69.128.241]) by mx1.freebsd.org (Postfix) with ESMTP id EA7028FC13 for ; Mon, 31 Oct 2011 12:34:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Message-Id:Content-Transfer-Encoding:Content-Type:Reply-To:In-Reply-To:References:Date:Mime-Version:Subject:Cc:To:From; bh=MHy7TQB1YuWD1rwF9Bm/GDhil5C2SCpXd964DBsUpAg=; b=gbk91DjBlBNNx3PaBJ3EzxZ7rhv3nvUNBh5oOLLE7jQuuUQgHa5THGeogzAvXmIAlm2tSFEOutQlvbsaso+2zQlF5EJPtWL+aEjTDbJGreMkURxlltelgQhh/vGd4153; Received: from mail by f273.mail.ru with local id 1RKr4K-000369-00; Mon, 31 Oct 2011 16:34:24 +0400 Received: from [95.32.229.148] by e.mail.ru with HTTP; Mon, 31 Oct 2011 16:34:24 +0400 From: =?UTF-8?B?QW5kcmV5IFNtYWdpbg==?= To: pyunyh@gmail.com Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [95.32.229.148] Date: Mon, 31 Oct 2011 16:34:24 +0400 References: <20111031005519.GC1679@michelle.cdnetworks.com> In-Reply-To: <20111031005519.GC1679@michelle.cdnetworks.com> X-Priority: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Message-Id: X-Spam: Not detected X-Mras: Ok X-Mailman-Approved-At: Mon, 31 Oct 2011 15:31:17 +0000 Cc: freebsd-net@freebsd.org Subject: Re[2]: PCI-E VT6130 NIC (if_vge) hang system with gigabit link X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?UTF-8?B?QW5kcmV5IFNtYWdpbg==?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 12:34:28 -0000 CgoKMzEg0L7QutGC0Y/QsdGA0Y8gMjAxMSwgMDQ6NTcg0L7RgiBZb25nSHllb24gUFlVTiA8cHl1 bnloQGdtYWlsLmNvbT46Cj4gT24gU2F0LCBPY3QgMjksIDIwMTEgYXQgMDk6NTc6MzBBTSArMDQw MCwgQW5kcmV5IFNtYWdpbiB3cm90ZToKPiA+Cj4gPiBPay4gV2l0aCBhdXRvbmVnb3RpYXRpb24g aWZjb25maWcgc2hvdyBzcGVlZCAxMDBNQml0Lgo+IAo+IEFuZCB2Z2UoNCkgd29yayB3aXRob3V0 IHByb2JsZW1zIHdpdGggdGhlIHJlc29sdmVkIHNwZWVkL2R1cGxleAo+IG9mIGF1dG8tbmVnb3Rp YXRpb24/CgpXaXRoIGF1dG8tbmVnb3RpYXRpb24gdmdlIGNvbm5lY3QgYXQgMTAwYmFzZVRYIGFu ZCB3b3JrIGdvb2QuCgo+IAo+ID4gd2l0aCBtYW51YWwgMTAwMGJhc2VUIGZ1bGwtZHVwbGV4IHNl dHRpbmdzIGluIGRtZXNnOgo+ID4gdmdlMDogZmFpbGVkIHRvIHN0YXJ0IE1JSSBhdXRvcG9sbAo+ ID4gdmdlMDogTUlJIHJlYWQgdGltZWQgb3V0Cj4gPiB2Z2UwOiBmYWlsZWQgdG8gc3RhcnQgTUlJ IGF1dG9wb2xsCj4gPiB2Z2UwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKPiA+IHZnZTA6IE1J SSByZWFkIHRpbWVkIG91dAo= From owner-freebsd-net@FreeBSD.ORG Mon Oct 31 16:46:44 2011 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 0F0B6106566C; Mon, 31 Oct 2011 16:46:44 +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 DA5978FC17; Mon, 31 Oct 2011 16:46:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9VGkh6t082151; Mon, 31 Oct 2011 16:46:43 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9VGkhVS082147; Mon, 31 Oct 2011 16:46:43 GMT (envelope-from linimon) Date: Mon, 31 Oct 2011 16:46:43 GMT Message-Id: <201110311646.p9VGkhVS082147@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/162201: [ip] [patch] multicast forwarding cache hash always allocated with size 0, resulting in buffer overrun 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, 31 Oct 2011 16:46:44 -0000 Old Synopsis: [patch] multicast forwarding cache hash always allocated with size 0, resulting in buffer overrun New Synopsis: [ip] [patch] multicast forwarding cache hash always allocated with size 0, resulting in buffer overrun Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Oct 31 16:46:16 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=162201 From owner-freebsd-net@FreeBSD.ORG Mon Oct 31 18:20:11 2011 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 6B967106564A for ; Mon, 31 Oct 2011 18:20:11 +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 50EDE8FC16 for ; Mon, 31 Oct 2011 18:20:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9VIKB6Q065160 for ; Mon, 31 Oct 2011 18:20:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9VIKBfH065159; Mon, 31 Oct 2011 18:20:11 GMT (envelope-from gnats) Date: Mon, 31 Oct 2011 18:20:11 GMT Message-Id: <201110311820.p9VIKBfH065159@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Gleb Smirnoff Cc: Subject: Re: misc/162201: [patch] multicast forwarding cache hash always allocated with size 0, resulting in buffer overrun X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gleb Smirnoff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 18:20:11 -0000 The following reply was made to PR kern/162201; it has been noted by GNATS. From: Gleb Smirnoff To: Stevan Markovic Cc: freebsd-gnats-submit@FreeBSD.org, zec@FreeBSD.org, bms@FreeBSD.org, bz@FreeBSD.org Subject: Re: misc/162201: [patch] multicast forwarding cache hash always allocated with size 0, resulting in buffer overrun Date: Mon, 31 Oct 2011 21:10:22 +0300 Hi, On Mon, Oct 31, 2011 at 04:22:00PM +0000, Stevan Markovic wrote: S> >Description: S> Bug is observed as kernel panic shortly after stopping XORP (www.xorp.org) configured for PIM/SM routing. Debugging discovered that at the time of MALLOC for V_nexpire in ip_mroute.c::vnet_mroute_init() size variable mfchashsize always has value 0. S> S> Why: variable mfchashsize is initialized in module event handler which is executed with SI_ORDER_ANY ordering tag which happens _after_ variable usage in MALLOC in VNET_SYSINIT with SI_ORDER_MIDDLE. S> S> Fix simply moves variable initialization before its usage in vnet_mroute_init. S> S> This bug is discovered and fixed in McAfee Inc development. S> >How-To-Repeat: S> Hard to reproduce since system behavior after memory overwrite is unpredictable. Multicast forwarding cashe hash overrun always happens after: S> a) configuring xorp to use PIM/SM S> b) starting xorp_rtrmgr S> c) stopping xorp_rtrmgr. S> S> >Fix: S> Fix simply moves mfchashsize variable initialization before its usage in vnet_mroute_init. S> S> Patch attached with submission follows: S> S> Index: ip_mroute.c S> =================================================================== S> RCS file: /projects/freebsd/src_cvsup/src/sys/netinet/ip_mroute.c,v S> retrieving revision 1.161 S> diff -u -r1.161 ip_mroute.c S> --- ip_mroute.c 22 Nov 2010 19:32:54 -0000 1.161 S> +++ ip_mroute.c 31 Oct 2011 15:54:53 -0000 S> @@ -2814,7 +2814,13 @@ S> static void S> vnet_mroute_init(const void *unused __unused) S> { S> - S> + mfchashsize = MFCHASHSIZE; S> + if (TUNABLE_ULONG_FETCH("net.inet.ip.mfchashsize", &mfchashsize) && S> + !powerof2(mfchashsize)) { S> + printf("WARNING: %s not a power of 2; using default\n", S> + "net.inet.ip.mfchashsize"); S> + mfchashsize = MFCHASHSIZE; S> + } S> MALLOC(V_nexpire, u_char *, mfchashsize, M_MRTABLE, M_WAITOK|M_ZERO); S> bzero(V_bw_meter_timers, sizeof(V_bw_meter_timers)); S> callout_init(&V_expire_upcalls_ch, CALLOUT_MPSAFE); S> @@ -2855,13 +2861,6 @@ S> MFC_LOCK_INIT(); S> VIF_LOCK_INIT(); S> S> - mfchashsize = MFCHASHSIZE; S> - if (TUNABLE_ULONG_FETCH("net.inet.ip.mfchashsize", &mfchashsize) && S> - !powerof2(mfchashsize)) { S> - printf("WARNING: %s not a power of 2; using default\n", S> - "net.inet.ip.mfchashsize"); S> - mfchashsize = MFCHASHSIZE; S> - } S> S> pim_squelch_wholepkt = 0; S> TUNABLE_ULONG_FETCH("net.inet.pim.squelch_wholepkt", Have you tried to remove these VNET_SYSINITs at all and do all the initialization in the ip_mroute_modevent() itself? From first glance I see no reason for separate malloc() + callout_init()s. I am putting guys, who made and reviewed the commit, into Cc. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon Oct 31 18:40:13 2011 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 71F501065673 for ; Mon, 31 Oct 2011 18:40:13 +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 60E4A8FC18 for ; Mon, 31 Oct 2011 18:40:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9VIeDV3084146 for ; Mon, 31 Oct 2011 18:40:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9VIeDFX084145; Mon, 31 Oct 2011 18:40:13 GMT (envelope-from gnats) Date: Mon, 31 Oct 2011 18:40:13 GMT Message-Id: <201110311840.p9VIeDFX084145@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Cc: Subject: RE: misc/162201: [patch] multicast forwarding cache hash always allocated with size 0, resulting in buffer overrun X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stevan_Markovic@McAfee.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 18:40:13 -0000 The following reply was made to PR kern/162201; it has been noted by GNATS. From: To: Cc: , , , Subject: RE: misc/162201: [patch] multicast forwarding cache hash always allocated with size 0, resulting in buffer overrun Date: Mon, 31 Oct 2011 13:26:43 -0500 Hi, Gleb, no, I have not tried to eliminate VNET_SYSINITS and I do not think it= can be done. My understanding is that VNET_SYSINIT initializes virtual net= work stack instance specific data. Eliminating it would prevent using multi= cast in multiple virtual network stacks.=20 Stevan=20 -----Original Message----- From: Gleb Smirnoff [mailto:glebius@FreeBSD.org]=20 Sent: Monday, October 31, 2011 2:10 PM To: Markovic, Stevan Cc: freebsd-gnats-submit@FreeBSD.org; zec@FreeBSD.org; bms@FreeBSD.org; bz@= FreeBSD.org Subject: Re: misc/162201: [patch] multicast forwarding cache hash always al= located with size 0, resulting in buffer overrun Hi, On Mon, Oct 31, 2011 at 04:22:00PM +0000, Stevan Markovic wrote: S> >Description: S> Bug is observed as kernel panic shortly after stopping XORP (www.xorp.or= g) configured for PIM/SM routing. Debugging discovered that at the time of = MALLOC for V_nexpire in ip_mroute.c::vnet_mroute_init() size variable mfcha= shsize always has value 0.=20 S>=20 S> Why: variable mfchashsize is initialized in module event handler which i= s executed with SI_ORDER_ANY ordering tag which happens _after_ variable u= sage in MALLOC in VNET_SYSINIT with SI_ORDER_MIDDLE. S>=20 S> Fix simply moves variable initialization before its usage in vnet_mroute= _init. S>=20 S> This bug is discovered and fixed in McAfee Inc development. S> >How-To-Repeat: S> Hard to reproduce since system behavior after memory overwrite is unpred= ictable. Multicast forwarding cashe hash overrun always happens after: S> a) configuring xorp to use PIM/SM S> b) starting xorp_rtrmgr S> c) stopping xorp_rtrmgr. S>=20 S> >Fix: S> Fix simply moves mfchashsize variable initialization before its usage in= vnet_mroute_init. S>=20 S> Patch attached with submission follows: S>=20 S> Index: ip_mroute.c S> =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=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D S> RCS file: /projects/freebsd/src_cvsup/src/sys/netinet/ip_mroute.c,v S> retrieving revision 1.161 S> diff -u -r1.161 ip_mroute.c S> --- ip_mroute.c 22 Nov 2010 19:32:54 -0000 1.161 S> +++ ip_mroute.c 31 Oct 2011 15:54:53 -0000 S> @@ -2814,7 +2814,13 @@ S> static void S> vnet_mroute_init(const void *unused __unused) S> { S> - S> + mfchashsize =3D MFCHASHSIZE; S> + if (TUNABLE_ULONG_FETCH("net.inet.ip.mfchashsize", &mfchashsize) && S> + !powerof2(mfchashsize)) { S> + printf("WARNING: %s not a power of 2; using default\n", S> + "net.inet.ip.mfchashsize"); S> + mfchashsize =3D MFCHASHSIZE; S> + } S> MALLOC(V_nexpire, u_char *, mfchashsize, M_MRTABLE, M_WAITOK|M_ZERO); S> bzero(V_bw_meter_timers, sizeof(V_bw_meter_timers)); S> callout_init(&V_expire_upcalls_ch, CALLOUT_MPSAFE); S> @@ -2855,13 +2861,6 @@ S> MFC_LOCK_INIT(); S> VIF_LOCK_INIT(); S> =20 S> - mfchashsize =3D MFCHASHSIZE; S> - if (TUNABLE_ULONG_FETCH("net.inet.ip.mfchashsize", &mfchashsize) && S> - !powerof2(mfchashsize)) { S> - printf("WARNING: %s not a power of 2; using default\n", S> - "net.inet.ip.mfchashsize"); S> - mfchashsize =3D MFCHASHSIZE; S> - } S> =20 S> pim_squelch_wholepkt =3D 0; S> TUNABLE_ULONG_FETCH("net.inet.pim.squelch_wholepkt", Have you tried to remove these VNET_SYSINITs at all and do all the initialization in the ip_mroute_modevent() itself? From first glance I see no reason for separate malloc() + callout_init()s. I am putting guys, who made and reviewed the commit, into Cc. --=20 Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon Oct 31 19:40:10 2011 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 1061D1065673 for ; Mon, 31 Oct 2011 19:40:10 +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 F34668FC14 for ; Mon, 31 Oct 2011 19:40:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9VJe9Wx039221 for ; Mon, 31 Oct 2011 19:40:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9VJe9oZ039219; Mon, 31 Oct 2011 19:40:09 GMT (envelope-from gnats) Date: Mon, 31 Oct 2011 19:40:09 GMT Message-Id: <201110311940.p9VJe9oZ039219@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Gleb Smirnoff Cc: Subject: Re: kern/162110: Releng_9 panics on boot in IGB driver - regression from 8.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gleb Smirnoff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 19:40:10 -0000 The following reply was made to PR kern/162110; it has been noted by GNATS. From: Gleb Smirnoff To: Frank Terhaar-Yonkers Cc: freebsd-gnats-submit@FreeBSD.org, jfv@FreeBSD.org Subject: Re: kern/162110: Releng_9 panics on boot in IGB driver - regression from 8.2 Date: Mon, 31 Oct 2011 22:37:28 +0300 --LTeJQqWS0MN7I/qa Content-Type: text/plain; charset=koi8-r Content-Disposition: inline On Fri, Oct 28, 2011 at 07:43:28PM +0000, Frank Terhaar-Yonkers wrote: F> F> >Number: 162110 F> >Category: kern F> >Synopsis: Releng_9 panics on boot in IGB driver - regression from 8.2 F> >Confidential: no F> >Severity: critical F> >Priority: high F> >Responsible: freebsd-bugs F> >State: open F> >Quarter: F> >Keywords: F> >Date-Required: F> >Class: sw-bug F> >Submitter-Id: current-users F> >Arrival-Date: Fri Oct 28 19:50:08 UTC 2011 F> >Closed-Date: F> >Last-Modified: F> >Originator: Frank Terhaar-Yonkers F> >Release: Releng_9 CVSUP 2011-October-28 F> >Organization: F> Cisco F> >Environment: F> FreeBSD fty-zfs-01 9.0-RC1 FreeBSD 9.0-RC1 #1: Fri Oct 28 06:50:23 EDT 2011 toot@fty-zfs-01:/usr/obj/usr/src/sys/GENERIC amd64 F> >Description: F> if_igb driver panics during bootup. F> F> The IGB driver probes the device at line 591 of if_igb.c and punts: F> if (e1000_validate_nvm_checksum(&adapter->hw) < 0) { F> device_printf(dev, F> "The EEPROM Checksum Is Not Valid\n"); F> error = EIO; F> goto err_late; F> } F> F> The kernel immediately panics with a page fault. The trace-back show it's in the if_igb driver as the console messages suggest. F> F> Releng_8 did not panic, so this is a regression. The IGB NIC most likely has some sort of problem which is properly diagnosed. F> F> Email me if you want the screen shot of the panic, or have a fix to try out. To reproduce your problem, I've put '|| 1)' conditional into code quoted above. It appeared that calling igb_detach() in case of igb_attach() failure is full of landmines. Attached patch fixes lot of them, and at least kernel doesn't panic in case of e1000_validate_nvm_checksum() failure, not sure about other cases. Unfortunately patch will not fix your NIC, it only cures panic. I've put into Cc Jack Vogel, who is maintainer of the Intel NIC drivers in FreeBSD. May be he can help you. Jack, please consider including my patch into next version of driver. The issues fixed: - igb_detach() may be called with not initialized ifp - igb_stop() may be called with not initialized ifp - igb_detach() already does free transmit/receive structures - igb_detach() already does free adapter->mta - igb_detach() already does destroy core lock There are probably other edge cases, when kernel panics due to some failure in igb_attach(), not all possible error exits were tested. -- Totus tuus, Glebius. --LTeJQqWS0MN7I/qa Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="if_igb.c.diff" Index: if_igb.c =================================================================== --- if_igb.c (revision 226966) +++ if_igb.c (working copy) @@ -670,11 +670,12 @@ err_late: igb_detach(dev); - igb_free_transmit_structures(adapter); - igb_free_receive_structures(adapter); igb_release_hw_control(adapter); if (adapter->ifp != NULL) if_free(adapter->ifp); + igb_free_pci_resources(adapter); + return (error); + err_pci: igb_free_pci_resources(adapter); free(adapter->mta, M_DEVBUF); @@ -701,26 +702,37 @@ INIT_DEBUGOUT("igb_detach: begin"); - /* Make sure VLANS are not using driver */ - if (adapter->ifp->if_vlantrunk != NULL) { - device_printf(dev,"Vlan in use, detach first\n"); - return (EBUSY); - } + IGB_CORE_LOCK(adapter); + adapter->in_detach = 1; + igb_stop(adapter); + IGB_CORE_UNLOCK(adapter); - ether_ifdetach(adapter->ifp); + /* Unregister VLAN events */ + if (adapter->vlan_attach != NULL) + EVENTHANDLER_DEREGISTER(vlan_config, adapter->vlan_attach); + if (adapter->vlan_detach != NULL) + EVENTHANDLER_DEREGISTER(vlan_unconfig, adapter->vlan_detach); - if (adapter->led_dev != NULL) - led_destroy(adapter->led_dev); + callout_drain(&adapter->timer); + if (ifp != NULL) { + /* Make sure VLANS are not using driver */ + if (ifp->if_vlantrunk != NULL) { + device_printf(dev,"Vlan in use, detach first\n"); + return (EBUSY); + } + + ether_ifdetach(ifp); + #ifdef DEVICE_POLLING - if (ifp->if_capenable & IFCAP_POLLING) - ether_poll_deregister(ifp); + if (ifp->if_capenable & IFCAP_POLLING) + ether_poll_deregister(ifp); #endif + if_free(ifp); + } - IGB_CORE_LOCK(adapter); - adapter->in_detach = 1; - igb_stop(adapter); - IGB_CORE_UNLOCK(adapter); + if (adapter->led_dev != NULL) + led_destroy(adapter->led_dev); e1000_phy_hw_reset(&adapter->hw); @@ -734,17 +746,8 @@ igb_enable_wakeup(dev); } - /* Unregister VLAN events */ - if (adapter->vlan_attach != NULL) - EVENTHANDLER_DEREGISTER(vlan_config, adapter->vlan_attach); - if (adapter->vlan_detach != NULL) - EVENTHANDLER_DEREGISTER(vlan_unconfig, adapter->vlan_detach); - - callout_drain(&adapter->timer); - igb_free_pci_resources(adapter); bus_generic_detach(dev); - if_free(ifp); igb_free_transmit_structures(adapter); igb_free_receive_structures(adapter); @@ -2135,7 +2138,8 @@ callout_stop(&adapter->timer); /* Tell the stack that the interface is no longer active */ - ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); + if (ifp != NULL) + ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); /* Unarm watchdog timer. */ for (int i = 0; i < adapter->num_queues; i++, txr++) { --LTeJQqWS0MN7I/qa-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 31 20:30:15 2011 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 37D77106564A for ; Mon, 31 Oct 2011 20:30:15 +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 261858FC14 for ; Mon, 31 Oct 2011 20:30:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9VKUFBT084209 for ; Mon, 31 Oct 2011 20:30:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9VKUFoR084208; Mon, 31 Oct 2011 20:30:15 GMT (envelope-from gnats) Date: Mon, 31 Oct 2011 20:30:15 GMT Message-Id: <201110312030.p9VKUFoR084208@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Marko Zec Cc: Subject: Re: misc/162201: [patch] multicast forwarding cache hash always allocated with size 0, resulting in buffer overrun X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marko Zec List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 20:30:15 -0000 The following reply was made to PR kern/162201; it has been noted by GNATS. From: Marko Zec To: Stevan_Markovic@mcafee.com Cc: glebius@freebsd.org, freebsd-gnats-submit@freebsd.org, bms@freebsd.org, bz@freebsd.org Subject: Re: misc/162201: [patch] multicast forwarding cache hash always allocated with size 0, resulting in buffer overrun Date: Mon, 31 Oct 2011 21:13:27 +0100 On Monday 31 October 2011 19:26:43 Stevan_Markovic@mcafee.com wrote: > Hi, > > Gleb, no, I have not tried to eliminate VNET_SYSINITS and I do not think it > can be done. My understanding is that VNET_SYSINIT initializes virtual > network stack instance specific data. Eliminating it would prevent using > multicast in multiple virtual network stacks. vnet_mroute_init() should be triggered after ip_mroute_modevent() is done, not before, I think that's the whole wisdom here. I'll throw a look at this... Marko > Stevan > > -----Original Message----- > From: Gleb Smirnoff [mailto:glebius@FreeBSD.org] > Sent: Monday, October 31, 2011 2:10 PM > To: Markovic, Stevan > Cc: freebsd-gnats-submit@FreeBSD.org; zec@FreeBSD.org; bms@FreeBSD.org; > bz@FreeBSD.org Subject: Re: misc/162201: [patch] multicast forwarding cache > hash always allocated with size 0, resulting in buffer overrun > > Hi, > > On Mon, Oct 31, 2011 at 04:22:00PM +0000, Stevan Markovic wrote: > S> >Description: > S> Bug is observed as kernel panic shortly after stopping XORP > (www.xorp.org) configured for PIM/SM routing. Debugging discovered that at > the time of MALLOC for V_nexpire in ip_mroute.c::vnet_mroute_init() size > variable mfchashsize always has value 0. S> > S> Why: variable mfchashsize is initialized in module event handler which > is executed with SI_ORDER_ANY ordering tag which happens _after_ variable > usage in MALLOC in VNET_SYSINIT with SI_ORDER_MIDDLE. S> > S> Fix simply moves variable initialization before its usage in > vnet_mroute_init. S> > S> This bug is discovered and fixed in McAfee Inc development. > S> >How-To-Repeat: > S> Hard to reproduce since system behavior after memory overwrite is > unpredictable. Multicast forwarding cashe hash overrun always happens > after: S> a) configuring xorp to use PIM/SM > S> b) starting xorp_rtrmgr > S> c) stopping xorp_rtrmgr. > S> > S> >Fix: > S> Fix simply moves mfchashsize variable initialization before its usage in > vnet_mroute_init. S> > S> Patch attached with submission follows: > S> > S> Index: ip_mroute.c > S> =================================================================== > S> RCS file: /projects/freebsd/src_cvsup/src/sys/netinet/ip_mroute.c,v > S> retrieving revision 1.161 > S> diff -u -r1.161 ip_mroute.c > S> --- ip_mroute.c 22 Nov 2010 19:32:54 -0000 1.161 > S> +++ ip_mroute.c 31 Oct 2011 15:54:53 -0000 > S> @@ -2814,7 +2814,13 @@ > S> static void > S> vnet_mroute_init(const void *unused __unused) > S> { > S> - > S> + mfchashsize = MFCHASHSIZE; > S> + if (TUNABLE_ULONG_FETCH("net.inet.ip.mfchashsize", &mfchashsize) && > S> + !powerof2(mfchashsize)) { > S> + printf("WARNING: %s not a power of 2; using default\n", > S> + "net.inet.ip.mfchashsize"); > S> + mfchashsize = MFCHASHSIZE; > S> + } > S> MALLOC(V_nexpire, u_char *, mfchashsize, M_MRTABLE, M_WAITOK|M_ZERO); > S> bzero(V_bw_meter_timers, sizeof(V_bw_meter_timers)); > S> callout_init(&V_expire_upcalls_ch, CALLOUT_MPSAFE); > S> @@ -2855,13 +2861,6 @@ > S> MFC_LOCK_INIT(); > S> VIF_LOCK_INIT(); > S> > S> - mfchashsize = MFCHASHSIZE; > S> - if (TUNABLE_ULONG_FETCH("net.inet.ip.mfchashsize", &mfchashsize) && > S> - !powerof2(mfchashsize)) { > S> - printf("WARNING: %s not a power of 2; using default\n", > S> - "net.inet.ip.mfchashsize"); > S> - mfchashsize = MFCHASHSIZE; > S> - } > S> > S> pim_squelch_wholepkt = 0; > S> TUNABLE_ULONG_FETCH("net.inet.pim.squelch_wholepkt", > > Have you tried to remove these VNET_SYSINITs at all and do all the > initialization in the ip_mroute_modevent() itself? From first glance > I see no reason for separate malloc() + callout_init()s. > > I am putting guys, who made and reviewed the commit, into Cc. From owner-freebsd-net@FreeBSD.ORG Mon Oct 31 23:16:23 2011 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 50CBA106566B; Mon, 31 Oct 2011 23:16:23 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id AF8788FC0C; Mon, 31 Oct 2011 23:16:22 +0000 (UTC) Received: by wyh11 with SMTP id 11so2677473wyh.13 for ; Mon, 31 Oct 2011 16:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=CMhyiDnh1JpxlNqSWoEYuFbFnqcUTOnwCPbfF7DFGQo=; b=DHBlW0wPUu/nqeqMFct0NOBnAGWP8vAHyt8cwHGnajoXdDsVA+5Pk92sSIegbZWfZj wPcBk3vJSbL8j1tcnPv6UoKpxaNVqHp0i3p6Ek5+b6BS2gMa0zk/nRPwj5G63ial4LPV sUrDm4Lgv9Y20p8DWF+O7qrF3MkOsLLI2ul1Y= MIME-Version: 1.0 Received: by 10.227.209.21 with SMTP id ge21mr21054686wbb.6.1320102981624; Mon, 31 Oct 2011 16:16:21 -0700 (PDT) Received: by 10.180.105.162 with HTTP; Mon, 31 Oct 2011 16:16:21 -0700 (PDT) Date: Mon, 31 Oct 2011 19:16:21 -0400 Message-ID: From: Arnaud Lacombe To: Julian Elischer , freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Undocumented netgraph `cmd' flags ? 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, 31 Oct 2011 23:16:23 -0000 Hi Julian, For my information, is it documented anywhere that bit 28[0] and 29[1] of Netgraph message's `cmd' shall not be used (the bits, not the macros) ? Thanks, - Arnaud [0]: NGM_READONLY [1]: NGM_HASREPLY From owner-freebsd-net@FreeBSD.ORG Tue Nov 1 02:08:17 2011 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 2605E1065672 for ; Tue, 1 Nov 2011 02:08:17 +0000 (UTC) (envelope-from pprocacci@datapipe.com) Received: from EXFESMQ04.datapipe-corp.net (exfesmq04.datapipe.com [64.27.120.68]) by mx1.freebsd.org (Postfix) with ESMTP id D09758FC1E for ; Tue, 1 Nov 2011 02:08:16 +0000 (UTC) Received: from nat.myhome (192.168.128.103) by EXFESMQ04.datapipe-corp.net (192.168.128.29) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 31 Oct 2011 21:57:24 -0400 Date: Mon, 31 Oct 2011 20:57:46 -0500 From: "Paul A. Procacci" To: Message-ID: <20111101015746.GA96508@nat.myhome> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [192.168.128.103] Content-Transfer-Encoding: quoted-printable Subject: [High Interrupt Count] Networking Difficulties 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, 01 Nov 2011 02:08:17 -0000 Gents, I'm having quite an aweful problem that I need a bit of help with. I have an HPDL360 G3 ( http://h18000.www1.hp.com/products/quickspecs/11504_= na/11504_na.HTML ) which acts as a NAT (via PF) for several (600+) class C'= s amongst 24+ machines sitting behind it. It's running FPSense (FreeBSD 8.1-RELEASE-p4). The important guts are: 2 x 2.8 GHz Cpus 2 BGE interfaces on a PCI-X bus. During peak times this machine is only able to handle between 500Mbps - 600= Mbps before running out of cpu capacity. (300Mbps(ish) on the LAN, 300Mbps= (ish) on the WAN) It's due to the high number of interrupts. I was speaking with a networking engineer here and he mentioned that I shou= ld look at "Interrupt Coalescing" to increase throughput. The only information I found online regarding this was a post from 2 years = ago here: http://lists.freebsd.org/pipermail/freebsd-net/2009-June/022227.h= tml The tunables mentioned in the above post aren't present in my system, so I = imagine this never made it into the bge driver. Assuming this to be the ca= se, I started looking at DEVICE_POLLING as a solution. I did try implementing device polling, but the results were worse than I ex= pected. netisr was using 100% of a single cpu while the other cpu remained= mostly idle. Not knowing exactly what netisr is, I reverted the changes. This leads me to this list. Given the scenario above, I'm nearly certain I= need to use device polling instead of the standard interrupt driven setup. The two sysctl's that I've come across thus far that I think are what I nee= d are: net.isr.maxthreads hern.hz I would assume setting net.isr.maxthreads to 2 given my dual core machine i= s advisable, but I'm not 100% sure. What are the caveats in setting this higher? Given the output of `sysctl -= d net.isr.maxthreads` I would expect anything higher than the number of cor= es to be detrimental. Is this correct? kern.hz I'm more unsure of. I understand what the sysctl is, but I'm not s= ure how to come up with a reasonable number. Generally speaking, and in your experience, would a setting of 2000 achive = close to the theoritical meximum of the cards? Is there an upper limit tha= t I would be worried about? Random Question: - is device polling really the answer? I am missing something in the bge d= river that I've overlooked? - what tunables directly effect processing high volumes of packets. Network Interfaces: ###########################################################################= ####### bge0: flags=3D8943 metric 0= mtu 1500 options=3D8009b ether 00:0b:cd:ca:1d:1a inet 209.18.70.211 netmask 0xffffff00 broadcast 209.18.70.255 inet6 fe80::20b:cdff:feca:1d1a%bge0 prefixlen 64 scopeid 0x1 nd6 options=3D3 media: Ethernet autoselect (1000baseT ) status: active bge1: flags=3D8943 metric 0= mtu 1500 options=3D8009b ether 00:0b:cd:ca:1a:74 inet 172.16.0.3 netmask 0xfffc0000 broadcast 172.19.255.255 inet6 fe80::20b:cdff:feca:1a74%bge1 prefixlen 64 scopeid 0x2 nd6 options=3D3 media: Ethernet autoselect (1000baseT ) status: active ###########################################################################= ####### I appreciate the help in advance. Thanks, Paul ________________________________ This message may contain confidential or privileged information. If you are= not the intended recipient, please advise us immediately and delete this m= essage. See http://www.datapipe.com/about-us-legal-email-disclaimer.htm for= further information on confidentiality and the risks of non-secure electro= nic communication. If you cannot access these links, please notify us by re= ply message and we will send the contents to you. From owner-freebsd-net@FreeBSD.ORG Tue Nov 1 03:25:47 2011 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 55FD91065674; Tue, 1 Nov 2011 03:25:47 +0000 (UTC) (envelope-from kevlo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2D9F78FC13; Tue, 1 Nov 2011 03:25:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pA13Plpl073671; Tue, 1 Nov 2011 03:25:47 GMT (envelope-from kevlo@freefall.freebsd.org) Received: (from kevlo@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pA13PkFL073667; Tue, 1 Nov 2011 03:25:46 GMT (envelope-from kevlo) Date: Tue, 1 Nov 2011 03:25:46 GMT Message-Id: <201111010325.pA13PkFL073667@freefall.freebsd.org> To: milo@cyberlifelabs.com, kevlo@FreeBSD.org, freebsd-net@FreeBSD.org From: kevlo@FreeBSD.org Cc: Subject: Re: bin/155365: [patch] routed(8): if.c in routed fails to compile if time_t and long are different sizes 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, 01 Nov 2011 03:25:47 -0000 Synopsis: [patch] routed(8): if.c in routed fails to compile if time_t and long are different sizes State-Changed-From-To: open->closed State-Changed-By: kevlo State-Changed-When: Tue Nov 1 03:25:20 UTC 2011 State-Changed-Why: Fixed in r204405 http://www.freebsd.org/cgi/query-pr.cgi?pr=155365 From owner-freebsd-net@FreeBSD.ORG Tue Nov 1 05:16:40 2011 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 1961B106783D for ; Tue, 1 Nov 2011 05:16:21 +0000 (UTC) (envelope-from pprocacci@datapipe.com) Received: from EXFESMQ04.datapipe-corp.net (exfesmq04.datapipe.com [64.27.120.68]) by mx1.freebsd.org (Postfix) with ESMTP id A3C348FC14 for ; Tue, 1 Nov 2011 05:16:18 +0000 (UTC) Received: from nat.myhome (192.168.128.103) by EXFESMQ04.datapipe-corp.net (192.168.128.29) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 1 Nov 2011 01:16:17 -0400 Date: Tue, 1 Nov 2011 00:16:37 -0500 From: "Paul A. Procacci" To: Message-ID: <20111101051637.GC2445@nat.myhome> References: <20111101015746.GA96508@nat.myhome> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20111101015746.GA96508@nat.myhome> User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [192.168.128.103] Content-Transfer-Encoding: quoted-printable Subject: Re: [High Interrupt Count] Networking Difficulties 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, 01 Nov 2011 05:16:40 -0000 On Mon, Oct 31, 2011 at 08:57:46PM -0500, Paul A. Procacci wrote: > Gents, > > I'm having quite an aweful problem that I need a bit of help with. > > I have an HPDL360 G3 ( http://h18000.www1.hp.com/products/quickspecs/1150= 4_na/11504_na.HTML ) which acts as a NAT (via PF) for several (600+) class = C's amongst 24+ machines sitting behind it. > It's running FPSense (FreeBSD 8.1-RELEASE-p4). > > The important guts are: > > 2 x 2.8 GHz Cpus > 2 BGE interfaces on a PCI-X bus. > > During peak times this machine is only able to handle between 500Mbps - 6= 00Mbps before running out of cpu capacity. (300Mbps(ish) on the LAN, 300Mb= ps(ish) on the WAN) It's due to the high number of interrupts. > I was speaking with a networking engineer here and he mentioned that I sh= ould look at "Interrupt Coalescing" to increase throughput. > The only information I found online regarding this was a post from 2 year= s ago here: http://lists.freebsd.org/pipermail/freebsd-net/2009-June/022227= .html > > The tunables mentioned in the above post aren't present in my system, so = I imagine this never made it into the bge driver. Assuming this to be the = case, I started looking at DEVICE_POLLING as a solution. > I did try implementing device polling, but the results were worse than I = expected. netisr was using 100% of a single cpu while the other cpu remain= ed mostly idle. > Not knowing exactly what netisr is, I reverted the changes. > > This leads me to this list. Given the scenario above, I'm nearly certain= I need to use device polling instead of the standard interrupt driven setu= p. > The two sysctl's that I've come across thus far that I think are what I n= eed are: > > net.isr.maxthreads > hern.hz > > I would assume setting net.isr.maxthreads to 2 given my dual core machine= is advisable, but I'm not 100% sure. > What are the caveats in setting this higher? Given the output of `sysctl= -d net.isr.maxthreads` I would expect anything higher than the number of c= ores to be detrimental. Is this correct? > > kern.hz I'm more unsure of. I understand what the sysctl is, but I'm not= sure how to come up with a reasonable number. > Generally speaking, and in your experience, would a setting of 2000 achiv= e close to the theoritical meximum of the cards? Is there an upper limit t= hat I would be worried about? > > Random Question: > - is device polling really the answer? I am missing something in the bge= driver that I've overlooked? > - what tunables directly effect processing high volumes of packets. > After some more coffee, and source code reading, I've now learned that havi= ng device polling enabled forces netisr to limit the number of threads it c= reates to 1. This kinda defeats the purpose of enabling device polling. This makes me be= lieve that device polling isn't going to be a great solution afterall. A snippet from dmesg: bge0: mem 0xf7ef= 0000-0xf7efffff irq 30 at device 2.0 on pci1 brgphy0: PHY 1 on miibus0 bge1: mem 0xf7ff= 0000-0xf7ffffff irq 29 at device 2.0 on pci4 brgphy1: PHY 1 on miibus1 Any help/advice is appreciated, and sorry for following up to myself with t= his information. ~Paul ________________________________ This message may contain confidential or privileged information. If you are= not the intended recipient, please advise us immediately and delete this m= essage. See http://www.datapipe.com/about-us-legal-email-disclaimer.htm for= further information on confidentiality and the risks of non-secure electro= nic communication. If you cannot access these links, please notify us by re= ply message and we will send the contents to you. From owner-freebsd-net@FreeBSD.ORG Tue Nov 1 05:31:31 2011 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 87144106570C for ; Tue, 1 Nov 2011 05:31:31 +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 5BB408FC1F for ; Tue, 1 Nov 2011 05:31:31 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id pA15VPbS095525 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 31 Oct 2011 22:31:30 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4EAF842D.3080909@freebsd.org> Date: Mon, 31 Oct 2011 22:31:25 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Arnaud Lacombe References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Undocumented netgraph `cmd' flags ? 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, 01 Nov 2011 05:31:31 -0000 On 10/31/11 4:16 PM, Arnaud Lacombe wrote: > Hi Julian, > > For my information, is it documented anywhere that bit 28[0] and 29[1] > of Netgraph message's `cmd' shall not be used (the bits, not the > macros) ? > > Thanks, > - Arnaud > > [0]: NGM_READONLY > [1]: NGM_HASREPLY > Not really sure what you are asking. NGM_READONLY allows the base system to use a reader lock and not block other traffic while the message is bring processed. NGM_HASREPLY is not used that I can see in the kernel. It may be a historical artifact or maybe only used in the library as a hint. It has been so long since I was involved with netgraph (over a decade) that I really don't remember. From owner-freebsd-net@FreeBSD.ORG Tue Nov 1 07:54:49 2011 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 D8A9C106566C for ; Tue, 1 Nov 2011 07:54:49 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 972118FC15 for ; Tue, 1 Nov 2011 07:54:49 +0000 (UTC) Received: by vws11 with SMTP id 11so399039vws.13 for ; Tue, 01 Nov 2011 00:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9sTmign04JMVVUHNlqU+GuUoYHrCjInFvPRzgmmqHGU=; b=jfZGACOOY4crRZcWWarNajbw0FhxPYNZREVQ5gWrnpsdD+eIMsofJRNCWfH+lh8Z2L 8Dz0AbX3dXXVwUym9CE6SfWp0w++laUvy/mxdwEDs40dPHnxTMQvHTEXCSiaAylbtdK0 RKRnVFXYtec7l9H7F8e8+Q2fyVtNulk76mTYs= MIME-Version: 1.0 Received: by 10.52.100.70 with SMTP id ew6mr7379427vdb.49.1320134088810; Tue, 01 Nov 2011 00:54:48 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.52.164.101 with HTTP; Tue, 1 Nov 2011 00:54:48 -0700 (PDT) In-Reply-To: <20111101015746.GA96508@nat.myhome> References: <20111101015746.GA96508@nat.myhome> Date: Tue, 1 Nov 2011 00:54:48 -0700 X-Google-Sender-Auth: CKXm_v5Jp4hA5RK9gTOklgOOHD0 Message-ID: From: Adrian Chadd To: "Paul A. Procacci" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: [High Interrupt Count] Networking Difficulties 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, 01 Nov 2011 07:54:49 -0000 Hi, I'd suggest starting to dig for datasheets or alternative open source drivers (eg Linux) that exposes what the NIC can do with interrupts (eg interrupt coalescing.) I'd also suggest using hwpmc and doing a spot of profiling to find out where your CPU is being spent. Anything else is conjecture. :) adrian From owner-freebsd-net@FreeBSD.ORG Tue Nov 1 12:59:05 2011 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 47F8E106564A for ; Tue, 1 Nov 2011 12:59:05 +0000 (UTC) (envelope-from bipin@xbipin.com) Received: from xbipin.com (xbipin.com [184.107.58.176]) by mx1.freebsd.org (Postfix) with SMTP id F14018FC18 for ; Tue, 1 Nov 2011 12:59:04 +0000 (UTC) dkim-signature: v=1; a=rsa-sha256; d=xbipin.com; s=2009; c=relaxed/relaxed; q=dns/txt; h=From:Subject:Date:Message-ID:To:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=c/8XCDrYSTk2kscD47M3uQONJKPeIlmb5UgOExu6K0E=; b=boMaC0fXRcDnyH+Ki2uMMdkb/zadyCpRXlzIrcsvD5+FGnWNfL+xu//8638VBwtNaO6GHBPXXMloNGjuPYRLzC/JD4c8GeRBoCouWfYAgUqngD6BSKgYkZx7bl3lfMcj Received: from [192.168.0.11] ([92.99.205.87]) by xbipin.com ; Tue, 1 Nov 2011 16:47:04 +0400 Message-ID: <4EAFEA44.2070109@xbipin.com> Date: Tue, 01 Nov 2011 16:47:00 +0400 From: Bipin Patel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 To: freebsd-net@freebsd.org Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: pppoe reconnection issue 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, 01 Nov 2011 12:59:05 -0000 hi, can some1 help or fix this issue mentioned here [1]http://forum.pfsense.org/index.php/topic,41061.0.html its something to do with freebsd and mpd which causes a pppoe connection not to reestablish once the modem is reset leaving behind a zombie connection which is only brought down with a link down, older freebsd used to perform this well along with the older mpd v4 i guess but this newer mpd v5.5 and newer bsd has this issue, it more over looks like a mpd issue and i was asked to bring up this in this mailing list as the developers at pfsense havent yet replied and there r quiet a few ppl suffering this including me -- Regards, Bipin _________________________________________________________________ References 1. http://forum.pfsense.org/index.php/topic,41061.0.html From owner-freebsd-net@FreeBSD.ORG Tue Nov 1 14:41:05 2011 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 D286E1065670 for ; Tue, 1 Nov 2011 14:41:05 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5E7F68FC16 for ; Tue, 1 Nov 2011 14:41:05 +0000 (UTC) Received: by bkbzs2 with SMTP id zs2so4792293bkb.13 for ; Tue, 01 Nov 2011 07:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=reply-to:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=lzwgEprESVMQEwOfAEKcofW2YPSHXMuaaF12bgW7KEg=; b=N+uzEe8zrVrNWXE27HzW8vYIRevDBUGmW019HUM/9rxbKR79iaAW+dpO6ZrrAl9Ahf gYsWaJDqCdSI0TUh+8y33V2lRKpozJyrZ6jpCLvo0uqDQ5Caxf1yLzA1ZeE4CuVF6eD5 12V75snBpUd98xjWYUwsBDhIVpS95mt/2g6ig= Received: by 10.205.83.73 with SMTP id af9mr15350514bkc.24.1320158464150; Tue, 01 Nov 2011 07:41:04 -0700 (PDT) Received: from rimwks1x64 ([92.124.19.231]) by mx.google.com with ESMTPS id j9sm20875339bkd.2.2011.11.01.07.41.02 (version=SSLv3 cipher=OTHER); Tue, 01 Nov 2011 07:41:03 -0700 (PDT) From: rozhuk.im@gmail.com To: "'Bipin Patel'" , References: <4EAFEA44.2070109@xbipin.com> In-Reply-To: <4EAFEA44.2070109@xbipin.com> Date: Tue, 1 Nov 2011 23:41:01 +0900 Message-ID: <4eb004ff.0922cc0a.3a8a.ffff964e@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyYlikp3w9lsYpLRaqSVHbzvqBL0wAC+RRw Content-Language: ru Cc: Subject: RE: pppoe reconnection issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk.IM@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, 01 Nov 2011 14:41:06 -0000 I have same problem with one ISP some years ago, but config file is lost = ) Try this config for mpd5. If not help - read mpd5 manuals and play with config file. ### Rozhuk Ivan 2009 - 2010 ### MPD configuration file ### startup: ###set user foo bar admin ###set user foo1 bar1 ###set console self 127.0.0.1 5005 set console close #set console enable logging ###set web self 0.0.0.0 5006 set web close #set web enable auth set global disable one-shot tcp-wrapper #log +auth -bund -ccp -chat +console -echo -ecp -frame -fsm -iface +ipcp -ipv6cp -lcp -link -phys -radius -rep log +auth +bund +ccp +chat +console +echo +ecp +frame +fsm +iface +ipcp +ipv6cp +lcp +link +phys +radius +rep default: load pppoe_client1 pppoe_client1: create bundle static BndPPPoECli set bundle fsm-timeout 8 set bundle enable ipcp set bundle no compression encryption bw-manage round-robin ipv6cp crypt-reqd set iface route default set iface mtu 1492 set iface idle 0 set iface session 0 #set iface up-script "/usr/local/etc/mpd5/pppoe_out_link.up" #set iface down-script "/usr/local/etc/mpd5/pppoe_out_link.down" set iface enable tcpmssfix set iface disable on-demand proxy-arp tee nat netflow-in netflow-out netflow-once ipacct set ipcp enable vjcomp req-pri-dns req-sec-dns set ipcp no req-pri-nbns req-sec-nbns create link static LnkPPPoECli pppoe set link action bundle BndPPPoECli set link mtu 1492 set link mru 1492 set link fsm-timeout 8 set link keep-alive 16 40 set link max-redial 0 set link redial-delay 8 set link accept pap chap-md5 chap-msv2 set link enable acfcomp protocomp magicnum check-magic set link no chap-msv1 eap incoming multilink shortseq passive callback no-orig-auth keep-ms-domain time-remain peer-as-calling = report-mac set auth authname XXXXXXXXXX set auth password YYYYYYYYYY set pppoe iface ZZZZZ set pppoe service "" #set pppoe acname Open =A0 -- Rozhuk Ivan =A0=20 > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Bipin Patel > Sent: Tuesday, November 01, 2011 9:47 PM > To: freebsd-net@freebsd.org > Subject: pppoe reconnection issue >=20 >=20 > hi, > can some1 help or fix this issue mentioned here > [1]http://forum.pfsense.org/index.php/topic,41061.0.html > its something to do with freebsd and mpd which causes a pppoe > connection not to reestablish once the modem is reset leaving = behind > a > zombie connection which is only brought down with a link down, = older > freebsd used to perform this well along with the older mpd v4 i > guess > but this newer mpd v5.5 and newer bsd has this issue, it more over > looks like a mpd issue and i was asked to bring up this in this > mailing list as the developers at pfsense havent yet replied and > there > r quiet a few ppl suffering this including me >=20 > -- > Regards, > Bipin > _________________________________________________________________ >=20 > References >=20 > 1. http://forum.pfsense.org/index.php/topic,41061.0.html > _______________________________________________ > 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 Tue Nov 1 15:15:22 2011 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 64A05106564A for ; Tue, 1 Nov 2011 15:15:22 +0000 (UTC) (envelope-from bipin@xbipin.com) Received: from xbipin.com (xbipin.com [184.107.58.176]) by mx1.freebsd.org (Postfix) with SMTP id 28DB78FC0C for ; Tue, 1 Nov 2011 15:15:21 +0000 (UTC) dkim-signature: v=1; a=rsa-sha256; d=xbipin.com; s=2009; c=relaxed/relaxed; q=dns/txt; h=From:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; bh=CCoMpwkqACPGp1vboW74CvHgmdi34laQw8qhneqwUrc=; b=uoH/PxxywPkA4cBnAHUZ8o9PlIJfKLZ9hB1ChJ46Jny/NMERwz1R1XbqP9jSLKACBd4DxI2V9G/AESYnQ6VrYmxkNy+rgS2kcXnCsqa39FPViBht3dyiH9h+fAUxSVbm Received: from [192.168.0.11] ([92.99.205.87]) by xbipin.com ; Tue, 1 Nov 2011 19:15:21 +0400 Message-ID: <4EB00D05.4080204@xbipin.com> Date: Tue, 01 Nov 2011 19:15:17 +0400 From: Bipin Patel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Rozhuk.IM@gmail.com References: <4EAFEA44.2070109@xbipin.com> <4eb004ff.0922cc0a.3a8a.ffff964e@mx.google.com> In-Reply-To: <4eb004ff.0922cc0a.3a8a.ffff964e@mx.google.com> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: pppoe reconnection issue 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, 01 Nov 2011 15:15:22 -0000 hi, can u be more specific on the portion in the script which would make it behave properly because the mod script is a lot different than whats in pfsense so i would have to edit the file manually so its better i know the commands which would make some difference in the present situation Regards, Bipin ------------------------------------------------------------------------ -------- Original Message -------- Subject: Re: pppoe reconnection issue From: rozhuk.im@gmail.com To: 'Bipin Patel' , freebsd-net@freebsd.org Date: Tuesday, November 01, 2011 6:41:01 PM > > I have same problem with one ISP some years ago, but config file is lost ) > > Try this config for mpd5. > If not help - read mpd5 manuals and play with config file. > > > > ### Rozhuk Ivan 2009 - 2010 > ### MPD configuration file > ### > > > startup: > ###set user foo bar admin > ###set user foo1 bar1 > > ###set console self 127.0.0.1 5005 > set console close > #set console enable logging > > ###set web self 0.0.0.0 5006 > set web close > #set web enable auth > > set global disable one-shot tcp-wrapper > > #log +auth -bund -ccp -chat +console -echo -ecp -frame -fsm -iface > +ipcp -ipv6cp -lcp -link -phys -radius -rep > log +auth +bund +ccp +chat +console +echo +ecp +frame +fsm +iface > +ipcp +ipv6cp +lcp +link +phys +radius +rep > > > default: > load pppoe_client1 > > > pppoe_client1: > create bundle static BndPPPoECli > set bundle fsm-timeout 8 > set bundle enable ipcp > set bundle no compression encryption bw-manage round-robin ipv6cp > crypt-reqd > set iface route default > set iface mtu 1492 > set iface idle 0 > set iface session 0 > #set iface up-script "/usr/local/etc/mpd5/pppoe_out_link.up" > #set iface down-script "/usr/local/etc/mpd5/pppoe_out_link.down" > set iface enable tcpmssfix > set iface disable on-demand proxy-arp tee nat netflow-in netflow-out > netflow-once ipacct > set ipcp enable vjcomp req-pri-dns req-sec-dns > set ipcp no req-pri-nbns req-sec-nbns > create link static LnkPPPoECli pppoe > set link action bundle BndPPPoECli > set link mtu 1492 > set link mru 1492 > set link fsm-timeout 8 > set link keep-alive 16 40 > set link max-redial 0 > set link redial-delay 8 > set link accept pap chap-md5 chap-msv2 > set link enable acfcomp protocomp magicnum check-magic > set link no chap-msv1 eap incoming multilink shortseq passive > callback no-orig-auth keep-ms-domain time-remain peer-as-calling report-mac > set auth authname XXXXXXXXXX > set auth password YYYYYYYYYY > set pppoe iface ZZZZZ > set pppoe service "" > #set pppoe acname > Open > > > > > -- > Rozhuk Ivan > > > >> -----Original Message----- >> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- >> net@freebsd.org] On Behalf Of Bipin Patel >> Sent: Tuesday, November 01, 2011 9:47 PM >> To: freebsd-net@freebsd.org >> Subject: pppoe reconnection issue >> >> >> hi, >> can some1 help or fix this issue mentioned here >> [1]http://forum.pfsense.org/index.php/topic,41061.0.html >> its something to do with freebsd and mpd which causes a pppoe >> connection not to reestablish once the modem is reset leaving behind >> a >> zombie connection which is only brought down with a link down, older >> freebsd used to perform this well along with the older mpd v4 i >> guess >> but this newer mpd v5.5 and newer bsd has this issue, it more over >> looks like a mpd issue and i was asked to bring up this in this >> mailing list as the developers at pfsense havent yet replied and >> there >> r quiet a few ppl suffering this including me >> >> -- >> Regards, >> Bipin >> _________________________________________________________________ >> >> References >> >> 1. http://forum.pfsense.org/index.php/topic,41061.0.html >> _______________________________________________ >> 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 Tue Nov 1 15:20:00 2011 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 237DA106564A for ; Tue, 1 Nov 2011 15:20:00 +0000 (UTC) (envelope-from bipin@xbipin.com) Received: from xbipin.com (xbipin.com [184.107.58.176]) by mx1.freebsd.org (Postfix) with SMTP id DA3D78FC14 for ; Tue, 1 Nov 2011 15:19:59 +0000 (UTC) dkim-signature: v=1; a=rsa-sha256; d=xbipin.com; s=2009; c=relaxed/relaxed; q=dns/txt; h=From:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; bh=qUJPt4/S3UC+/8OdwrwRVNjqoK9Kc5Fdwv5r1q8u864=; b=lHsVh6VXUr15nYuw6pR3Bw4VAg4qqDXRahUparhPv1Ri6dxnjOzfdnH9KB9YyKzzH/UCyYQiQkKlLlT8vyIqh8pfyLo0TFKTYsmYNuETMlQfnl0nGcZSLox+bXxEGKxG Received: from [192.168.0.11] ([92.99.205.87]) by xbipin.com ; Tue, 1 Nov 2011 19:19:59 +0400 Message-ID: <4EB00E1A.308@xbipin.com> Date: Tue, 01 Nov 2011 19:19:54 +0400 From: Bipin Patel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Rozhuk.IM@gmail.com References: <4EAFEA44.2070109@xbipin.com> <4eb004ff.0922cc0a.3a8a.ffff964e@mx.google.com> In-Reply-To: <4eb004ff.0922cc0a.3a8a.ffff964e@mx.google.com> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: pppoe reconnection issue 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, 01 Nov 2011 15:20:00 -0000 hi, my current mod config file looks liek this startup: # configure the console set console close # configure the web server set web close default: pppoeclient: create bundle static wan set iface name pppoe0 set iface route default set iface enable on-demand set iface idle 0 set iface addrs 10.10.1.1 10.10.1.2 set iface enable tcpmssfix set iface up-script /usr/local/sbin/ppp-linkup set iface down-script /usr/local/sbin/ppp-linkdown set ipcp ranges 0.0.0.0/0 0.0.0.0/0 set ipcp no vjcomp #log -bund -ccp -chat -iface -ipcp -lcp -link create link static wan_link0 pppoe set link action bundle wan set link disable multilink set link keep-alive 10 60 set link max-redial 0 set link disable chap pap set link accept chap pap eap set link disable incoming set link mtu 1492 set auth authname "username" set auth password password set pppoe service "WE1" set pppoe iface vr1 open Regards, Bipin ------------------------------------------------------------------------ -------- Original Message -------- Subject: Re: pppoe reconnection issue From: rozhuk.im@gmail.com To: 'Bipin Patel' , freebsd-net@freebsd.org Date: Tuesday, November 01, 2011 6:41:01 PM > > I have same problem with one ISP some years ago, but config file is lost ) > > Try this config for mpd5. > If not help - read mpd5 manuals and play with config file. > > > > ### Rozhuk Ivan 2009 - 2010 > ### MPD configuration file > ### > > > startup: > ###set user foo bar admin > ###set user foo1 bar1 > > ###set console self 127.0.0.1 5005 > set console close > #set console enable logging > > ###set web self 0.0.0.0 5006 > set web close > #set web enable auth > > set global disable one-shot tcp-wrapper > > #log +auth -bund -ccp -chat +console -echo -ecp -frame -fsm -iface > +ipcp -ipv6cp -lcp -link -phys -radius -rep > log +auth +bund +ccp +chat +console +echo +ecp +frame +fsm +iface > +ipcp +ipv6cp +lcp +link +phys +radius +rep > > > default: > load pppoe_client1 > > > pppoe_client1: > create bundle static BndPPPoECli > set bundle fsm-timeout 8 > set bundle enable ipcp > set bundle no compression encryption bw-manage round-robin ipv6cp > crypt-reqd > set iface route default > set iface mtu 1492 > set iface idle 0 > set iface session 0 > #set iface up-script "/usr/local/etc/mpd5/pppoe_out_link.up" > #set iface down-script "/usr/local/etc/mpd5/pppoe_out_link.down" > set iface enable tcpmssfix > set iface disable on-demand proxy-arp tee nat netflow-in netflow-out > netflow-once ipacct > set ipcp enable vjcomp req-pri-dns req-sec-dns > set ipcp no req-pri-nbns req-sec-nbns > create link static LnkPPPoECli pppoe > set link action bundle BndPPPoECli > set link mtu 1492 > set link mru 1492 > set link fsm-timeout 8 > set link keep-alive 16 40 > set link max-redial 0 > set link redial-delay 8 > set link accept pap chap-md5 chap-msv2 > set link enable acfcomp protocomp magicnum check-magic > set link no chap-msv1 eap incoming multilink shortseq passive > callback no-orig-auth keep-ms-domain time-remain peer-as-calling report-mac > set auth authname XXXXXXXXXX > set auth password YYYYYYYYYY > set pppoe iface ZZZZZ > set pppoe service "" > #set pppoe acname > Open > > > > > -- > Rozhuk Ivan > > > >> -----Original Message----- >> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- >> net@freebsd.org] On Behalf Of Bipin Patel >> Sent: Tuesday, November 01, 2011 9:47 PM >> To: freebsd-net@freebsd.org >> Subject: pppoe reconnection issue >> >> >> hi, >> can some1 help or fix this issue mentioned here >> [1]http://forum.pfsense.org/index.php/topic,41061.0.html >> its something to do with freebsd and mpd which causes a pppoe >> connection not to reestablish once the modem is reset leaving behind >> a >> zombie connection which is only brought down with a link down, older >> freebsd used to perform this well along with the older mpd v4 i >> guess >> but this newer mpd v5.5 and newer bsd has this issue, it more over >> looks like a mpd issue and i was asked to bring up this in this >> mailing list as the developers at pfsense havent yet replied and >> there >> r quiet a few ppl suffering this including me >> >> -- >> Regards, >> Bipin >> _________________________________________________________________ >> >> References >> >> 1. http://forum.pfsense.org/index.php/topic,41061.0.html >> _______________________________________________ >> 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 Tue Nov 1 16:17:51 2011 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 963C01065673 for ; Tue, 1 Nov 2011 16:17:51 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2EB598FC0C for ; Tue, 1 Nov 2011 16:17:50 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id pA1GHnvL039497; Tue, 1 Nov 2011 17:17:50 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id pA1GHn0g039496; Tue, 1 Nov 2011 17:17:49 +0100 (CET) (envelope-from marius) Date: Tue, 1 Nov 2011 17:17:49 +0100 From: Marius Strobl To: dave jones Message-ID: <20111101161749.GA38912@alchemy.franken.de> References: <20111009165838.GA19886@alchemy.franken.de> 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: Question about GPIO bitbang MII 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, 01 Nov 2011 16:17:51 -0000 On Mon, Oct 10, 2011 at 03:56:32PM +0800, dave jones wrote: > On Mon, Oct 10, 2011 at 12:58 AM, Marius Strobl wrote: > > On Fri, Oct 07, 2011 at 10:34:58AM +0800, dave jones wrote: > >> Hi, > >> > >> Does FreeBSD have gpio bitbang api for MII? If not, any driver in tree using > >> gpio-bitbang mii that I can refer to? Thanks. > >> It seems like OpenBSD, NetBSD and Linux have added support to gpio bitbang mii, > >> and it's useful for porting embedded devices. > >> > > > > If what you are referring to is their mii_bitbang.[c,h] then I've a patch > > which (im)ports these and converts drivers to take advantage of it here: > > http://people.freebsd.org/~marius/mii_bitbang.diff > > You can also hook up that generic MII bitbang'ing code up to GPIO. > > Awesome! This is what I want, thank you very much, Marius. > FYI, I've committed the patch to head in r226995. I'll probably try to get it into 9.0 due to the bus barrier additions done as part of it. Marius From owner-freebsd-net@FreeBSD.ORG Tue Nov 1 17:42:18 2011 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 B0CEE106564A for ; Tue, 1 Nov 2011 17:42:18 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 43CB38FC15 for ; Tue, 1 Nov 2011 17:42:17 +0000 (UTC) Received: by wyg36 with SMTP id 36so776928wyg.13 for ; Tue, 01 Nov 2011 10:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=SaH2to4KCGYhPT14oKKWKb2N5bviXOfk+Waaaf1EfT8=; b=SrCVKUjkYlCMql0E/MmfB1l3YOMDJgZ16QhSvHDcZlbqgMJDDpJeJ2r7MCQmWud9LH jwbq7rVme7qDi8Dm8rWIgwKQdXi1jykKUh5x2hCIszjzwoNOBq/L3hw0QZr835QZPbrr RJHBB3/fJOfoxPrVXb5DHa+hU3VgYDZUiwkUk= Received: by 10.216.137.86 with SMTP id x64mr182114wei.2.1320169337100; Tue, 01 Nov 2011 10:42:17 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id et20sm17153546wbb.15.2011.11.01.10.42.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Nov 2011 10:42:15 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 01 Nov 2011 10:40:41 -0700 From: YongHyeon PYUN Date: Tue, 1 Nov 2011 10:40:41 -0700 To: "Paul A. Procacci" Message-ID: <20111101174041.GC6914@michelle.cdnetworks.com> References: <20111101015746.GA96508@nat.myhome> <20111101051637.GC2445@nat.myhome> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111101051637.GC2445@nat.myhome> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [High Interrupt Count] Networking Difficulties 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, 01 Nov 2011 17:42:18 -0000 On Tue, Nov 01, 2011 at 12:16:37AM -0500, Paul A. Procacci wrote: > On Mon, Oct 31, 2011 at 08:57:46PM -0500, Paul A. Procacci wrote: > > Gents, > > > > I'm having quite an aweful problem that I need a bit of help with. > > > > I have an HPDL360 G3 ( http://h18000.www1.hp.com/products/quickspecs/11504_na/11504_na.HTML ) which acts as a NAT (via PF) for several (600+) class C's amongst 24+ machines sitting behind it. > > It's running FPSense (FreeBSD 8.1-RELEASE-p4). > > > > The important guts are: > > > > 2 x 2.8 GHz Cpus > > 2 BGE interfaces on a PCI-X bus. > > > > During peak times this machine is only able to handle between 500Mbps - 600Mbps before running out of cpu capacity. (300Mbps(ish) on the LAN, 300Mbps(ish) on the WAN) It's due to the high number of interrupts. > > I was speaking with a networking engineer here and he mentioned that I should look at "Interrupt Coalescing" to increase throughput. > > The only information I found online regarding this was a post from 2 years ago here: http://lists.freebsd.org/pipermail/freebsd-net/2009-June/022227.html > > > > The tunables mentioned in the above post aren't present in my system, so I imagine this never made it into the bge driver. Assuming this to be the case, I started looking at DEVICE_POLLING as a solution. > > I did try implementing device polling, but the results were worse than I expected. netisr was using 100% of a single cpu while the other cpu remained mostly idle. > > Not knowing exactly what netisr is, I reverted the changes. > > > > This leads me to this list. Given the scenario above, I'm nearly certain I need to use device polling instead of the standard interrupt driven setup. > > The two sysctl's that I've come across thus far that I think are what I need are: > > > > net.isr.maxthreads > > hern.hz > > > > I would assume setting net.isr.maxthreads to 2 given my dual core machine is advisable, but I'm not 100% sure. > > What are the caveats in setting this higher? Given the output of `sysctl -d net.isr.maxthreads` I would expect anything higher than the number of cores to be detrimental. Is this correct? > > > > kern.hz I'm more unsure of. I understand what the sysctl is, but I'm not sure how to come up with a reasonable number. > > Generally speaking, and in your experience, would a setting of 2000 achive close to the theoritical meximum of the cards? Is there an upper limit that I would be worried about? > > > > Random Question: > > - is device polling really the answer? I am missing something in the bge driver that I've overlooked? > > - what tunables directly effect processing high volumes of packets. > > > > > > After some more coffee, and source code reading, I've now learned that having device polling enabled forces netisr to limit the number of threads it creates to 1. > This kinda defeats the purpose of enabling device polling. This makes me believe that device polling isn't going to be a great solution afterall. > > A snippet from dmesg: > > bge0: mem 0xf7ef0000-0xf7efffff irq 30 at device 2.0 on pci1 > brgphy0: PHY 1 on miibus0 > bge1: mem 0xf7ff0000-0xf7ffffff irq 29 at device 2.0 on pci4 > brgphy1: PHY 1 on miibus1 > > > Any help/advice is appreciated, and sorry for following up to myself with this information. > In most cases there is *NO* need to use DEVICE_POLLING on advanced controllers like bge(4). How many interrupts do you see on your box? Are you seeing more than 50K interrupts per second? bge(4) already supports interrupt coalescing but its configuration is not tunable yet. So you may have to patch driver to change that. I guess there were a couple of fixes for BCM5703 that sits on PCI-X bus since 8.1-RELEASE. Do you see similar problem on 8.2-RELEASE? From owner-freebsd-net@FreeBSD.ORG Tue Nov 1 18:03:13 2011 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 2859B106566B for ; Tue, 1 Nov 2011 18:03:13 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id AFC898FC0A for ; Tue, 1 Nov 2011 18:03:12 +0000 (UTC) Received: by wwp14 with SMTP id 14so2620256wwp.31 for ; Tue, 01 Nov 2011 11:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=eukINC/e7EWRJ0PeeYoE7dkJxro6asL9ca6AVMPYGsU=; b=dtMJnNL0zFeG3AAvWOe9Dq8QH6/ixuYJwqWWSWCfjR6DLA5TZewHiMHrp692cZ+ewS 8kHvbBIhqeOR6YMauTGw7MTnQDsSjGSVfbaDcOiITfJN250ZgEwm3MYmFJBHGe/mSDuT bd4p2HOLAOuEFJE0kZfzQQPsfPmvtxFxwD5dE= Received: by 10.227.205.132 with SMTP id fq4mr836222wbb.5.1320170591428; Tue, 01 Nov 2011 11:03:11 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id e40sm6094777wbp.3.2011.11.01.11.03.06 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Nov 2011 11:03:09 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 01 Nov 2011 11:01:35 -0700 From: YongHyeon PYUN Date: Tue, 1 Nov 2011 11:01:35 -0700 To: Andrey Smagin Message-ID: <20111101180135.GD6914@michelle.cdnetworks.com> References: <20111031005519.GC1679@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: PCI-E VT6130 NIC (if_vge) hang system with gigabit link 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, 01 Nov 2011 18:03:13 -0000 On Mon, Oct 31, 2011 at 12:58:29PM +0400, Andrey Smagin wrote: > > > > 31 октября 2011, 04:56 от YongHyeon PYUN : > > On Sat, Oct 29, 2011 at 09:57:30AM +0400, Andrey Smagin wrote: > > > > > > Ok. With autonegotiation ifconfig show speed 100MBit. > > > > And vge(4) work without problems with the resolved speed/duplex > > of auto-negotiation? > > > > > with manual 1000baseT full-duplex settings in dmesg: > > > vge0: failed to start MII autopoll > > > vge0: MII read timed out > > > vge0: failed to start MII autopoll > > > vge0: link state changed to UP > > > vge0: MII read timed out > > > > [...] > > > > Did vge(4) ever work with 1000baseT on your box? > Hm... I never seen 1000baseT with vge on this box because > it have only FreeBSD. > > And why you have to manually configure 1000baseT link? > With autonegatiation link stand on 100Mbit full-duplex > > Does link partner(switch) also use auto-negotiation? > In box also present Intel if_em gigabit and if_nfe gigabit card wich work with > same cable and partner(switch) at gigabit speed. I only switch connector to if_vge socket. > > > I should have been more clearer. I wanted to know which previous FreeBSD release was able to establish a 1000baseT link. Downshifting feature of IC Plus IP1001 PHY is automatically enabled which will downshift to 100TX link when 1000baseT link establishment fails in auto-negotiation process. So can you confirm there is no cabling issues there? From owner-freebsd-net@FreeBSD.ORG Tue Nov 1 19:24:42 2011 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 0B53110656D0 for ; Tue, 1 Nov 2011 19:24:42 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.43]) by mx1.freebsd.org (Postfix) with SMTP id 5A4CC8FC1A for ; Tue, 1 Nov 2011 19:24:41 +0000 (UTC) Received: (qmail invoked by alias); 01 Nov 2011 19:24:39 -0000 Received: from adsl-32.109.242.162.tellas.gr (EHLO [192.168.73.192]) [109.242.162.32] by mail.gmx.com (mp-eu003) with SMTP; 01 Nov 2011 20:24:39 +0100 X-Authenticated: #46156728 X-Provags-ID: V01U2FsdGVkX1890+E9AhM9I8v6aop5IlQWugoWlOzNDcfY7MLm1Y zLtP/915Q9x9yS Message-ID: <4EB04770.9000805@gmx.com> Date: Tue, 01 Nov 2011 21:24:32 +0200 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bipin Patel References: <4EAFEA44.2070109@xbipin.com> <4eb004ff.0922cc0a.3a8a.ffff964e@mx.google.com> <4EB00E1A.308@xbipin.com> In-Reply-To: <4EB00E1A.308@xbipin.com> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-net@freebsd.org, Rozhuk.IM@gmail.com Subject: Re: pppoe reconnection issue 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, 01 Nov 2011 19:24:42 -0000 On 11/1/2011 5:19 PM, Bipin Patel wrote: > set link keep-alive 10 60 Lower these values according to: http://mpd.sourceforge.net/doc5/mpd20.html and then run mpd interactively to see what's happening. Nikos From owner-freebsd-net@FreeBSD.ORG Tue Nov 1 21:51:13 2011 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 2D768106564A for ; Tue, 1 Nov 2011 21:51:13 +0000 (UTC) (envelope-from prabhakar.lakhera@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id E9B2F8FC0C for ; Tue, 1 Nov 2011 21:51:12 +0000 (UTC) Received: by ggnq2 with SMTP id q2so9961810ggn.13 for ; Tue, 01 Nov 2011 14:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=jH4fivMSByXNNJq/zlpsYGlq4QV+90J0BswKfkwr/+g=; b=hWnToNo0smbIcM3bTV4mcv+duyS3HpMnRJIchSBBPPpMiGPrBU9AQs5LIf4Dr1x/4U BxllCHcLcy1m3SJgD6cRltUX2uJVrrZ54UOqjI81XSF+BxCnZVHrjFq777uWmAYmZrag GuNredLqBY1A0T4eGqzo7R+Thuf/sc2mh2lDU= MIME-Version: 1.0 Received: by 10.101.11.18 with SMTP id o18mr361617ani.86.1320182834015; Tue, 01 Nov 2011 14:27:14 -0700 (PDT) Received: by 10.100.48.17 with HTTP; Tue, 1 Nov 2011 14:27:13 -0700 (PDT) Date: Tue, 1 Nov 2011 14:27:13 -0700 Message-ID: From: prabhakar lakhera To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: mbuf leak in icmp6 code?? 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, 01 Nov 2011 21:51:13 -0000 Hi, In FreeBSD icmp6 code I see function where we are either going to freeit where passed mbuf is freed or we are simply returning. For example: icmp6_input calls icmp6_redirect_input and right after it returns it makes m=NULL. Inside icmp6_redirect_input there are checks for ifp and for the message being short (which probably don't get exercised that often (or at all?)) and for these checks simply return. Looks to be mbuf leak. In other icmp6 functions also we have similar instances. Just wanted to check if these are there undetected or not. This is my first mail to the BSD community so I am not sure if reporting this in the mail the right way. Please let me know. Best, Prabhakar From owner-freebsd-net@FreeBSD.ORG Wed Nov 2 02:07:09 2011 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 3ACFE106564A for ; Wed, 2 Nov 2011 02:07:09 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id AF6FD8FC15 for ; Wed, 2 Nov 2011 02:07:08 +0000 (UTC) Received: by wyg36 with SMTP id 36so1263830wyg.13 for ; Tue, 01 Nov 2011 19:07:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=XChjSS9d0Su4u5eNAIEjgR7ELH2WiOtbqLAp++pd/Mc=; b=wF1Fs1OK6Qzj4W8xiTxZh2wCg043W7Sben+OurUoZvmjyqGKKHbA0gDcUKf4mckmqx eEMbJuy1JyipThYjQMCadC5WJAqipMR0+QUQbSijHet/kueeBaJspfJJ/5cbC+KlOm1Z r/0zGNDzZEGTt5VdcvSFrcnbI8JgcWm7U5VmQ= Received: by 10.216.131.215 with SMTP id m65mr688884wei.5.1320199627535; Tue, 01 Nov 2011 19:07:07 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id es5sm1458656wbb.11.2011.11.01.19.07.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Nov 2011 19:07:05 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 01 Nov 2011 19:05:32 -0700 From: YongHyeon PYUN Date: Tue, 1 Nov 2011 19:05:32 -0700 To: Andrey Smagin Message-ID: <20111102020532.GF6914@michelle.cdnetworks.com> References: <20111031005519.GC1679@michelle.cdnetworks.com> <20111101180135.GD6914@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20111101180135.GD6914@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: PCI-E VT6130 NIC (if_vge) hang system with gigabit link 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: Wed, 02 Nov 2011 02:07:09 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Tue, Nov 01, 2011 at 11:01:35AM -0700, YongHyeon PYUN wrote: > On Mon, Oct 31, 2011 at 12:58:29PM +0400, Andrey Smagin wrote: > > > > > > > > 31 октября 2011, 04:56 от YongHyeon PYUN : > > > On Sat, Oct 29, 2011 at 09:57:30AM +0400, Andrey Smagin wrote: > > > > > > > > Ok. With autonegotiation ifconfig show speed 100MBit. > > > > > > And vge(4) work without problems with the resolved speed/duplex > > > of auto-negotiation? > > > > > > > with manual 1000baseT full-duplex settings in dmesg: > > > > vge0: failed to start MII autopoll > > > > vge0: MII read timed out > > > > vge0: failed to start MII autopoll > > > > vge0: link state changed to UP > > > > vge0: MII read timed out > > > > > > [...] > > > > > > Did vge(4) ever work with 1000baseT on your box? > > Hm... I never seen 1000baseT with vge on this box because > > it have only FreeBSD. > > > And why you have to manually configure 1000baseT link? > > With autonegatiation link stand on 100Mbit full-duplex > > > Does link partner(switch) also use auto-negotiation? > > In box also present Intel if_em gigabit and if_nfe gigabit card wich work with > > same cable and partner(switch) at gigabit speed. I only switch connector to if_vge socket. > > > > > > > I should have been more clearer. I wanted to know which previous > FreeBSD release was able to establish a 1000baseT link. > Downshifting feature of IC Plus IP1001 PHY is automatically enabled > which will downshift to 100TX link when 1000baseT link > establishment fails in auto-negotiation process. So can you confirm > there is no cabling issues there? If there is no cabling issue there, please try attached patch and let me know whether the patch makes any difference on you. Thanks. --GvXjxJ+pjyke8COw Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="vge.link.diff" Index: sys/dev/vge/if_vge.c =================================================================== --- sys/dev/vge/if_vge.c (revision 227010) +++ sys/dev/vge/if_vge.c (working copy) @@ -173,6 +173,7 @@ static void vge_freebufs(struct vge_softc *); static void vge_ifmedia_sts(struct ifnet *, struct ifmediareq *); static int vge_ifmedia_upd(struct ifnet *); +static int vge_ifmedia_upd_locked(struct vge_softc *); static void vge_init(void *); static void vge_init_locked(struct vge_softc *); static void vge_intr(void *); @@ -180,7 +181,6 @@ static int vge_ioctl(struct ifnet *, u_long, caddr_t); static void vge_link_statchg(void *); static int vge_miibus_readreg(device_t, int, int); -static void vge_miibus_statchg(device_t); static int vge_miibus_writereg(device_t, int, int, int); static void vge_miipoll_start(struct vge_softc *); static void vge_miipoll_stop(struct vge_softc *); @@ -190,6 +190,7 @@ static int vge_rx_list_init(struct vge_softc *); static int vge_rxeof(struct vge_softc *, int); static void vge_rxfilter(struct vge_softc *); +static void vge_setmedia(struct vge_softc *); static void vge_setvlan(struct vge_softc *); static void vge_setwol(struct vge_softc *); static void vge_start(struct ifnet *); @@ -218,7 +219,6 @@ /* MII interface */ DEVMETHOD(miibus_readreg, vge_miibus_readreg), DEVMETHOD(miibus_writereg, vge_miibus_writereg), - DEVMETHOD(miibus_statchg, vge_miibus_statchg), { 0, 0 } }; @@ -1102,7 +1102,7 @@ /* Do MII setup */ error = mii_attach(dev, &sc->vge_miibus, ifp, vge_ifmedia_upd, vge_ifmedia_sts, BMSR_DEFCAPMASK, sc->vge_phyaddr, MII_OFFSET_ANY, - 0); + MIIF_DOPAUSE); if (error != 0) { device_printf(dev, "attaching PHYs failed\n"); goto fail; @@ -1660,30 +1660,41 @@ { struct vge_softc *sc; struct ifnet *ifp; - struct mii_data *mii; + uint8_t physts; sc = xsc; ifp = sc->vge_ifp; VGE_LOCK_ASSERT(sc); - mii = device_get_softc(sc->vge_miibus); - mii_pollstat(mii); - if ((sc->vge_flags & VGE_FLAG_LINK) != 0) { - if (!(mii->mii_media_status & IFM_ACTIVE)) { + physts = CSR_READ_1(sc, VGE_PHYSTS0); + if ((physts & VGE_PHYSTS_RESETSTS) == 0) { + if ((physts & VGE_PHYSTS_LINK) == 0) { sc->vge_flags &= ~VGE_FLAG_LINK; if_link_state_change(sc->vge_ifp, LINK_STATE_DOWN); - } - } else { - if (mii->mii_media_status & IFM_ACTIVE && - IFM_SUBTYPE(mii->mii_media_active) != IFM_NONE) { + } else { sc->vge_flags |= VGE_FLAG_LINK; if_link_state_change(sc->vge_ifp, LINK_STATE_UP); + CSR_WRITE_1(sc, VGE_CRC2, VGE_CR2_FDX_TXFLOWCTL_ENABLE | + VGE_CR2_FDX_RXFLOWCTL_ENABLE); + if ((physts & VGE_PHYSTS_FDX) != 0) { + if ((physts & VGE_PHYSTS_TXFLOWCAP) != 0) + CSR_WRITE_1(sc, VGE_CRS2, + VGE_CR2_FDX_TXFLOWCTL_ENABLE); + if ((physts & VGE_PHYSTS_RXFLOWCAP) != 0) + CSR_WRITE_1(sc, VGE_CRS2, + VGE_CR2_FDX_RXFLOWCTL_ENABLE); + } if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) vge_start_locked(ifp); } } + /* + * Restart MII auto-polling because link state change interrupt + * will disable it. + */ + vge_miipoll_start(sc); } #ifdef DEVICE_POLLING @@ -2099,10 +2110,17 @@ vge_rxfilter(sc); vge_setvlan(sc); - /* Enable flow control */ + /* Initialize pause timer. */ + CSR_WRITE_2(sc, VGE_TX_PAUSE_TIMER, 0xFFFF); + /* + * Initialize flow control parameters. + * TX XON high threshold : 48 + * TX pause low threshold : 24 + * Disable hald-duplex flow control + */ + CSR_WRITE_1(sc, VGE_CRC2, 0xFF); + CSR_WRITE_1(sc, VGE_CRS2, VGE_CR2_XON_ENABLE | 0x0B); - CSR_WRITE_1(sc, VGE_CRS2, 0x8B); - /* Enable jumbo frame reception (if desired) */ /* Start the MAC. */ @@ -2129,7 +2147,7 @@ CSR_WRITE_1(sc, VGE_CRS3, VGE_CR3_INT_GMSK); sc->vge_flags &= ~VGE_FLAG_LINK; - mii_mediachg(mii); + vge_ifmedia_upd_locked(sc); ifp->if_drv_flags |= IFF_DRV_RUNNING; ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; @@ -2143,14 +2161,28 @@ vge_ifmedia_upd(struct ifnet *ifp) { struct vge_softc *sc; - struct mii_data *mii; int error; sc = ifp->if_softc; VGE_LOCK(sc); + error = vge_ifmedia_upd_locked(sc); + VGE_UNLOCK(sc); + + return (error); +} + +static int +vge_ifmedia_upd_locked(struct vge_softc *sc) +{ + struct mii_data *mii; + struct mii_softc *miisc; + int error; + mii = device_get_softc(sc->vge_miibus); + LIST_FOREACH(miisc, &mii->mii_phys, mii_list) + PHY_RESET(miisc); + vge_setmedia(sc); error = mii_mediachg(mii); - VGE_UNLOCK(sc); return (error); } @@ -2179,13 +2211,11 @@ } static void -vge_miibus_statchg(device_t dev) +vge_setmedia(struct vge_softc *sc) { - struct vge_softc *sc; struct mii_data *mii; struct ifmedia_entry *ife; - sc = device_get_softc(dev); mii = device_get_softc(sc->vge_miibus); ife = mii->mii_media.ifm_cur; @@ -2219,7 +2249,7 @@ } break; default: - device_printf(dev, "unknown media type: %x\n", + device_printf(sc->vge_dev, "unknown media type: %x\n", IFM_SUBTYPE(ife->ifm_media)); break; } @@ -2772,6 +2802,9 @@ break; } } + /* Clear forced MAC speed/duplex configuration. */ + CSR_CLRBIT_1(sc, VGE_DIAGCTL, VGE_DIAGCTL_MACFORCE); + CSR_CLRBIT_1(sc, VGE_DIAGCTL, VGE_DIAGCTL_FDXFORCE); vge_miibus_writereg(sc->vge_dev, sc->vge_phyaddr, MII_100T2CR, 0); vge_miibus_writereg(sc->vge_dev, sc->vge_phyaddr, MII_ANAR, ANAR_TX_FD | ANAR_TX | ANAR_10_FD | ANAR_10 | ANAR_CSMA); --GvXjxJ+pjyke8COw-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 2 05:19:22 2011 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 43E2A106566B for ; Wed, 2 Nov 2011 05:19:22 +0000 (UTC) (envelope-from bipin@xbipin.com) Received: from xbipin.com (xbipin.com [184.107.58.176]) by mx1.freebsd.org (Postfix) with SMTP id E915A8FC08 for ; Wed, 2 Nov 2011 05:19:21 +0000 (UTC) dkim-signature: v=1; a=rsa-sha256; d=xbipin.com; s=2009; c=relaxed/relaxed; q=dns/txt; h=From:Subject:Date:Message-ID:To:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; bh=a7QCX2NQqc0joyeF/xrwk4C0uv2jdgd+/7gnlf+FYmY=; b=TBx4V+4SljiwJE8drZSWzNF42yfEopKgEF407rJ6+Q5FguxaNqEZ+43Sqp7sfbjL5iLzC0JSqUeQtRwMS7ARTqhVHNQdadeQbU7t/erL7HUvhCfsok/BdAargRZULKmn Received: from [192.168.0.11] ([92.96.218.185]) by xbipin.com ; Wed, 2 Nov 2011 09:19:21 +0400 Message-ID: <4EB0D2D3.4050805@xbipin.com> Date: Wed, 02 Nov 2011 09:19:15 +0400 From: Bipin Patel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Sin , freebsd-net@freebsd.org References: <4EAFEA44.2070109@xbipin.com> <215C4C4E450545008A6CDD8E1C2E57F3@dts> In-Reply-To: <215C4C4E450545008A6CDD8E1C2E57F3@dts> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: pppoe reconnection issue 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, 02 Nov 2011 05:19:22 -0000 hi, pfsense uses mpd so is there anything equivalent to it? Regards, Bipin ------------------------------------------------------------------------ -------- Original Message -------- Subject: Re: pppoe reconnection issue From: Sin To: Bipin Patel Date: Tuesday, November 01, 2011 11:33:02 PM > I've been using FreeBSD since 4.7 with PPPoE on DSL. I noticed around > v5.5 I had this issue as well. I don't use mpd for the connection, but I > do use the user ppp program. The exact same problem would happen, since > that version of FreeBSD i've had to enable link quality and reporting in > my ppp.conf file: > > enable lqr > set lqrperiod 10 > > The extra traffic is minimal. > > ----- Original Message ----- From: "Bipin Patel" > To: > Sent: Tuesday, November 01, 2011 8:47 AM > Subject: pppoe reconnection issue > > >> >> hi, >> can some1 help or fix this issue mentioned here >> [1]http://forum.pfsense.org/index.php/topic,41061.0.html >> its something to do with freebsd and mpd which causes a pppoe >> connection not to reestablish once the modem is reset leaving behind a >> zombie connection which is only brought down with a link down, older >> freebsd used to perform this well along with the older mpd v4 i guess >> but this newer mpd v5.5 and newer bsd has this issue, it more over >> looks like a mpd issue and i was asked to bring up this in this >> mailing list as the developers at pfsense havent yet replied and there >> r quiet a few ppl suffering this including me >> >> -- >> Regards, >> Bipin >> _________________________________________________________________ >> >> References >> >> 1. http://forum.pfsense.org/index.php/topic,41061.0.html >> _______________________________________________ >> 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 Wed Nov 2 06:24:41 2011 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 65B35106566B; Wed, 2 Nov 2011 06:24:41 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id CD1318FC08; Wed, 2 Nov 2011 06:24:40 +0000 (UTC) Received: by wyg36 with SMTP id 36so1418329wyg.13 for ; Tue, 01 Nov 2011 23:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=uFII4oLw2YvdT6vn7xTQx8BClMfEzo728mXCAXdilkM=; b=XX1U9eocHeh7C4rEoG02eG5X2fgEDpu6bOb6Ufu8B2NSBsX0i9euxvDQ4M8keCb+Pm V27IeGVkke+Xxs1ZsFeMVb7GikQXY/mNuEF4bn3CWxT1xQdXdf+Ed09I8Mf9ahV+LGZw 9mzRMbWeqnMKUJIEQ/FOnhfyNHSzxV+s2d/Hs= MIME-Version: 1.0 Received: by 10.216.198.213 with SMTP id v63mr5383832wen.98.1320215079549; Tue, 01 Nov 2011 23:24:39 -0700 (PDT) Received: by 10.180.94.106 with HTTP; Tue, 1 Nov 2011 23:24:39 -0700 (PDT) In-Reply-To: <4EAF842D.3080909@freebsd.org> References: <4EAF842D.3080909@freebsd.org> Date: Wed, 2 Nov 2011 02:24:39 -0400 Message-ID: From: Arnaud Lacombe To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Undocumented netgraph `cmd' flags ? 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, 02 Nov 2011 06:24:41 -0000 Hi, On Tue, Nov 1, 2011 at 1:31 AM, Julian Elischer wrote: > On 10/31/11 4:16 PM, Arnaud Lacombe wrote: >> >> Hi Julian, >> >> For my information, is it documented anywhere that bit 28[0] and 29[1] >> of Netgraph message's `cmd' shall not be used (the bits, not the >> macros) ? >> >> Thanks, >> =A0- Arnaud >> >> [0]: NGM_READONLY >> [1]: NGM_HASREPLY >> > Not really sure what you are asking. > I may have turned the question in "why undocumented flags forbids me to use the full `int' range, as netgraph internals are using those bits for their internal mambo-jumbo, which is completely against POLA ?" > NGM_READONLY allows the base system to use a reader lock and not block ot= her > traffic while the message is bring processed. > NGM_HASREPLY is not used that I can see in the kernel. It may be a > historical artifact or > maybe only used in the library as a hint. > Well, I'm sorry, but this interface _sucks_. Now, I don't really know if I should thanks you for the misdesign, the undocumented behavior, or just for having costed me a whole afternoon trying to figure out why my program ended up not completing after sending `__INT_MAX-1' as a command :/ Anyway, we're stuck with that ABI. I'll try to see if I can find a way to document this in netgraph(4). - Arnaud > It has been so long since I was involved with netgraph (over a decade) th= at > I really don't remember. > From owner-freebsd-net@FreeBSD.ORG Wed Nov 2 07:35:55 2011 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 E317F106566B for ; Wed, 2 Nov 2011 07:35:55 +0000 (UTC) (envelope-from samspeed@mail.ru) Received: from f105.mail.ru (f105.mail.ru [94.100.178.74]) by mx1.freebsd.org (Postfix) with ESMTP id 547B68FC13 for ; Wed, 2 Nov 2011 07:35:55 +0000 (UTC) Received: from mail by f105.mail.ru with local id 1RLVMW-0000fD-00; Wed, 02 Nov 2011 11:35:52 +0400 Received: from [77.45.195.158] by e.mail.ru with HTTP; Wed, 02 Nov 2011 11:35:52 +0400 From: =?UTF-8?B?QW5kcmV5IFNtYWdpbg==?= To: pyunyh@gmail.com Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [77.45.195.158] Date: Wed, 02 Nov 2011 11:35:52 +0400 References: <20111101180135.GD6914@michelle.cdnetworks.com> In-Reply-To: <20111101180135.GD6914@michelle.cdnetworks.com> X-Priority: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Message-Id: X-Spam: Not detected X-Mras: Ok X-Mailman-Approved-At: Wed, 02 Nov 2011 10:58:57 +0000 Cc: freebsd-net@freebsd.org Subject: Re[2]: PCI-E VT6130 NIC (if_vge) hang system with gigabit link X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?UTF-8?B?QW5kcmV5IFNtYWdpbg==?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 07:35:56 -0000 CgoKMDEg0L3QvtGP0LHRgNGPIDIwMTEsIDIyOjAzINC+0YIgWW9uZ0h5ZW9uIFBZVU4gPHB5dW55 aEBnbWFpbC5jb20+Ogo+IE9uIE1vbiwgT2N0IDMxLCAyMDExIGF0IDEyOjU4OjI5UE0gKzA0MDAs IEFuZHJleSBTbWFnaW4gd3JvdGU6Cj4gPgo+ID4KPiA+Cj4gPiAzMSDQvtC60YLRj9Cx0YDRjyAy MDExLCAwNDo1NiDQvtGCIFlvbmdIeWVvbiBQWVVOIDxweXVueWhAZ21haWwuY29tPjoKPiA+ID4g T24gU2F0LCBPY3QgMjksIDIwMTEgYXQgMDk6NTc6MzBBTSArMDQwMCwgQW5kcmV5IFNtYWdpbiB3 cm90ZToKPiA+ID4gPgo+ID4gPiA+IE9rLiBXaXRoIGF1dG9uZWdvdGlhdGlvbiBpZmNvbmZpZyBz aG93IHNwZWVkIDEwME1CaXQuCj4gPiA+Cj4gPiA+IEFuZCB2Z2UoNCkgd29yayB3aXRob3V0IHBy b2JsZW1zIHdpdGggdGhlIHJlc29sdmVkIHNwZWVkL2R1cGxleAo+ID4gPiBvZiBhdXRvLW5lZ290 aWF0aW9uPwo+ID4gPgo+ID4gPiA+IHdpdGggbWFudWFsIDEwMDBiYXNlVCBmdWxsLWR1cGxleCBz ZXR0aW5ncyBpbiBkbWVzZzoKPiA+ID4gPiB2Z2UwOiBmYWlsZWQgdG8gc3RhcnQgTUlJIGF1dG9w b2xsCj4gPiA+ID4gdmdlMDogTUlJIHJlYWQgdGltZWQgb3V0Cj4gPiA+ID4gdmdlMDogZmFpbGVk IHRvIHN0YXJ0IE1JSSBhdXRvcG9sbAo+ID4gPiA+IHZnZTA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0 byBVUAo+ID4gPiA+IHZnZTA6IE1JSSByZWFkIHRpbWVkIG91dAo+ID4gPgo+ID4gPiBbLi4uXQo+ ID4gPgo+ID4gPiBEaWQgdmdlKDQpIGV2ZXIgd29yayB3aXRoIDEwMDBiYXNlVCBvbiB5b3VyIGJv eD8KPiA+IEhtLi4uIEkgbmV2ZXIgc2VlbiAxMDAwYmFzZVQgd2l0aCB2Z2Ugb24gdGhpcyBib3gg YmVjYXVzZQo+ID4gaXQgaGF2ZSBvbmx5IEZyZWVCU0QuCj4gPiA+IEFuZCB3aHkgeW91IGhhdmUg dG8gbWFudWFsbHkgY29uZmlndXJlIDEwMDBiYXNlVCBsaW5rPwo+ID4gV2l0aCBhdXRvbmVnYXRp YXRpb24gbGluayBzdGFuZCBvbiAxMDBNYml0IGZ1bGwtZHVwbGV4Cj4gPiA+IERvZXMgbGluayBw YXJ0bmVyKHN3aXRjaCkgYWxzbyB1c2UgYXV0by1uZWdvdGlhdGlvbj8KPiA+IEluIGJveCBhbHNv IHByZXNlbnQgSW50ZWwgaWZfZW0gZ2lnYWJpdCAgYW5kIGlmX25mZSBnaWdhYml0IGNhcmQgd2lj aCB3b3JrIHdpdGgKPiA+IHNhbWUgY2FibGUgYW5kIHBhcnRuZXIoc3dpdGNoKSBhdCBnaWdhYml0 IHNwZWVkLiBJIG9ubHkgc3dpdGNoIGNvbm5lY3RvciB0byBpZl92Z2Ugc29ja2V0Lgo+ID4gPgo+ ID4KPiAKPiBJIHNob3VsZCBoYXZlIGJlZW4gbW9yZSBjbGVhcmVyLiBJIHdhbnRlZCB0byBrbm93 IHdoaWNoIHByZXZpb3VzCj4gRnJlZUJTRCByZWxlYXNlIHdhcyBhYmxlIHRvIGVzdGFibGlzaCBh IDEwMDBiYXNlVCBsaW5rLgpJIHVwZ3JhZGUgRnJlZUJTRCwgYWZ0ZXIgc29tZSB0aW1lIHB1dCAy IFBDSS1FIHZnZSBjYXJkcyBpbiBib3ggdG8gcmVwbGFjZSAyIFBDSSBzdGdlIGNhcmRzLiAKPiBE b3duc2hpZnRpbmcgZmVhdHVyZSBvZiBJQyBQbHVzIElQMTAwMSBQSFkgaXMgYXV0b21hdGljYWxs eSBlbmFibGVkCj4gd2hpY2ggd2lsbCBkb3duc2hpZnQgdG8gMTAwVFggbGluayB3aGVuIDEwMDBi YXNlVCBsaW5rCj4gZXN0YWJsaXNobWVudCBmYWlscyBpbiBhdXRvLW5lZ290aWF0aW9uIHByb2Nl c3MuIFNvIGNhbiB5b3UgY29uZmlybQo+IHRoZXJlIGlzIG5vIGNhYmxpbmcgaXNzdWVzIHRoZXJl PwpDYWJsZSBhbmQgc3dpdGNoIDEwMCUgZ29vZC4gQW55IGFub3RoZXIgTklDKGVtLHN0Z2UsbmZl KSBpbiBib3ggc3VjY2VzZnVsbHkgY29ubmVjdGVkIGF0IDFHYiBhbmQgCnNwZWVkIG9mIHRyYW5z ZmVyIG1vcmUgdGhhbiA1MDBtYml0L3MgaW4gYW55IGRpcmVjdGlvbiwgYWx3YXlzLiA= From owner-freebsd-net@FreeBSD.ORG Wed Nov 2 17:00:22 2011 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 8CE95106566C for ; Wed, 2 Nov 2011 17:00:22 +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 71F618FC0A for ; Wed, 2 Nov 2011 17:00:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pA2H0MxQ043503 for ; Wed, 2 Nov 2011 17:00:22 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pA2H0MND043499; Wed, 2 Nov 2011 17:00:22 GMT (envelope-from gnats) Date: Wed, 2 Nov 2011 17:00:22 GMT Message-Id: <201111021700.pA2H0MND043499@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Andrey Zonov Cc: Subject: Re: kern/155585: [tcp] [panic] tcp_output tcp_mtudisc loop until kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrey Zonov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 17:00:22 -0000 The following reply was made to PR kern/155585; it has been noted by GNATS. From: Andrey Zonov To: bug-followup@FreeBSD.org, samspeed@mail.ru Cc: Subject: Re: kern/155585: [tcp] [panic] tcp_output tcp_mtudisc loop until kernel panic Date: Wed, 02 Nov 2011 20:54:15 +0400 This is a multi-part message in MIME format. --------------040501090905060606010708 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Andrey, Please try attached patch. I think the same problem was resolved here [1]. [1] http://svnweb.freebsd.org/base?view=revision&revision=178029 -- Andrey Zonov --------------040501090905060606010708 Content-Type: text/plain; name="patch-tcp_output.c.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch-tcp_output.c.txt" SW5kZXg6IHN5cy9uZXRpbmV0L3RjcF9vdXRwdXQuYwo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMv bmV0aW5ldC90Y3Bfb3V0cHV0LmMJKHJldmlzaW9uIDIyNzAyMCkKKysrIHN5cy9uZXRpbmV0 L3RjcF9vdXRwdXQuYwkod29ya2luZyBjb3B5KQpAQCAtMTc3LDggKzE3Nyw5IEBACiAJaW50 IGlkbGUsIHNlbmRhbG90OwogCWludCBzYWNrX3J4bWl0LCBzYWNrX2J5dGVzX3J4bXQ7CiAJ c3RydWN0IHNhY2tob2xlICpwOwotCWludCB0c287CisJaW50IHRzbywgbXR1LCBvZmZlcjsK IAlzdHJ1Y3QgdGNwb3B0IHRvOworCXN0cnVjdCByb3V0ZSBybzsKICNpZiAwCiAJaW50IG1h eGJ1cnN0ID0gVENQX01BWEJVUlNUOwogI2VuZGlmCkBAIC0yMTgsNiArMjE5LDcgQEAKIAkJ dGNwX3NhY2tfYWRqdXN0KHRwKTsKIAlzZW5kYWxvdCA9IDA7CiAJdHNvID0gMDsKKwltdHUg PSAwOwogCW9mZiA9IHRwLT5zbmRfbnh0IC0gdHAtPnNuZF91bmE7CiAJc2VuZHdpbiA9IG1p bih0cC0+c25kX3duZCwgdHAtPnNuZF9jd25kKTsKIApAQCAtMTIzMSw5ICsxMjMzLDE2IEBA CiAJaWYgKFZfcGF0aF9tdHVfZGlzY292ZXJ5ICYmIHRwLT50X21heG9wZCA+IFZfdGNwX21p bm1zcykKIAkJaXAtPmlwX29mZiB8PSBJUF9ERjsKIAotCWVycm9yID0gaXBfb3V0cHV0KG0s IHRwLT50X2lucGNiLT5pbnBfb3B0aW9ucywgTlVMTCwKKwliemVybygmcm8sIHNpemVvZihy bykpOworCisJZXJyb3IgPSBpcF9vdXRwdXQobSwgdHAtPnRfaW5wY2ItPmlucF9vcHRpb25z LCAmcm8sCiAJICAgICgoc28tPnNvX29wdGlvbnMgJiBTT19ET05UUk9VVEUpID8gSVBfUk9V VEVUT0lGIDogMCksIDAsCiAJICAgIHRwLT50X2lucGNiKTsKKworCWlmIChlcnJvciA9PSBF TVNHU0laRSAmJiByby5yb19ydCkKKwkJbXR1ID0gcm8ucm9fcnQtPnJ0X3JteC5ybXhfbXR1 OworCWlmIChyby5yb19ydCkKKwkJUlRGUkVFKHJvLnJvX3J0KTsKICAgICB9CiAjZW5kaWYg LyogSU5FVCAqLwogCWlmIChlcnJvcikgewpAQCAtMTI3OSwyMiArMTI4OCwyMCBAQAogCQkJ LyoKIAkJCSAqIEZvciBzb21lIHJlYXNvbiB0aGUgaW50ZXJmYWNlIHdlIHVzZWQgaW5pdGlh bGx5CiAJCQkgKiB0byBzZW5kIHNlZ21lbnRzIGNoYW5nZWQgdG8gYW5vdGhlciBvciBsb3dl cmVkCi0JCQkgKiBpdHMgTVRVLgotCQkJICoKLQkJCSAqIHRjcF9tdHVkaXNjKCkgd2lsbCBm aW5kIG91dCB0aGUgbmV3IE1UVSBhbmQgYXMKLQkJCSAqIGl0cyBsYXN0IGFjdGlvbiwgaW5p dGlhdGUgcmV0cmFuc21pc3Npb24sIHNvIGl0Ci0JCQkgKiBpcyBpbXBvcnRhbnQgdG8gbm90 IGRvIHNvIGhlcmUuCi0JCQkgKgotCQkJICogSWYgVFNPIHdhcyBhY3RpdmUgd2UgZWl0aGVy IGdvdCBhbiBpbnRlcmZhY2UKLQkJCSAqIHdpdGhvdXQgVFNPIGNhcGFiaWxpdHMgb3IgVFNP IHdhcyB0dXJuZWQgb2ZmLgotCQkJICogRGlzYWJsZSBpdCBmb3IgdGhpcyBjb25uZWN0aW9u IGFzIHRvbyBhbmQKLQkJCSAqIGltbWVkaWF0bHkgcmV0cnkgd2l0aCBNU1Mgc2l6ZWQgc2Vn bWVudHMgZ2VuZXJhdGVkCi0JCQkgKiBieSB0aGlzIGZ1bmN0aW9uLgorCQkJICogaXRzIE1U VS4gVXBkYXRlIHRfbWF4b3BkIGFuZCB0X21heHNlZyB0aHJvdWdoCisJCQkgKiB0Y3BfbXNz X3VwZGF0ZSgpIGFuZCB0cnkgdG8gc2VuZCBkYXRhIGFnYWluLgogCQkJICovCi0JCQlpZiAo dHNvKQotCQkJCXRwLT50X2ZsYWdzICY9IH5URl9UU087Ci0JCQl0Y3BfbXR1ZGlzYyh0cC0+ dF9pbnBjYiwgMCk7Ci0JCQlyZXR1cm4gKDApOworCQkJaWYgKG10dSAhPSAwKSB7CisJCQkJ b2ZmZXIgPSBtdHUgLSBoZHJsZW47CisJCQkJaWYgKCh0cC0+dF9mbGFncyAmIFRGX1JDVkRf VFNUTVApID09IFRGX1JDVkRfVFNUTVApCisJCQkJCW9mZmVyICs9IFRDUE9MRU5fVFNUQU1Q X0FQUEE7CisJCQkJdGNwX21zc191cGRhdGUodHAsIG9mZmVyLCBOVUxMLCBOVUxMKTsKKwkJ CQlnb3RvIGFnYWluOworCQkJfQorCQkJLyoKKwkJCSAqIFRoaXMgaXMgdGhlIGJlc3Qgd2Ug Y2FuIGRvIGhlcmUuCisJCQkgKi8KKwkJCXJldHVybiAoZXJyb3IpOwogCQljYXNlIEVIT1NU RE9XTjoKIAkJY2FzZSBFSE9TVFVOUkVBQ0g6CiAJCWNhc2UgRU5FVERPV046Cg== --------------040501090905060606010708-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 3 09:50:29 2011 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 2D46E1065670; Thu, 3 Nov 2011 09:50:29 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 05DEB8FC12; Thu, 3 Nov 2011 09:50:29 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pA39oSL3015476; Thu, 3 Nov 2011 09:50:28 GMT (envelope-from melifaro@freefall.freebsd.org) Received: (from melifaro@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pA39oSso015467; Thu, 3 Nov 2011 09:50:28 GMT (envelope-from melifaro) Date: Thu, 3 Nov 2011 09:50:28 GMT Message-Id: <201111030950.pA39oSso015467@freefall.freebsd.org> To: melifaro@FreeBSD.org, freebsd-net@FreeBSD.org, melifaro@FreeBSD.org From: melifaro@FreeBSD.org Cc: Subject: Re: bin/136661: [patch] ndp(8) ignores -f option 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, 03 Nov 2011 09:50:29 -0000 Synopsis: [patch] ndp(8) ignores -f option Responsible-Changed-From-To: freebsd-net->melifaro Responsible-Changed-By: melifaro Responsible-Changed-When: Thu Nov 3 09:49:06 UTC 2011 Responsible-Changed-Why: Take my own PR http://www.freebsd.org/cgi/query-pr.cgi?pr=136661 From owner-freebsd-net@FreeBSD.ORG Thu Nov 3 09:53:22 2011 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 CF9401065672; Thu, 3 Nov 2011 09:53:22 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A5EA08FC08; Thu, 3 Nov 2011 09:53:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pA39rMir021982; Thu, 3 Nov 2011 09:53:22 GMT (envelope-from melifaro@freefall.freebsd.org) Received: (from melifaro@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pA39rMOh021978; Thu, 3 Nov 2011 09:53:22 GMT (envelope-from melifaro) Date: Thu, 3 Nov 2011 09:53:22 GMT Message-Id: <201111030953.pA39rMOh021978@freefall.freebsd.org> To: samspeed@mail.ru, melifaro@FreeBSD.org, freebsd-net@FreeBSD.org, melifaro@FreeBSD.org From: melifaro@FreeBSD.org Cc: Subject: Re: kern/155585: [tcp] [panic] tcp_output tcp_mtudisc loop until kernel panic 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, 03 Nov 2011 09:53:22 -0000 Synopsis: [tcp] [panic] tcp_output tcp_mtudisc loop until kernel panic State-Changed-From-To: open->feedback State-Changed-By: melifaro State-Changed-When: Thu Nov 3 09:52:26 UTC 2011 State-Changed-Why: Take Responsible-Changed-From-To: freebsd-net->melifaro Responsible-Changed-By: melifaro Responsible-Changed-When: Thu Nov 3 09:52:26 UTC 2011 Responsible-Changed-Why: Take http://www.freebsd.org/cgi/query-pr.cgi?pr=155585 From owner-freebsd-net@FreeBSD.ORG Thu Nov 3 06:47:28 2011 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 29AC2106566C for ; Thu, 3 Nov 2011 06:47:28 +0000 (UTC) (envelope-from rejithomas.d@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B08B78FC13 for ; Thu, 3 Nov 2011 06:47:27 +0000 (UTC) Received: by bkbzs2 with SMTP id zs2so1123002bkb.13 for ; Wed, 02 Nov 2011 23:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=iRg9+q8HUFZil40+fyLdY2Ohnh+oUmDrzrTyLOs8iSU=; b=Qrs0w53X2Q4Al1UUGqQEE8D1iL+DvR3RzPf6WOT4sN6VARDdQ5/0MJreiAMK6jPcG/ rNYkcwKgsmruObiomdEiEV17DtenVEacE3BYBPNSux1I35ubOwH3GAK9159vsAc8smez SPQzo9TFf4vGUlS8Rartw766/u/VawWEA2tr0= MIME-Version: 1.0 Received: by 10.204.136.152 with SMTP id r24mr6595233bkt.5.1320301001685; Wed, 02 Nov 2011 23:16:41 -0700 (PDT) Received: by 10.204.51.135 with HTTP; Wed, 2 Nov 2011 23:16:41 -0700 (PDT) Date: Thu, 3 Nov 2011 11:46:41 +0530 Message-ID: From: Reji Thomas To: freebsd-net@freebsd.org X-Mailman-Approved-At: Thu, 03 Nov 2011 11:44:26 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Doubt regarding key_do_allocsa_policy in ipsec path 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, 03 Nov 2011 06:47:28 -0000 Hi, The key_do_allocsa_policy searches and deletes the non preferred sas if there are multiple sas that match the search parameters . I see that if there are multiple sas of same parameters established between end points, this end up in deletion of all "outbound sa" but the preferred sa. Since the deletion occurs only on the outbound sa, this ends up in a scenario where the corresponding inbound ipsec sas gets unpaired and not cleaned up particularly when the ike daemon doesnt send a delete notification of sa to the other peer. ( racoon2 ikev1 doesnt seem to do this). In such a scenario, what should be the proper thing to do?. 1. Make sure that a delete notification is sent by the iked so that the peers can cleanup the unpaired sa. 2. Since ipsec sas are always paired, should we delete the unpaired sa in the kernel at the same time? Thanks Reji From owner-freebsd-net@FreeBSD.ORG Thu Nov 3 12:07:55 2011 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 7B3FE1065670 for ; Thu, 3 Nov 2011 12:07:55 +0000 (UTC) (envelope-from kp@sigsegv.be) Received: from mercury.codepro.be (mercury.codepro.be [IPv6:2001:4b98:dc0:51:216:3eff:feb7:3147]) by mx1.freebsd.org (Postfix) with ESMTP id 148108FC27 for ; Thu, 3 Nov 2011 12:07:55 +0000 (UTC) Received: from adrastea.jupiter.sigsegv.be (adrastea.jupiter.sigsegv.be [IPv6:2001:6f8:1498:1::3]) by mercury.codepro.be (Postfix) with ESMTP id 62A09361; Thu, 3 Nov 2011 13:07:53 +0100 (CET) Received: from thebe.jupiter.sigsegv.be (thebe.jupiter.sigsegv.be [172.16.1.5]) by adrastea.jupiter.sigsegv.be (Postfix) with ESMTP id CE9EF5953; Thu, 3 Nov 2011 13:07:52 +0100 (CET) Received: by thebe.jupiter.sigsegv.be (Postfix, from userid 1000) id A826525308; Thu, 3 Nov 2011 13:07:52 +0100 (CET) Date: Thu, 3 Nov 2011 13:07:52 +0100 From: Kristof Provost To: prabhakar lakhera Message-ID: <20111103120752.GG9553@thebe.jupiter.sigsegv.be> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org Subject: Re: mbuf leak in icmp6 code?? 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, 03 Nov 2011 12:07:55 -0000 On 2011-11-01 14:27:13 (-0700), prabhakar lakhera wrote: > In FreeBSD icmp6 code I see function where we are either going to > freeit where passed mbuf is freed or we are simply returning. > For example: > > icmp6_input calls icmp6_redirect_input and right after it returns it > makes m=NULL. Inside icmp6_redirect_input there are checks for ifp and > for the message being short (which probably don't get exercised that > often (or at all?)) and for these checks simply return. Looks to be > mbuf leak. In other icmp6 functions also we have similar instances. The checks for m and ifp should probably be asserts, rather than just returns. I think they are always supposed to be true. You do have a point with the message length check, but that's only true if PULLDOWN_TEST is set. IP_EXTHDR_CHECK does free the mbuf is the message is too short. Regards, Kristof From owner-freebsd-net@FreeBSD.ORG Thu Nov 3 13:27:46 2011 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 633B1106564A for ; Thu, 3 Nov 2011 13:27:46 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 165E48FC08 for ; Thu, 3 Nov 2011 13:27:45 +0000 (UTC) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id 2832A2798BD for ; Thu, 3 Nov 2011 14:09:05 +0100 (CET) Received: by astro.zen.inc (Postfix, from userid 1000) id BC5F517055; Thu, 3 Nov 2011 14:09:04 +0100 (CET) Date: Thu, 3 Nov 2011 14:09:04 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20111103130904.GA50156@zeninc.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: All mail clients suck. This one just sucks less. Subject: Re: Doubt regarding key_do_allocsa_policy in ipsec path 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, 03 Nov 2011 13:27:46 -0000 On Thu, Nov 03, 2011 at 11:46:41AM +0530, Reji Thomas wrote: > Hi, Hi. > The key_do_allocsa_policy searches and deletes the non preferred sas if > there are multiple sas that match the search parameters . I see that if > there are multiple sas of same parameters established between end points, > this end up in deletion of all "outbound sa" but the preferred sa. Yes. > Since > the deletion occurs only on the outbound sa, this ends up in a scenario > where the corresponding inbound ipsec sas gets unpaired and not cleaned up > particularly when the ike daemon doesnt send a delete notification of sa to > the other peer. ( racoon2 ikev1 doesnt seem to do this). Yep, some peers may generate that situation. > In such a scenario, what should be the proper thing to do?. Nothing :-) To be more exact: just wait until the lifetime of the old SA expires..... > 1. Make sure that a delete notification is sent by the iked so that the > peers can cleanup the unpaired sa. You can make sure you sent a DELETE_SA, but you can't be sure peer received it and correctly handled it. And if you're takling about sending a DELETE_SA for your inbound SA..... yes, you could do that, but why ? And what will you do if your peer doesn't get/handle the DELETE_SA and continue using the old SA for it's outgoing packets ? > 2. Since ipsec sas are always paired, should we delete the unpaired sa in > the kernel at the same time? In the real world, almost all SAs are "paired" when you negociate them. But you can't just consider SAs will always be aired. For example, if you have "use_oldsa == 0" and your peer have "use_oldsa == 1" (or whatever else which will generate a similar result), you're right when you decide to delete your outbound SA, because you are sure that you won't use it again, but your peer will still use it's old outbound SA, which is your old inbount SA. The only situation I see where this may become a real issue is if you start negociating with no lifetime, but only lifebyte.... just forget that kind of situation, it will lead you to other issues ! Yvan. From owner-freebsd-net@FreeBSD.ORG Thu Nov 3 16:37:39 2011 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 91017106564A for ; Thu, 3 Nov 2011 16:37:39 +0000 (UTC) (envelope-from prvs=2816a1e84=david.hooton@platformnetworks.net) Received: from inbound.spambox.com.au (inbound.spambox.com.au [202.62.145.154]) by mx1.freebsd.org (Postfix) with ESMTP id 129818FC15 for ; Thu, 3 Nov 2011 16:37:38 +0000 (UTC) X-SBRS: None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAHAFG7sk7KPpZI/2dsb2JhbABEgk2oKYIAJ2QBDHQnBC6caKAQiR8EpX0 Received: from wiggum.plat.net.au (HELO WIGGUM.syd01.office.plat.net.au.local) ([202.62.150.72]) by outbound.spambox.com.au with ESMTP; 04 Nov 2011 03:07:51 +1100 Received: from wiggum.syd01.office.plat.net.au.local ([202.62.150.72]) by WIGGUM.syd01.office.plat.net.au.local ([202.62.150.72]) with mapi id 14.01.0339.001; Fri, 4 Nov 2011 03:07:50 +1100 From: David Hooton To: "freebsd-net@freebsd.org" Thread-Topic: MPD LAC Scaling Thread-Index: AQHMmkK7c1NpwlJRXka4K3YtrbbQPA== Date: Thu, 3 Nov 2011 16:07:49 +0000 Message-ID: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [116.6.31.130] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: MPD LAC Scaling 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, 03 Nov 2011 16:37:39 -0000 Hi All, I'm currently evaluating MPD as a potential LAC solution for a project I'm = working on. I'm looking to try and handle at least 4Gbit and 20,000 sessio= ns worth of PPPoE -> L2TP LAC traffic per server. The reading I've done fr= om the archives so far seems to indicate that this has not yet been done.. So my questions to you are: A) Can it be done? B) Am I crazy? C) What is the most sessions and traffic an MPD install is doing that you'r= e aware of? C) What kind of hardware is required? D) What MPD and BSD configurations would you recommend? E) How would I load test such a configuration? I'm hoping to start testing our options very shortly and am willing to cont= ribute development time & effort if required to make it happen. Thanks for= your help! -- Cheers! Dave From owner-freebsd-net@FreeBSD.ORG Thu Nov 3 20:43:02 2011 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 C16761065670 for ; Thu, 3 Nov 2011 20:43:02 +0000 (UTC) (envelope-from slonoman2011@yandex.ru) Received: from forward14.mail.yandex.net (forward14.mail.yandex.net [IPv6:2a02:6b8:0:801::4]) by mx1.freebsd.org (Postfix) with ESMTP id 41B928FC0C for ; Thu, 3 Nov 2011 20:43:02 +0000 (UTC) Received: from web142.yandex.ru (web142.yandex.ru [95.108.130.10]) by forward14.mail.yandex.net (Yandex) with ESMTP id 8CE0319841C0 for ; Fri, 4 Nov 2011 00:43:00 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1320352980; bh=jz3g3b7cEXAz5mbTwQjmFgE8Ohrb54PNR7tjMIbUJGA=; h=From:To:Subject:MIME-Version:Message-Id:Date: Content-Transfer-Encoding:Content-Type; b=SVTelsLZ0j/alg+ShPibZUPzTtx3wPCeekiHQs99LKSsler2l7EWMh0X6H2CtmPOE uw3lZOv2oPQXbfAtCX6Y8EWhPaOlFaexnGsXU6RKb8xLnBpggrKe/yM244/Yvx1ZAg JHKq5ajaOu7RtmhJj2sVMWMnmWpb8WQ65Eg1XOSY= Received: from localhost (localhost.localdomain [127.0.0.1]) by web142.yandex.ru (Yandex) with ESMTP id 760F9301803C for ; Fri, 4 Nov 2011 00:43:00 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1320352980; bh=jz3g3b7cEXAz5mbTwQjmFgE8Ohrb54PNR7tjMIbUJGA=; h=From:To:Subject:MIME-Version:Message-Id:Date: Content-Transfer-Encoding:Content-Type; b=SVTelsLZ0j/alg+ShPibZUPzTtx3wPCeekiHQs99LKSsler2l7EWMh0X6H2CtmPOE uw3lZOv2oPQXbfAtCX6Y8EWhPaOlFaexnGsXU6RKb8xLnBpggrKe/yM244/Yvx1ZAg JHKq5ajaOu7RtmhJj2sVMWMnmWpb8WQ65Eg1XOSY= X-Yandex-Spam: 1 Received: from nat140-249-205-109.tvoe.tv (nat140-249-205-109.tvoe.tv [109.205.249.140]) by web142.yandex.ru with HTTP; Fri, 04 Nov 2011 00:43:00 +0400 From: Slono Slono To: freebsd-net@freebsd.org MIME-Version: 1.0 Message-Id: <85301320352980@web142.yandex.ru> Date: Fri, 04 Nov 2011 00:43:00 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Subject: arp code broken after BETA3 9.0 ? 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, 03 Nov 2011 20:43:02 -0000 After upgrade procedure from BETA3 to RC1 ive get similar problem like http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/162267 Looks like problem outside the MPD code which have not changed a long time. Ive browse SVN history and has found out recent changes in sys/netinet/in.c code which could affect occurrence kernel panic in RC1. http://svnweb.freebsd.org/base/head/sys/netinet/in.c?r1=226120&r2=226119&pathrev=226120 http://svnweb.freebsd.org/base/head/sys/netinet/in.c?r1=225946&r2=225945&pathrev=225946 Somebody else has met this problem? Thanks. From owner-freebsd-net@FreeBSD.ORG Thu Nov 3 21:25:08 2011 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 25278106566C; Thu, 3 Nov 2011 21:25:08 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 04CE08FC0C; Thu, 3 Nov 2011 21:25:07 +0000 (UTC) Received: from PWSVL-EXCHTS-02.internal.cacheflow.com (sai-rp.bluecoat.com [10.2.2.126] (may be forged)) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id pA3LP63M010596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Nov 2011 14:25:06 -0700 (PDT) Received: from PWSVL-EXCMBX-01.internal.cacheflow.com ([fe80::15bc:12e2:4676:340f]) by PWSVL-EXCHTS-02.internal.cacheflow.com ([fe80::4910:317f:407:6ecc%14]) with mapi id 14.01.0289.001; Thu, 3 Nov 2011 14:25:01 -0700 From: "Li, Qing" To: Slono Slono , "freebsd-net@freebsd.org" Thread-Topic: arp code broken after BETA3 9.0 ? Thread-Index: AQHMmmlAC9rNUxzAt0qh1FqDih+nv5WbqKp+ Date: Thu, 3 Nov 2011 21:25:00 +0000 Message-ID: References: <85301320352980@web142.yandex.ru> In-Reply-To: <85301320352980@web142.yandex.ru> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.52.23.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "qingli@freebsd.org" Subject: RE: arp code broken after BETA3 9.0 ? 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, 03 Nov 2011 21:25:08 -0000 Could you please apply this patch=0A= =0A= http://svnweb.freebsd.org/base?view=3Drevision&revision=3D227002=0A= =0A= and let me know how it works out for you ?=0A= =0A= Thanks,=0A= =0A= --Qing=0A= =0A= ________________________________________=0A= From: owner-freebsd-net@freebsd.org [owner-freebsd-net@freebsd.org] on beha= lf of Slono Slono [slonoman2011@yandex.ru]=0A= Sent: Thursday, November 03, 2011 1:43 PM=0A= To: freebsd-net@freebsd.org=0A= Subject: arp code broken after BETA3 9.0 ?=0A= =0A= After upgrade procedure from BETA3 to RC1 ive get similar problem like http= ://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/162267=0A= Looks like problem outside the MPD code which have not changed a long time.= Ive browse SVN history and has found out recent=0A= changes in sys/netinet/in.c code which could affect occurrence kernel panic= in RC1.=0A= =0A= http://svnweb.freebsd.org/base/head/sys/netinet/in.c?r1=3D226120&r2=3D22611= 9&pathrev=3D226120=0A= http://svnweb.freebsd.org/base/head/sys/netinet/in.c?r1=3D225946&r2=3D22594= 5&pathrev=3D225946=0A= =0A= Somebody else has met this problem? Thanks.=0A= _______________________________________________=0A= freebsd-net@freebsd.org mailing list=0A= http://lists.freebsd.org/mailman/listinfo/freebsd-net=0A= To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"=0A= From owner-freebsd-net@FreeBSD.ORG Fri Nov 4 10:29:33 2011 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 064721065676 for ; Fri, 4 Nov 2011 10:29:33 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop03.sare.net (proxypop03.sare.net [194.30.0.207]) by mx1.freebsd.org (Postfix) with ESMTP id BED2C8FC14 for ; Fri, 4 Nov 2011 10:29:32 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop03.sare.net (Postfix) with ESMTPSA id D111B9DC5B6 for ; Fri, 4 Nov 2011 11:13:33 +0100 (CET) From: Borja Marcos Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Nov 2011 11:13:21 +0100 Message-Id: To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: FreeBSD 9-RC1, openbgpd, tcp md5 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, 04 Nov 2011 10:29:33 -0000 Hi I'm testing a set up for OpenBGPd with FreeBSD 9-RC1 (amd64). For now = I'm trying on two virtual machines. Using the stock GENERIC kernel it = works, although of course it doesn't have TCP MD5 support, which I = require. I've compiled new kernels with the TCP MD5 support (options IPSEC, = device crypto and options TCP_SIGNATURE), and after installing it on = both machines OpenBGPd no longer works. No matter if I try to configure = the bgp sessions with TCP-MD5 or not, the sessions won't work. Any ideas? As far as I know, this shoud work. The daemon is complaning = that there's no kernel support for pf_key. FreeBSD pruebazfs3 9.0-RC1 FreeBSD 9.0-RC1 #10: Fri Nov 4 10:32:41 UTC = 2011 borjam@pruebazfs1:/usr/obj/rpool/newsrc/src/sys/GENERIC amd64 Thanks, Borja. =20= From owner-freebsd-net@FreeBSD.ORG Fri Nov 4 12:57:06 2011 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 569B6106564A for ; Fri, 4 Nov 2011 12:57:06 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [94.23.254.147]) by mx1.freebsd.org (Postfix) with ESMTP id 1DB848FC0C for ; Fri, 4 Nov 2011 12:57:05 +0000 (UTC) Received: from mr12941.univ-rennes1.fr (mr129041.cri.univ-rennes1.fr [129.20.129.41]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 1DF7EFAA31A5; Fri, 4 Nov 2011 13:41:40 +0100 (CET) Received: from mr12941 (localhost.localdomain [127.0.0.1]) by mr12941.univ-rennes1.fr (Postfix) with ESMTP id B80717A00BE; Fri, 4 Nov 2011 13:41:39 +0100 (CET) Date: Fri, 4 Nov 2011 13:41:39 +0100 From: Patrick Lamaiziere To: freebsd-net@freebsd.org Message-ID: <20111104134139.0836f380@mr12941> In-Reply-To: References: X-Mailer: Claws Mail 3.7.8 (GTK+ 2.24.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Borja Marcos Subject: Re: FreeBSD 9-RC1, openbgpd, tcp md5 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, 04 Nov 2011 12:57:06 -0000 Le Fri, 4 Nov 2011 11:13:21 +0100, Borja Marcos a écrit : > I'm testing a set up for OpenBGPd with FreeBSD 9-RC1 (amd64). For now > I'm trying on two virtual machines. Using the stock GENERIC kernel it > works, although of course it doesn't have TCP MD5 support, which I > require. > > I've compiled new kernels with the TCP MD5 support (options IPSEC, > device crypto and options TCP_SIGNATURE), and after installing it on > both machines OpenBGPd no longer works. No matter if I try to > configure the bgp sessions with TCP-MD5 or not, the sessions won't > work. > > Any ideas? As far as I know, this shoud work. The daemon is > complaning that there's no kernel support for pf_key. Isn't a new option to build openbgpd with tcp-md5 (and without pf_key)? I've used TCP-MD5 signature for bgp between a FreeBSD 8.x and OpenBSD, using setkey(8) to enforce the signature between the peers. That worked (of course, then you shouldn't use tcp-md5 in openbgd). setkey(8): add -4 peer1 peer2 tcp 0x1000 -A tcp-md5 "PASSWORD"; add -4 peer2 peer1 tcp 0x1000 -A tcp-md5 "PASSWORD"; kernconf: # In order to enable IPSEC you MUST also add device crypto to # your kernel configuration options IPSEC #IP security (requires device crypto) device crypto options TCP_SIGNATURE #include support for RFC 2385 Regards. From owner-freebsd-net@FreeBSD.ORG Sat Nov 5 05:58:32 2011 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 2725F1065670 for ; Sat, 5 Nov 2011 05:58:32 +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 EFEB68FC16 for ; Sat, 5 Nov 2011 05:58:31 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id pA55wQlL024072 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 4 Nov 2011 22:58:27 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4EB4D084.1080309@freebsd.org> Date: Fri, 04 Nov 2011 22:58:28 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: David Hooton References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: MPD LAC Scaling 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, 05 Nov 2011 05:58:32 -0000 On 11/3/11 9:07 AM, David Hooton wrote: > Hi All, > > I'm currently evaluating MPD as a potential LAC solution for a project I'm working on. I'm looking to try and handle at least 4Gbit and 20,000 sessions worth of PPPoE -> L2TP LAC traffic per server. The reading I've done from the archives so far seems to indicate that this has not yet been done.. probably not with a single machine but it should be possible to use several machines and pppoe is designed to allow multiple providers to co-exist on the same network. 20,000 is probably high.. I've heard of 8000 but I have no idea of how well it worked or what they had to tweek.. 4Gb is also pushing it if you want to be dong other work at the same time. having said that, maybe 3 fast machines together could do it.. "maybe" becasue I haven't tried using those components since I wrote the pppoe module in '97 and a lot has changed since then. > So my questions to you are: > A) Can it be done? > "maybe" > B) Am I crazy? "Optimistic" > C) What is the most sessions and traffic an MPD install is doing that you're aware of? several thousand sessions but no idea of the aggregate throughput. > C) What kind of hardware is required? fast :-) > D) What MPD and BSD configurations would you recommend? can't help > E) How would I load test such a configuration? > I'm hoping to start testing our options very shortly and am willing to contribute development time& effort if required to make it happen. Thanks for your help! > -- > Cheers! > > Dave julian > _______________________________________________ > 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 Nov 5 12:20:07 2011 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 356BE106566C for ; Sat, 5 Nov 2011 12:20:07 +0000 (UTC) (envelope-from bevan@bi-co.net) Received: from tomahna.bi-co.net (tomahna.bi-co.net [178.77.99.158]) by mx1.freebsd.org (Postfix) with ESMTP id 882EF8FC0A for ; Sat, 5 Nov 2011 12:20:06 +0000 (UTC) Received: (qmail 10098 invoked from network); 5 Nov 2011 12:53:24 +0100 Received: from ip-109-91-30-235.unitymediagroup.de (HELO ?192.168.178.21?) (109.91.30.235) by tomahna.bi-co.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 5 Nov 2011 12:53:24 +0100 Message-ID: <1320494003.19667.41.camel@bevan-pc.fritz.box> From: Michael =?ISO-8859-1?Q?La=DF?= To: freebsd-net@freebsd.org Date: Sat, 05 Nov 2011 12:53:23 +0100 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.1 Content-Transfer-Encoding: 8bit Mime-Version: 1.0 Subject: Gigabit Ethernet performance with Realtek 8111E X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bevan@bi-co.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 12:20:07 -0000 Hi! I've got a small NAS with Intel D525MW (Atom) board inside using FreeBSD 9.0-RC1 as operating system. It has an onboard Realtek 8111E ethernet adapter. I'm experiencing heavy performance problems when transfering files from a specific PC in my network to that NAS. I did the following tests by transfering large amount of data between the diferrent machines (using dd and nc): NAS -> Linux1: ~ 400Mbit/s NAS -> Linux2: ~ 400Mbit/s Linux1 -> NAS: heavy fluctuation, between 700Mbit/s and 0bit/s Linux2 -> NAS: ~ 400Mbit/s Linux1 -> Linux2: ~ 400Mbit/s Linux2 -> Linux1: ~ 400Mbit/s As you can see everythink works fine except for transfering data from Linux1 to that NAS box. The following graph shows the problem: http://dl.dropbox.com/u/25455527/network-problems.png While the transfer rate drops to zero the NAS also has a very bad ping up to one second. Ping of Linux1 is perfectly fine during these outages. I also had a quick look on the data stream with wireshark on Linux1 and it shows a lot of TCP Dup ACK (up to 263 Dup ACKs created by NAS for one frame). What can be eliminated as a cause is: - Switch (I tried connecting Linux1 and NAS directly) - Cable (I changed that a few times) - Harddisk I/O (I'm only writing from /dev/zero to /dev/null) The sevirity of that problem varies from one minute to another but can always be reproduced with a few tries. When limiting either NAS or Linux1 to 100Mbit I'm getting a steady transfer rate of about 90Mbit/s. When decreasing the MTU on NAS to 1200 the problem seems to disappear, getting a transfer rate of about 160Mbit/s. ifconfig re0: > re0: flags=8843 metric 0 mtu 1500 > options=388b > ether 38:60:77:3e:af:a5 > inet 192.168.178.54 netmask 0xffffff00 broadcast 192.168.178.255 > nd6 options=29 > media: Ethernet autoselect (1000baseT ) > status: active pciconf -lv: > re0@pci0:1:0:0: class=0x020000 card=0xd6258086 chip=0x816810ec rev=0x06 hdr=0x00 > vendor = 'Realtek Semiconductor Co., Ltd.' > device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' > class = network > subclass = ethernet Because Linux1 seems to be involved in that problem: It's running Linux 3.0 and it has an "Atheros Communications AR8121/AR8113/AR8114" onboard. Does anyone have an idea what could be the problem here? Decreasing the MTU is some kind of solution but the performance is still not optimal and a MTU of 1500 should be no problem. Greetings, Michael Laß From owner-freebsd-net@FreeBSD.ORG Sat Nov 5 15:32:43 2011 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 AB3D4106564A for ; Sat, 5 Nov 2011 15:32:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 65CE28FC1E for ; Sat, 5 Nov 2011 15:32:43 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAKRPtU6DaFvO/2dsb2JhbABDhHqjboIlgXIBAQEBAgEBAQEgBCcgCwUWGAICDRkCKQEJJg4CBQQBGgIEh2EIpGeRF4EwhmWBFgSSBIIdkgg X-IronPort-AV: E=Sophos;i="4.69,460,1315195200"; d="scan'208";a="142792502" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 05 Nov 2011 11:03:50 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E85EDB3F06; Sat, 5 Nov 2011 11:03:50 -0400 (EDT) Date: Sat, 5 Nov 2011 11:03:50 -0400 (EDT) From: Rick Macklem To: bevan@bi-co.net Message-ID: <1893638131.1215459.1320505430915.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1320494003.19667.41.camel@bevan-pc.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-net@freebsd.org Subject: Re: Gigabit Ethernet performance with Realtek 8111E 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, 05 Nov 2011 15:32:43 -0000 bevan wrote: > Hi! >=20 > I've got a small NAS with Intel D525MW (Atom) board inside using > FreeBSD > 9.0-RC1 as operating system. It has an onboard Realtek 8111E ethernet > adapter. I'm experiencing heavy performance problems when transfering > files from a specific PC in my network to that NAS. I did the > following > tests by transfering large amount of data between the diferrent > machines > (using dd and nc): >=20 > NAS -> Linux1: ~ 400Mbit/s > NAS -> Linux2: ~ 400Mbit/s > Linux1 -> NAS: heavy fluctuation, between 700Mbit/s and 0bit/s > Linux2 -> NAS: ~ 400Mbit/s > Linux1 -> Linux2: ~ 400Mbit/s > Linux2 -> Linux1: ~ 400Mbit/s >=20 > As you can see everythink works fine except for transfering data from > Linux1 to that NAS box. The following graph shows the problem: > http://dl.dropbox.com/u/25455527/network-problems.png >=20 > While the transfer rate drops to zero the NAS also has a very bad ping > up to one second. Ping of Linux1 is perfectly fine during these > outages. >=20 > I also had a quick look on the data stream with wireshark on Linux1 > and > it shows a lot of TCP Dup ACK (up to 263 Dup ACKs created by NAS for > one > frame). >=20 > What can be eliminated as a cause is: > - Switch (I tried connecting Linux1 and NAS directly) > - Cable (I changed that a few times) > - Harddisk I/O (I'm only writing from /dev/zero to /dev/null) >=20 > The sevirity of that problem varies from one minute to another but can > always be reproduced with a few tries. >=20 > When limiting either NAS or Linux1 to 100Mbit I'm getting a steady > transfer rate of about 90Mbit/s. > When decreasing the MTU on NAS to 1200 the problem seems to disappear, > getting a transfer rate of about 160Mbit/s. >=20 > ifconfig re0: > > re0: flags=3D8843 metric 0 mtu > > 1500 > > =09options=3D388b > > =09ether 38:60:77:3e:af:a5 > > =09inet 192.168.178.54 netmask 0xffffff00 broadcast 192.168.178.255 > > =09nd6 options=3D29 > > =09media: Ethernet autoselect (1000baseT ) > > =09status: active >=20 try typing: # sysctl dev.re.0.stats=3D1 - this will dump out the stats on the chip if the "Rx missed frames" count is non-zero, you're probably snookered, to put it technically:-) - That's what I get for a re chip is this laptop and I haven't found a way around it. I just live with flakey net performance. rick > pciconf -lv: > > re0@pci0:1:0:0: class=3D0x020000 card=3D0xd6258086 chip=3D0x816810ec > > rev=3D0x06 hdr=3D0x00 > > vendor =3D 'Realtek Semiconductor Co., Ltd.' > > device =3D 'RTL8111/8168B PCI Express Gigabit Ethernet controller' > > class =3D network > > subclass =3D ethernet >=20 > Because Linux1 seems to be involved in that problem: It's running > Linux > 3.0 and it has an "Atheros Communications AR8121/AR8113/AR8114" > onboard. >=20 > Does anyone have an idea what could be the problem here? Decreasing > the > MTU is some kind of solution but the performance is still not optimal > and a MTU of 1500 should be no problem. >=20 > Greetings, > Michael La=C3=9F >=20 > _______________________________________________ > 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 Nov 5 16:57:28 2011 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 25DEC106566B for ; Sat, 5 Nov 2011 16:57:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id D23EB8FC17 for ; Sat, 5 Nov 2011 16:57:27 +0000 (UTC) Received: by vws11 with SMTP id 11so348616vws.13 for ; Sat, 05 Nov 2011 09:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=qWEI5esXz9Ncm/0WHxYfw6O43hP8AZ0E0isQh7kNffI=; b=AYCVgO/utW9HUhE1DDWW6yy1SAElCnI/YEcTFV+TZHcpiaKtQrtfrWzpVuSE1mNxrD nw9wcvBckOkZpfuthGSj404sabrmDClaysHOHoPIevXH1wrWKR3nHTZQr9AaYuQsdeQ3 XaHNkd03VMRlQMYLakrRmbde0LHKizWuM1v1Y= MIME-Version: 1.0 Received: by 10.52.30.130 with SMTP id s2mr19754575vdh.55.1320512246940; Sat, 05 Nov 2011 09:57:26 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Sat, 5 Nov 2011 09:57:26 -0700 (PDT) In-Reply-To: <1893638131.1215459.1320505430915.JavaMail.root@erie.cs.uoguelph.ca> References: <1320494003.19667.41.camel@bevan-pc.fritz.box> <1893638131.1215459.1320505430915.JavaMail.root@erie.cs.uoguelph.ca> Date: Sat, 5 Nov 2011 09:57:26 -0700 X-Google-Sender-Auth: UYH3Qwn8AMLRgKvzCBlqCggNdJ4 Message-ID: From: Adrian Chadd To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, bevan@bi-co.net Subject: Re: Gigabit Ethernet performance with Realtek 8111E 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, 05 Nov 2011 16:57:28 -0000 .. I do seem to recall dup acks being a problem in the stack, no? Adrian