Date: Tue, 16 Jun 2009 11:33:34 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= <uqs@spoerlein.net> To: Pyun YongHyeon <pyunyh@gmail.com> Cc: current@freebsd.org Subject: Re: ale(4): Problems with tso, rxcsum and/or txcsum Message-ID: <20090616093334.GB31709@acme.spoerlein.net> In-Reply-To: <20090615125154.GG78415@michelle.cdnetworks.co.kr> References: <20090615121623.GA1479@roadrunner.spoerlein.net> <20090615125154.GG78415@michelle.cdnetworks.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <Atheros AR8121/AR8113/AR8114 PCIe Ethernet> 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: <MII bus> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> > options=311b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,WOL_MCAST,WOL_MAGIC>
> > ether 00:24:8c:36:3e:10
> > inet 192.168.0.146 netmask 0xffffff00 broadcast 192.168.0.255
> > media: Ethernet autoselect (100baseTX <full-duplex>)
> > 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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090616093334.GB31709>