On Wed, Apr 03, 2013 at 12:12:12AM +, Huang, Xiong wrote:
> > > Hannes, Thanks for your testing !
> > >
> > > simply revising MAX_TX_BUF_LEN to 0x4000 will cause incorrect TX
> > configuration...
> > > I mean you can try to put a gso size limit of 0x4000 (or 0x5000)
> >
> > I tested both
On Tue, Apr 02, 2013 at 03:34:53PM -0700, Eric Dumazet wrote:
> Really I don't understand why people use u16 instead of u32.
>
> u16 is slower most of the time, and more prone to overflows.
>
> diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
> b/drivers/net/ethernet/atheros/atl1e/at
> > Hannes, Thanks for your testing !
> >
> > simply revising MAX_TX_BUF_LEN to 0x4000 will cause incorrect TX
> configuration...
> > I mean you can try to put a gso size limit of 0x4000 (or 0x5000)
>
> I tested both values with multi-gigabyte nfsv4 traffic and both values are ok.
> If I und
On Tue, Apr 02, 2013 at 10:23:54PM +, Huang, Xiong wrote:
>
> >
> > On Tue, Apr 02, 2013 at 09:51:12PM +, Huang, Xiong wrote:
> > > > The error vanishes as soon as I put a gso size limit of
> > > > MAX_TX_BUF_LEN in the driver. MAX_TX_BUF_LEN seems to be
> > arbitrary
> > > > set to 0x200
On Tue, Apr 02, 2013 at 03:34:53PM -0700, Eric Dumazet wrote:
> On Wed, 2013-04-03 at 00:15 +0200, Hannes Frederic Sowa wrote:
> > On Tue, Apr 02, 2013 at 03:00:38PM -0700, Eric Dumazet wrote:
> > > On Tue, 2013-04-02 at 23:15 +0200, Hannes Frederic Sowa wrote:
> > >
> > > > The error vanishes as
On Wed, 2013-04-03 at 00:15 +0200, Hannes Frederic Sowa wrote:
> On Tue, Apr 02, 2013 at 03:00:38PM -0700, Eric Dumazet wrote:
> > On Tue, 2013-04-02 at 23:15 +0200, Hannes Frederic Sowa wrote:
> >
> > > The error vanishes as soon as I put a gso size limit of MAX_TX_BUF_LEN
> > > in the driver. MA
>
> On Tue, Apr 02, 2013 at 09:51:12PM +, Huang, Xiong wrote:
> > > The error vanishes as soon as I put a gso size limit of
> > > MAX_TX_BUF_LEN in the driver. MAX_TX_BUF_LEN seems to be
> arbitrary
> > > set to 0x2000. I can even raise it to 0x3000 and don't see any tcp
> > > retransmits. Do
On Tue, Apr 02, 2013 at 09:51:12PM +, Huang, Xiong wrote:
> > The error vanishes as soon as I put a gso size limit of MAX_TX_BUF_LEN in
> > the driver. MAX_TX_BUF_LEN seems to be arbitrary set to 0x2000. I can even
> > raise it to 0x3000 and don't see any tcp retransmits. Do you have an advice
On Tue, Apr 02, 2013 at 03:00:38PM -0700, Eric Dumazet wrote:
> On Tue, 2013-04-02 at 23:15 +0200, Hannes Frederic Sowa wrote:
>
> > The error vanishes as soon as I put a gso size limit of MAX_TX_BUF_LEN
> > in the driver. MAX_TX_BUF_LEN seems to be arbitrary set to 0x2000. I
> > can even raise it
On Tue, 2013-04-02 at 23:15 +0200, Hannes Frederic Sowa wrote:
> The error vanishes as soon as I put a gso size limit of MAX_TX_BUF_LEN
> in the driver. MAX_TX_BUF_LEN seems to be arbitrary set to 0x2000. I
> can even raise it to 0x3000 and don't see any tcp retransmits. Do you
> have an advice on
> The error vanishes as soon as I put a gso size limit of MAX_TX_BUF_LEN in
> the driver. MAX_TX_BUF_LEN seems to be arbitrary set to 0x2000. I can even
> raise it to 0x3000 and don't see any tcp retransmits. Do you have an advice on
> how to size this value (e.g. should we switch to the windows va
On Mon, Apr 01, 2013 at 02:51:56AM +, Huang, Xiong wrote:
> > >
> > > I checked windows driver, it does limit the max packet length for TSO
> > > windows XP : 32*1024 bytes (include MAC header and all MAC payload). No
> > support IP/TCP option.
> > > Windows 7: 15, 000 bytes, support IP/TCP o
> "HFS" == Hannes Frederic Sowa writes:
HFS> The bug is definitely still around. Yesterday I could reproduce it and
will
HFS> look for a solution in the next days.
This sounds great!
HFS> Do you have any details on the hangs every 6 months? Could you catch
HFS> thread dumps or oopses?
On Tue, Apr 02, 2013 at 09:35:04AM +0200, Anders Boström wrote:
> I'm sorry, but I can't test this at the moment. The computer with the
> TSO-problem is running as a file-server => can't be used for testing.
> Also, we don't use the Atheros Ethernet interface any more due to
> other problems, hard
> "BH" == Ben Hutchings writes:
BH> On Tue, 2010-01-26 at 09:34 +0100, Anders Boström wrote:
>> > "JY" == Jie Yang writes:
>>
JY> Anders Boström wrote:
>>
JY> following is my test cese,
>> >>
JY> a nfs server server with ar8131chip, device id 1063.
>> >> export /tmp/ dir as
> >
> > I checked windows driver, it does limit the max packet length for TSO
> > windows XP : 32*1024 bytes (include MAC header and all MAC payload). No
> support IP/TCP option.
> > Windows 7: 15, 000 bytes, support IP/TCP option.
>
> If TSO on these devices don't work properly with TCP options
On Sun, Mar 31, 2013 at 12:25:58AM +, Ben Hutchings wrote:
> On Tue, 2010-01-26 at 09:34 +0100, Anders Boström wrote:
> > > "JY" == Jie Yang writes:
> >
> > JY> Anders Boström wrote:
> >
> > JY> following is my test cese,
> > >>
> > JY> a nfs server server with ar8131chip, device i
On Sun, 2013-03-31 at 02:18 +, Huang, Xiong wrote:
> > > >
> > > > I've tested with
> > > > Debian linux-image-2.6.26-2-amd64 version 2.6.26-19lenny2, Debian
> > > > linux-image-2.6.30-bpo.2-amd64 version 2.6.30-8~bpo50+2 and
> > > > kernel.org
> > > > 2.6.30.10 amd64 with ethtool patch for set
> > >
> > > I've tested with
> > > Debian linux-image-2.6.26-2-amd64 version 2.6.26-19lenny2, Debian
> > > linux-image-2.6.30-bpo.2-amd64 version 2.6.30-8~bpo50+2 and
> > > kernel.org
> > > 2.6.30.10 amd64 with ethtool patch for setting of tso. Same result.
> >
> > Does booting with the kernel para
> >
> > I've tested with
> > Debian linux-image-2.6.26-2-amd64 version 2.6.26-19lenny2, Debian
> > linux-image-2.6.30-bpo.2-amd64 version 2.6.30-8~bpo50+2 and kernel.org
> > 2.6.30.10 amd64 with ethtool patch for setting of tso. Same result.
>
> Does booting with the kernel parameter 'pci=nomsi' a
On Tue, 2010-01-26 at 09:34 +0100, Anders Boström wrote:
> > "JY" == Jie Yang writes:
>
> JY> Anders Boström wrote:
>
> 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,
>
> "JY" == Jie Yang writes:
JY> Anders Boström wrote:
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
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
> sc
>>>>> "JY" == Jie Yang writes:
JY> 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
>
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 transmitti
Ben Hutchings wrote:
>
> Based on the TCP sequence numbers, it seems that the length of the
> broken packet is correct but its IP header is wrong.
>
> My understanding is that the length of the TCP payload in a GSO skb must
> always be a multiple of the gso_size, so that hardware is not required
On Thu, 2010-01-21 at 17:42 +0100, Anders Boström wrote:
> > "JY" == Jie Yang writes:
>
> >> 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?
> >>
> JY> yes, I tested NFS over TCP.
>
> One
> "JY" == Jie Yang writes:
>> 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?
>>
JY> yes, I tested NFS over TCP.
One strange observation is that I can only reproduce this problem when
transmit
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
>
> >>>>> &q
> "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 . wir
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 s
On Fri, 2010-01-15 at 14:25 +0100, Anders Boström wrote:
> When I run NFS over TCP (default options) and read large files from a
> server with Atheros AR8121/AR8113/AR8114 Ethernet chip, I only get
Do you know which specific chip it is?
> ~25Mbyte/s performance. I get ~5000 retransmitted packets
Package: linux-image-2.6.26-2-amd64
Version: 2.6.26-19
Severity: normal
Short desription
TCP Segmentation Offload (TSO) result in broken IPv4-packets sent out
from Atheros AR8121/AR8113/AR8114 with the atl1e driver.
Work around
---
Turn off TSO.
Long desription
-
33 matches
Mail list logo
