Bug#565404: linux-image-2.6.26-2-amd64: atl1e: TSO is broken

[Jie Yang]

Anders Boström  wrote:
>> IP-header length field, but is shorter.
>  >>
>  JY> following is my test cese,
>
>  JY> a nfs server server with ar8131chip, device id 1063.
> export /tmp/ dir as the nfs share directory,  JY> the client,
> mount the server_ip:/tmp to local dir /mnt/nfs, ust a python
> script to write and read data on the  JY>
> /mnt/nfs/testnfs.log. it works fine.
>
> OK, the device-ID in our NFS-server is 1026, rev. b0. So it
> is possible that the problem is specific to that chip/version.
oops, its my mistake in writing, my case is 1026 device ID

>
>  JY> Can you give me some advice on how to reproduce this bug??
>
> The only suggestion I have is to try to find a board with a
> 1026-chip on it.
>
> My test-case is just copy of a 1 Gbyte file from the
> NFS-server to /dev/null , after making sure that the file
> isn't cached on the client by reading huge amounts of other data.
>
just to check, if the kernel version is 2.6.26-2 ??

Best wishes
jie



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#565404: linux-image-2.6.26-2-amd64: atl1e: TSO is broken

[Jie Yang]

Anders Boström  wrote:

> Cc: b...@decadent.org.uk; net...@vger.kernel.org;
> 565...@bugs.debian.org; Xiong Huang
> Subject: Re: Bug#565404: linux-image-2.6.26-2-amd64: atl1e:
> TSO is broken

> One strange observation is that I can only reproduce this
> problem when transmitting data from a NFS-server using TCP
> with Atheros AR8121/AR8113/AR8114.
>
> I've tried to reproduce the problem using test-programs, like
> nttcp and netpipe, without any success. One observation is
> that the test-programs *only* generates 1500 bytes
> IP-packets. When the NFS-server sends data, a sequence of
> 1500 bytes IP-packets are generated, ending with a shorter
> packet. And this last packet in the sequence has 1500 in the
> IP-header length field, but is shorter.
>
following is my test cese,

a nfs server server with ar8131chip, device id 1063. export /tmp/ dir as the 
nfs share directory,
the client, mount the server_ip:/tmp to local dir /mnt/nfs, ust a python script 
to write and read data on the
/mnt/nfs/testnfs.log. it works fine.

Can you give me some advice on how to reproduce this bug??

Best wishes
jie



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#565404: linux-image-2.6.26-2-amd64: atl1e: TSO is broken

[Jie Yang]

 Anders Boström 
> Sent: Wednesday, January 20, 2010 5:27 PM
> To: Jie Yang
> Cc: b...@decadent.org.uk; net...@vger.kernel.org;
> 565...@bugs.debian.org; Xiong Huang
> Subject: Re: Bug#565404: linux-image-2.6.26-2-amd64: atl1e:
> TSO is broken
>
> >>>>> "JY" == Jie Yang  writes:
>
>  JY> Anders Boström  wrote:
>  >> It is an ASUS M4A78 PRO motherboard with the Atheros  >>
> AR8121/AR8113/AR8114 on-board.
>  >>
>  >> >> ~25Mbyte/s performance. I get ~5000 retransmitted
> packets  >> per GByte  >> data, according to RetransSegs in
> >> /proc/net/snmp . wireshark in the  >> client show that the
>  >> server send out a sequence of frames. All but the  >>
> last  >> one are 1500 bytes IP-packets. The last one is
> shorter, but  >> the  >> IP-header still say 1500 byte. The
> client then  >> requests retransmit,  >> and the
> retransmitted frame arrives  >> with correct IP-header.
>
>  JY> i just test it on Linux localhost.localdomain
> 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009
> x86_64 x86_64 x86_64 GNU/Linux.
>  JY> with hardware, Atheros AR8121/AR8113/AR8114 PCI-E
> Ethernet Controller (rev b0)  JY> device id : 1969:1026 (rev b0)
>
>  JY> i upload/download a 382M it work well with retransmit packet:
>
> Have you tested NFS over TCP? The block-size the application
> uses can have an effect on this. What application did you
> use? Block-size?
>
yes, I tested NFS over TCP.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#565404: linux-image-2.6.26-2-amd64: atl1e: TSO is broken

[Jie Yang]

Anders Boström  wrote:

> It is an ASUS M4A78 PRO motherboard with the Atheros
> AR8121/AR8113/AR8114 on-board.
>
>  >> ~25Mbyte/s performance. I get ~5000 retransmitted packets
> per GByte  >> data, according to RetransSegs in
> /proc/net/snmp . wireshark in the  >> client show that the
> server send out a sequence of frames. All but the  >> last
> one are 1500 bytes IP-packets. The last one is shorter, but
> the  >> IP-header still say 1500 byte. The client then
> requests retransmit,  >> and the retransmitted frame arrives
> with correct IP-header.

i just test it on Linux localhost.localdomain 2.6.31.5-127.fc12.x86_64 #1 SMP 
Sat Nov 7 21:11:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux.
with hardware, Atheros AR8121/AR8113/AR8114 PCI-E Ethernet Controller (rev b0)
device id : 1969:1026 (rev b0)

i upload/download a 382M it work well with retransmit packet:

Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails 
EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts
Tcp: 1 200 12 -1 2 4 2 0 2 532501 220631 6 0 2

I also test it on kernel 2.6.33-rc1 sync from git. but it fail to boot kernel




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#558426: [PATCH net-next]atl1e:disable NETIF_F_TSO6 for hardware limit

[Jie Yang]

On Wednesday, December 02, 2009 4:32 PM
David Miller  wrote:
>
> From: 
> Date: Wed, 2 Dec 2009 11:18:34 +0800
>
> > From: Jie Yang 
> >
> > For hardware limit to support TSOV6, just disable this feature
> > Signed-off-by: Jie Yang 
>
> Shouldn't we be applying this to net-2.6 since it's a bug fix?
>
oh, It should applying to net-2.6.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#558426: TSOv6 broken in atl1e

[Jie Yang]

On Tuesday, December 01, 2009 11:20 AM
Ben Hutchings  wrote:


>
> I received a bug report  that
> shows atl1e corrupting IPv6 packets.  I have reproduced this
> on an Eee PC 901 and found that it is linked to TSO.  The
> most obvious thing wrong with the driver code is that it
> calculates the super-packet length incorrectly.
> However, fixing that:
>
> --- a/drivers/net/atl1e/atl1e_main.c
> +++ b/drivers/net/atl1e/atl1e_main.c
> @@ -1667,6 +1667,7 @@ static int atl1e_tso_csum(struct
> atl1e_adapter *adapter,
>
>   if (offload_type & SKB_GSO_TCPV6) {
>   real_len = (((unsigned char
> *)ipv6_hdr(skb) - skb->data)
> + + sizeof(struct ipv6hdr)
>   +
> ntohs(ipv6_hdr(skb)->payload_len));
>   if (real_len < skb->len)
>   pskb_trim(skb, real_len);
> --- END ---
>
> does not solve the problem.  Presumably this function is not
> constructing correct DMA descriptors for TSOv6.
>
> Please fix this, or I will submit a patch to remove this
> feature from the driver.
>

ou, there is hareware limit to support TSOv6, just disable it.

Best wishes
jie



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#558426: TSOv6 broken in atl1e

[Jie Yang]

On Tuesday, December 01, 2009 11:20 AM
Ben Hutchings 
>
> I received a bug report  that
> shows atl1e corrupting IPv6 packets.  I have reproduced this
> on an Eee PC 901 and found that it is linked to TSO.  The
> most obvious thing wrong with the driver code is that it
> calculates the super-packet length incorrectly.
> However, fixing that:
>
> --- a/drivers/net/atl1e/atl1e_main.c
> +++ b/drivers/net/atl1e/atl1e_main.c
> @@ -1667,6 +1667,7 @@ static int atl1e_tso_csum(struct
> atl1e_adapter *adapter,
>
>   if (offload_type & SKB_GSO_TCPV6) {
>   real_len = (((unsigned char
> *)ipv6_hdr(skb) - skb->data)
> + + sizeof(struct ipv6hdr)
>   +
> ntohs(ipv6_hdr(skb)->payload_len));
>   if (real_len < skb->len)
>   pskb_trim(skb, real_len);
> --- END ---
>
> does not solve the problem.  Presumably this function is not
> constructing correct DMA descriptors for TSOv6.
>
> Please fix this, or I will submit a patch to remove this
> feature from the driver.
>
> Ben.
>
ok, I will try to reproduce it.

Best wishes
jie



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org