From owner-freebsd-current@FreeBSD.ORG Tue Jun 16 09:33:36 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 7282E10656B1 for ; Tue, 16 Jun 2009 09:33:36 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id E4C0D8FC1A for ; Tue, 16 Jun 2009 09:33:35 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (localhost.spoerlein.net [127.0.0.1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n5G9XYow045936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2009 11:33:34 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n5G9XYXX045935; Tue, 16 Jun 2009 11:33:34 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Tue, 16 Jun 2009 11:33:34 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Pyun YongHyeon Message-ID: <20090616093334.GB31709@acme.spoerlein.net> Mail-Followup-To: Pyun YongHyeon , current@freebsd.org References: <20090615121623.GA1479@roadrunner.spoerlein.net> <20090615125154.GG78415@michelle.cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090615125154.GG78415@michelle.cdnetworks.co.kr> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: current@freebsd.org 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 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 09:33:37 -0000 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. :/ 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. When tso is enabled, upload is seriously impacted, download is fine though, observe systat output: ale0 in 10.805 MB/s 11.101 MB/s 7.739 GB out 2.574 MB/s 8.740 MB/s 5.891 GB When disabling tso, while that test is running, it will immediately become this: ale0 in 7.498 MB/s 11.101 MB/s 8.270 GB out 7.560 MB/s 8.740 MB/s 6.209 GB Which looks more normal. Re-activating tso now has no further consequences to the stream (it only works for new TCP sessions, right?) Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/