Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Jun 2009 21:51:54 +0900
From:      Pyun YongHyeon <pyunyh@gmail.com>
To:        Pyun YongHyeon <yongari@FreeBSD.org>, current@freebsd.org
Subject:   Re: ale(4): Problems with tso, rxcsum and/or txcsum
Message-ID:  <20090615125154.GG78415@michelle.cdnetworks.co.kr>
In-Reply-To: <20090615121623.GA1479@roadrunner.spoerlein.net>
References:  <20090615121623.GA1479@roadrunner.spoerlein.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

> down/up the interface for changes to tso or {tr}xcsum to have any
> effect?
> 

No, ale(4) does not require interface reinitialization. Instead of
turning off all checksum offloading try disabling Rx checksum
offload first.

> Right now I'm rsyncing several GB to the machine and the connection
> seems stable even though I re-activated tso, rxcum and txcsum. This is
> rather weird ... Are problems with this chip revision known?
> 

No, I'm not aware of it but as I said it's second report so I guess
it's real.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090615125154.GG78415>