> > 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 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
> 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
> >
> > 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
> > >
> > > 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
Got it, Axel , thanks !
> -Original Message-
> From: Dr. Axel Stammler [mailto:dr_a_stamm...@versanet.de]
> Sent: Friday, July 06, 2012 5:35
> To: Huang, Xiong
> Cc: Jonathan Nieder; Ben Hutchings; 664...@bugs.debian.org; nic-devel;
> Rodriguez, Luis
> Subject: RE: [s
gt; -Original Message-
> From: Rodriguez, Luis
> Sent: Thursday, July 05, 2012 7:50
> To: Jonathan Nieder; Ben Hutchings
> Cc: Huang, Xiong; 664...@bugs.debian.org; a...@users.sourceforge.net; nic-
> devel; mcg...@frijolero.org
> Subject: RE: [squeeze] atl1c: AR8152: "tran
you point me where is the change ?
Thanks
Xiong
> -Original Message-
> From: Jonathan Nieder [mailto:jrnie...@gmail.com]
> Sent: Thursday, July 05, 2012 1:47
> To: Ben Hutchings
> Cc: Huang, Xiong; 664...@bugs.debian.org; a...@users.sourceforge.net; nic-
> devel; R
Nieder [mailto:jrnie...@gmail.com]
> Sent: Thursday, July 05, 2012 1:47
> To: Ben Hutchings
> Cc: Huang, Xiong; 664...@bugs.debian.org; a...@users.sourceforge.net; nic-
> devel; Rodriguez, Luis
> Subject: Re: [squeeze] atl1c: AR8152: "transmit queue 0 timed out" and
> netwo
:jrnie...@gmail.com]
> Sent: Thursday, July 05, 2012 2:16
> To: Ben Hutchings
> Cc: Huang, Xiong; 664...@bugs.debian.org; a...@users.sourceforge.net; nic-
> devel; Rodriguez, Luis
> Subject: Re: [squeeze] atl1c: AR8152: "transmit queue 0 timed out" and
> network is
>
> I've attempted to backport these changes to Linux 2.6.32 as used in the
> current Debian stable release. The result can be found at:
>
> git://anonscm.debian.org/kernel/linux-2.6.git squeeze-driver-test
>
> Please can you review the changes and test whether this works properly (I
> have no
Hi Jonathan
For driver atl1c, we add many patches recently. Please sync with the
kernel, the last patch is
80bcb4238dd858d atl1c: remove PHY polling from atl1c_change_mtu
Most of the time, the issue of tx q0 timeout is caused by wrong HW
configuration and bad cable condition.
It wil
13 matches
Mail list logo
