From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 05:26:13 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45A6B106566C for ; Mon, 29 Jun 2009 05:26:13 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f191.google.com (mail-px0-f191.google.com [209.85.216.191]) by mx1.freebsd.org (Postfix) with ESMTP id 113FC8FC0A for ; Mon, 29 Jun 2009 05:26:12 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by pxi29 with SMTP id 29so3207256pxi.3 for ; Sun, 28 Jun 2009 22:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:subject :message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=KVXTRH3CqNLh/18hs67SQ54rhV9vvzyKERgihskcQDI=; b=vfP5suoNsBOWbDa/dyhJo8varILqF8eahv1/fHLRytEzaPWyJkL1CNQZ4ixOKQuSh2 s5JSrYyC5kKGW6395yfRsBM+s/03e5m2yITzqifVXSXY+RjQOmJuFjgcC/yM0BgV2cq7 2Xevss9cQycF1tpnQ6/eO4K957+s0Y7ojR28g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=pya5CljLx+1NKcngyZxpB9dS9VFI1DvNzKAFRz1wGF+t10j3hdfZsvSxa9sIAtWaaG 2y4lON86ukoKDn7RJU7xCeRDy9ISuspzxyh0UHG/yi2cR6lQ1eKyigSUZcWvjsDLorpd HS0jL6cPq+o8iAEMoViteqXl2I8xltCmudpOk= Received: by 10.114.168.15 with SMTP id q15mr10924061wae.56.1246253172579; Sun, 28 Jun 2009 22:26:12 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id b39sm18125821rvf.8.2009.06.28.22.26.10 (version=SSLv3 cipher=RC4-MD5); Sun, 28 Jun 2009 22:26:11 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Mon, 29 Jun 2009 14:23:30 +0900 From: Pyun YongHyeon Date: Mon, 29 Jun 2009 14:23:30 +0900 To: current@freebsd.org Message-ID: <20090629052330.GC1268@michelle.cdnetworks.co.kr> References: <20090615121623.GA1479@roadrunner.spoerlein.net> <20090615125154.GG78415@michelle.cdnetworks.co.kr> <20090616093334.GB31709@acme.spoerlein.net> <20090616101740.GI78415@michelle.cdnetworks.co.kr> <20090627171110.GP31709@acme.spoerlein.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090627171110.GP31709@acme.spoerlein.net> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: ale(4): Problems with tso, rxcsum and/or txcsum 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: Mon, 29 Jun 2009 05:26:13 -0000 On Sat, Jun 27, 2009 at 07:11:11PM +0200, Ulrich Sp??rlein wrote: > Sorry for the long delay, I only now got around testing this more > thoroughly. > > On Tue, 16.06.2009 at 19:17:40 +0900, Pyun YongHyeon wrote: > > On Tue, Jun 16, 2009 at 11:33:34AM +0200, Ulrich Sp??rlein wrote: > > > On Mon, 15.06.2009 at 21:51:54 +0900, Pyun YongHyeon wrote: > > > > On Mon, Jun 15, 2009 at 02:16:23PM +0200, Ulrich Sp??rlein wrote: > > > > > Hello Pyun, > > > > > > > > > > I have connection problems with the onboard GigE of an Asus P5Q board, using a recent 8-CURRENT > > > > > > > > > > ale0: port 0xdc00-0xdc7f mem 0xfe9c0000-0xfe9fffff irq 17 at device 0.0 on pci2 > > > > > ale0: 960 Tx FIFO, 1024 Rx FIFO > > > > > ale0: Using 1 MSI messages. > > > > > ale0: 4GB boundary crossed, switching to 32bit DMA addressing mode. > > > > > miibus0: on ale0 > > > > > ale0: Ethernet address: 00:24:8c:36:3e:10 > > > > > ale0: [FILTER] > > > > > ale0: link state changed to UP > > > > > > > > > > ale0@pci0:2:0:0: class=0x020000 card=0x82261043 chip=0x10261969 rev=0xb0 hdr=0x00 > > > > > vendor = 'Attansic (Now owned by Atheros)' > > > > > device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' > > > > > class = network > > > > > subclass = ethernet > > > > > > > > > > ale0: flags=8843 metric 0 mtu 1500 > > > > > options=311b > > > > > ether 00:24:8c:36:3e:10 > > > > > inet 192.168.0.146 netmask 0xffffff00 broadcast 192.168.0.255 > > > > > media: Ethernet autoselect (100baseTX ) > > > > > status: active > > > > > > > > > > When transferring data to the machine at ~10MB/s (100Mbit network only) the ssh > > > > > connection will die after a couple of minutes with > > > > > > > > > > Disconnecting: Bad packet length 1592360521. > > > > > > > > > > After disabling tso, txcsum and rxcsum the connection seems to be > > > > > stable, though. I fail to figure out a pattern, though. Do I need to > > > > > > > > Hmm, I think this is the second report that could be related with > > > > Rx checksum offloading. If disabling Rx checksum fix the issue, I > > > > have to disable it by default until I understand what's going on. > > > > > > I really need to disable tso, rxcsum *and* txcsum to make this card work > > > stable. :/ > > > > Hmm, let's see which offload was broken. Disabling all offloads > > make it hard to find broken one. > > Ok, disabling -rxcsum will make the connection stable. But when I enable > rxcsum again, it is also stable! It looks like it is not turned on > again. To sum it up: > > 1. doing nothing: ssh connection drops after a couple of minutes > 2. ifconfig ale0 -rxcsum: ssh runs stable for dozens of minutes > 3. ifconfig ale0 rxcsum: ssh runs stable for dozens of minutes (wtf?) > > > > There is one other weirdness, though, regarding tso. I have been using a > > > netcat-blast test, where I "upload" /dev/zero to another machine, and > > > "download" it from the same machine. > > Scrap all my previous findings regarding this issue. I re-ran the test > with three machines. So ale0 would download from machine A and upload to > machine B. No matter how I hard I try, I can always saturate the 100MBit > Ethernet in full duplex. Don't know how the previous numbers came about. > Yeah, I still can't reproduce the issue you've mentioned but I think it's better to disable Rx checksum offload at this time. If I manage to find root cause of issue I would enable it again with proper workarounds. > Thanks for your patience, but it looks like the rxcsum is indeed fishy > on this chip revision. > Committed to HEAD(r195153). You can still enable Rx checksum offload with ifconfig(8) but it is disabled by default. Thanks for reporting!