From owner-freebsd-current@FreeBSD.ORG Sun Jan 3 22:17:50 2010 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 A24711065672 for ; Sun, 3 Jan 2010 22:17:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f176.google.com (mail-qy0-f176.google.com [209.85.221.176]) by mx1.freebsd.org (Postfix) with ESMTP id 568238FC22 for ; Sun, 3 Jan 2010 22:17:49 +0000 (UTC) Received: by qyk6 with SMTP id 6so6219352qyk.3 for ; Sun, 03 Jan 2010 14:17:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=XU5eT6JJAArsIdq5NqSrPB0ohu3aSRp08uqbqbqk+/8=; b=FEofCwdxGdcPAtuvLt8mxp9P4k22BhHyKeRTkUcOL1b9Z1WFxA1gbjM76PmHpiyLwj WEvsQVOR6qxbZDlFbnWagaEGG8lIEUA8sUfHkO+O8YsE5tQsc6Bv0CCADVLF431LbYFP lYi+qs5JASpntpeadDP07ghqBU4IcfZRjbEpQ= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=Uevhe2ckpEh6Cv+uf2G9M57AcaysGnWXgE1zRjhhtaLphSZMJXD9zgKf3OIYIysA2Z vyykYC/aC/m8mESO7iukObRwyjpZDQKI1N21ZK1yWMSSkcNMFrflpcup9uwzYSpA6Stc JyqvtM3O3PBVBxxJTUGBuFGGj4bjkCkTyZud0= Received: by 10.224.32.149 with SMTP id c21mr10805406qad.33.1262557062055; Sun, 03 Jan 2010 14:17:42 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 2sm47349445qwi.57.2010.01.03.14.17.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 03 Jan 2010 14:17:40 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 3 Jan 2010 14:16:30 -0800 From: Pyun YongHyeon Date: Sun, 3 Jan 2010 14:16:30 -0800 To: David Ehrmann Message-ID: <20100103221630.GV1166@michelle.cdnetworks.com> References: <4B40AFFA.6090706@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B40AFFA.6090706@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: vge traffic problem 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: Sun, 03 Jan 2010 22:17:50 -0000 On Sun, Jan 03, 2010 at 06:55:54AM -0800, David Ehrmann wrote: > I reported this problem before, but I have a specific, reproducible > example, now. I'm running 8.0 RC1. I'm trying to fetch the source to > upgrade to 8.0, but this happens: > > # csup stable-supfile > Connected to 72.233.193.64 > Receiver: Connection reset by peer > Will retry at 22:39:31 > > tcpdump output of that: http://pastebin.com/m16978f3 (there seem to be a > lot of duplicate acks being sent). > > I tried with a different server, and I tried several times, but > generally, the same thing, though I do occasionally get lucky. > > I have a vr interface on my motherboard, so I gave it an IP address in a > different subnet and changed the default gateway to a NAT box with the > same default gateway as this box used to have (so I'm using the same > internet connection). Suddenly, it works. Reproducibly. > > I also have issues with samba, but putting that aside, netstat -s -p tcp > reported this: > > tcp: > ... > 289024537 packets received > 116305350 acks (for 1099476725 bytes) > 3119202 duplicate acks > > That's a duplicate ack received for every 37 unique acks. Seems pretty > high for traffic on a small LAN, but I could be wrong. I checked the > cable; it is cat5e or cat 6. I also tried plugging the vge port into a > 10/100 mbps switch, but csup still failed. > I vaguely guess it comes from long standing vge(4) bug. If a sending frame is composed of exactly 7 fragments, vge(4) used to set to 8 because the hardware expect # fragments + 1 in TX descriptor. However the bit fields that represents the information has 3 bits such that setting it to 8 yields 0 in this field and this seems to confuse controller. > Ideas? I saw that there were a few recent changes to vge, but I'm not > sure if they're related to this. I think I fixed all known vge(4) issues in HEAD. vge(4) in HEAD has new hardware based interrupt moderation, hardware MAC statistics support and WOL as well as fixing long standing bugs. Would you try latest vge(4) in HEAD?(Just download if_vge.c, if_vgereg.h and if_vgevar.h from HEAD and rebuild it). If your vge(4) controller use IC Plus IP1001PHY you may also want to download ip1000phy.c in HEAD to reliably establish 1000baseT link after waking up from WOL/resume. There is one unresolved TX performance issue though. I couldn't get more than 800Mbps on TCP bulk transfers. All PCIe controllers I'm aware of can get more than 900Mbps so there might be some missing bits in vge(4).