From owner-freebsd-net@FreeBSD.ORG Wed Nov 17 13:18:21 2010 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 55D1D106566B for ; Wed, 17 Nov 2010 13:18:21 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 92D2A8FC1B for ; Wed, 17 Nov 2010 13:18:20 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id oAHCslQQ092122; Wed, 17 Nov 2010 18:54:47 +0600 (NOVT) (envelope-from eugen@grosbein.pp.ru) Message-ID: <4CE3D097.7030204@grosbein.pp.ru> Date: Wed, 17 Nov 2010 18:54:47 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20101117070422.GA45678@cabstand.com> In-Reply-To: <20101117070422.GA45678@cabstand.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: bsdlists@cabstand.com Subject: Re: request for MFC of em/igb drivers 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, 17 Nov 2010 13:18:21 -0000 On 17.11.2010 13:04, Chris Peiffer wrote: > > Hi, > > I've been watching the traffic here over the last few months relating > to the em and igb Intel ethernet drivers. It seems like there's a big > consensus that HEAD has some good new fixes. > > Looking at this: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/e1000/if_em.c > > There's a pretty big commit to HEAD in rev 1.58 on Sep 27 that's > marked "MFC: a week" but it doesn't look like anything's been MFC'd > since. (And several other revisions that look more experimental have > since gone into HEAD.) > > We've been seeing some weird issues with em devices under high load > and if these changes in 1.58 are ready for STABLE we'd love to test > them live. > > So this is a beg... if the relevant committers are out here, can that > MFC go through soon? Or if it can't, or I'm reading the logs wrong, > please explain. > > Thanks in advance. Indeed, in RELENG_8 em(4) is not useable for us because of two flaws: 1. It panices system due to NULL pointers dereference. It needs the following patch taken from CURRENT's igb(4): --- if_em.c.orig 2010-11-02 15:45:56.000000000 +0600 +++ if_em.c 2010-11-08 14:24:46.000000000 +0600 @@ -4181,9 +4181,11 @@ ifp->if_ierrors++; /* Reuse loaded DMA map and just update mbuf chain */ mp = rxr->rx_buffers[i].m_head; + if(mp) { mp->m_len = mp->m_pkthdr.len = MCLBYTES; mp->m_data = mp->m_ext.ext_buf; mp->m_next = NULL; + } if (adapter->max_frame_size <= (MCLBYTES - ETHER_ALIGN)) m_adj(mp, ETHER_ALIGN); igb(4) in RELENG_8 has not this fix too and there is a PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=150920 2. It makes physical link down/up for every vlan creation/deletion that leads to 3 seconds of service interruption and down/up events for all other vlans based on same parent interface. It needs the following patch that's already present in CURRENT but not in RELENG_8: @@ -4342,7 +4344,8 @@ em_shadow_vfta[index] |= (1 << bit); ++adapter->num_vlans; /* Re-init to load the changes */ - em_init(adapter); + if (ifp->if_capenable & IFCAP_VLAN_HWFILTER) + em_init(adapter); } /* @@ -4366,7 +4369,8 @@ em_shadow_vfta[index] &= ~(1 << bit); --adapter->num_vlans; /* Re-init to load the changes */ - em_init(adapter); + if (ifp->if_capenable & IFCAP_VLAN_HWFILTER) + em_init(adapter); } static void