From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 09:47:53 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 082E416A400 for ; Fri, 22 Feb 2008 09:47:53 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.180]) by mx1.freebsd.org (Postfix) with ESMTP id 94D8F13C4EF for ; Fri, 22 Feb 2008 09:47:52 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by el-out-1112.google.com with SMTP id r27so319133ele.3 for ; Fri, 22 Feb 2008 01:47:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=TDNdr5wikzJka4OV+lsrPt5++cb/I/7pL+1olUIfb2o=; b=WTuFBd7ajLy3GQjqDQirWzCRKcUGVC9ve2S7M/aiipEXkHkDx5N0LePHoyNiR8vFMzQ65kXrL0KCVe16PT/LZamMZ3o6qLPqwB7t3wj8wQtChMT6wuYjfiVlvROlklJASnLIqimjdL5aWiBLPAWio3gCJC3vKNzkecs122n7xrw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=W+6AU46EYh3n3evGE/fU54lrolRf+boZC9Rdh0hB2PscdKIfmi47m7fPYQEbMaUBGpMfOasyI93dHF6Rnqjdw75lAvs6bRiHB2+SI8FHU4juw/OO03OMKBLO/9/5QkjJLipf8kMuf9Dg2C1DODPJlE99tle5/MOSY1i68s6HEXc= Received: by 10.142.104.9 with SMTP id b9mr8509894wfc.48.1203673670285; Fri, 22 Feb 2008 01:47:50 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 20sm1994111wfi.14.2008.02.22.01.47.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Feb 2008 01:47:49 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m1M9lhdE032344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 18:47:44 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m1M9lhm7032343; Fri, 22 Feb 2008 18:47:43 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 22 Feb 2008 18:47:42 +0900 From: Pyun YongHyeon To: Ian FREISLICH Message-ID: <20080222094742.GF30497@cdnetworks.co.kr> References: <20080222042700.GB30497@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Current , Robert Backhaus Subject: Re: Packet corruption in re0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 09:47:53 -0000 On Fri, Feb 22, 2008 at 10:43:22AM +0200, Ian FREISLICH wrote: > Pyun YongHyeon wrote: > > On Thu, Feb 21, 2008 at 01:18:18PM +0200, Ian FREISLICH wrote: > > > Pyun YongHyeon wrote: > > > > On Thu, Feb 21, 2008 at 02:47:43PM +1000, Robert Backhaus wrote: > > > > > On Thu, Feb 21, 2008 at 1:50 PM, Pyun YongHyeon wr > ote: > > > > > > On Thu, Feb 21, 2008 at 11:03:02AM +1000, Robert Backhaus wrote: > > > > > > > I am experiencing roughly 15% packet corruption on the re inter > face > > > on > > > > > > > my freebsd 7/amd64 box. > > > > > > > > > > > > > > FreeBSD gw.flexi.robbak.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEA > SE #8 > > > : > > > > > > > Tue Feb 5 09:49:55 EST 2008 > > > > > > > root@gw.flexi.robbak.com:/usr/obj/usr/src/sys/GW amd64 > > > > > > > > > > > > > > Just to make troubleshooting difficult, this problem only shows > up > > > > > > > after the system has been up for roughly 36 hours, depending on > the > > > > > > > amount of traffic. > > > > > > > > > > > > > > > > > > > I didn't take a look attached tcpdump files but I guess the > > > > > > instability issue was fixed in HEAD. It's not yet MFCed but > > > > > > I'll handle it in a week. > > > > > > > > > > > > Would you try re(4) in HEAD? > > > > > > > > > > > > > > > > OK, I'll do that. What is the best way to do that? csupping to "." se > ems a > > > > > bit drastic, and I don't do much with cvs proper. I take it that I sh > ould > > > use > > > > > anon-cvs to grab the directory, but I don't quite know how. > > > > > > > > > > > > > Copy sys/dev/re/if_re.c, sys/pci/if_rlreg.h in HEAD to your box. > > > > Due to lack of m_defrag(9) in 7-PRERELEASE/RC, you also have to add > > > > that function to if_re.c(Copy m_defrag() in sys/kern/uipc_mbuf.c on > > > > HEAD/RELENG_7 to if_re.c). That would make it build on your box. > > > > > > This doesn't solve the problem that I'm seeing on re(4) interfaces. > > > It basically shows up as quagga establishing OSPF neighours as > > > "Exchange/DR" when VLAN hardware tagging is enabled. I'm running > > > OSPF over 802.1Q vlans. Neighbours are correctly negotiated once > > > VLAN hardware tagging is disabled on the interface. > > > > > > I'll do more debugging. > > > > > > > Hmm. That sounds like different issue to me. I guess I din't change > > any semantics in VLAN H/W tagging. Do you still the same VLAN H/W > > tagging related issues on RELENG_7? > > > > To narrow down the issue it would be even better to know which parts > > of H/W assistance was broken. For example, > > - Disable checksum offload for VLAN interface first and check > > whether quagga works. > > You can only disable offload on the parent interface. > Hmm... I thought it should work. I have no idea why ioctl handler of vlan(4) rejects checksum offload configutation. I guess vlan(4) should be teached to handle this. If parent interface have IFCAP_VLAN_HWCSUM capability and IFCAP_VLAN_HWTAGGING, ifconfig(4) should be able to control checksum offload for vlan(4) interface. CCed to yar to get his opinions on controlling checksum offload on vlan(4). > > - Disable checksum offload for parent interface and check again. > > If you can post tcpdump output for broken conntection it may help a > > lot to diagnose the issue. > > The only flag affecting this behaviour is vlanhwtag. Various > permutations of the interface flags make no difference to this > behaviour as long as hardware tagging is enabled. > Disabling VLAN HW tagging also turns off checksum offload on vlan(4) interface. > It seems like it's corrupting large packets on transmit when vlanhwtag > is enabled. From the tcpdump output it looks like a padding or > packet length issue. > > Here's what tcpdump on the re(4) device thinks it's transmitting: > > 00:08:a1:3c:32:9c > 00:90:fb:0c:89:7d, ethertype 802.1Q (0x8100), length 1510: vlan 1000, p 0, ethertype IPv4, 196.22.138.92 > 196.22.138.89: OSPFv2, Database Description, length: 1472 > > Here's what was actually recieved by the em(4) device on the > neighbour. Note the absense of the 801.1Q header: > I see, I'll check it. > 00:08:a1:3c:32:9c > 00:90:fb:0c:89:7d, ethertype IPv4 (0x0800), length 1506: 196.22.138.92 > 196.22.138.89: OSPFv2, Database Description, length: 1472 > > When vlanhwtagging is disabled, the re(4) device transmits: > > 00:90:fb:0c:89:7d > 00:08:a1:3c:32:9c, ethertype 802.1Q (0x8100), length 1510: vlan 1000, p 0, ethertype IPv4, 196.22.138.89 > 196.22.138.92: OSPFv2, Database Description, length: 1472 > > and the em(4) device recieves: > > 00:08:a1:3c:32:9c > 00:90:fb:0c:89:7d, ethertype 802.1Q (0x8100), length 1510: vlan 1000, p 0, ethertype IPv4, 196.22.138.92 > 196.22.138.89: OSPFv2, Database Description, length: 1472 > > Let me know if you need more detailed tcpdump output than I've provided. > > Ian > > -- > Ian Freislich > -- Regards, Pyun YongHyeon