Bug#565404: linux-image-2.6.26-2-amd64: atl1e: TSO is broken
> > 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 understand you correctly 0x4000 is a safe limit? Since Win7 driver uses 15000 bytes as its max packet length for TSO, I think 0x3C00 is more safer than 0x4000. :) Thanks Xiong
Bug#565404: linux-image-2.6.26-2-amd64: atl1e: TSO is broken
> > 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 how to size this value (e.g. should > we switch to the windows values)? > > > > > > > Would you try 0x4000 ? because the buffer-length in TX descriptor is 14bits, > 0x4000 exceeds max value. > > Do you find any bug/issue on the code that calculate the length for each TX > descriptor ? > > Setting MAX_TX_BUF_LEN to 0x4000 > > [ 8949.833750] ATL1E :04:00.0 p33p1: NIC Link is Up <100 Mbps Full > Duplex> [ 8949.833783] IPv6: ADDRCONF(NETDEV_CHANGE): p33p1: link > becomes ready [ 8960.861557] ATL1E :04:00.0 p33p1: PCIE DMA RW error > (status = 0x5000400) [ 8960.866879] ATL1E :04:00.0 p33p1: NIC Link is Up > <100 Mbps Full Duplex> [ 8961.095266] ATL1E :04:00.0 p33p1: PCIE DMA > RW error (status = 0x5000400) [ 8961.100791] ATL1E :04:00.0 p33p1: NIC > Link is Up <100 Mbps Full Duplex> > 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) Thanks Xiong
Bug#565404: linux-image-2.6.26-2-amd64: atl1e: TSO is broken
> 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 values)? > Would you try 0x4000 ? because the buffer-length in TX descriptor is 14bits, 0x4000 exceeds max value. Do you find any bug/issue on the code that calculate the length for each TX descriptor ? Thanks Xiong
Bug#565404: linux-image-2.6.26-2-amd64: atl1e: TSO is broken
> > > > 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 then you're > just going to have to disable it - Linux requires it to support at least the > timestamp option. I'm not sure about IP options (this really ought to be > documented). > > If there's a length limit lower than 64K, you'll need to set the limit using > netif_set_gso_max_size() before registering the net device. > Ben, thanks for your advice. I have discussed with windows driver developer and hardware designer, the TSO limitation for win driver is just For simplifying windows driver due to the buffer length limitation of TX descriptor. The hardware itself has no limitation on TSO packet length. BTW. Ip/tcp option is supported as well. Thanks Xiong
Bug#565404: linux-image-2.6.26-2-amd64: atl1e: TSO is broken
> > > > > > 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' avoid the problem? > > > > Hannes has found DMA-write (for rx-packet) is abnormal due to msi function. > But TSO is for rx-packet, an opposite direction. I'm not sure :(, If someone > has this issue, he/she could have a try. > 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. Thanks Xiong
Bug#565404: linux-image-2.6.26-2-amd64: atl1e: TSO is broken
> > > > 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' avoid the problem? > Hannes has found DMA-write (for rx-packet) is abnormal due to msi function. But TSO is for rx-packet, an opposite direction. I'm not sure :(, If someone has this issue, he/she could have a try. Thanks Xiong
Bug#664461: [squeeze] atl1c: AR8152: "transmit queue 0 timed out" and network is unusable until reset
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: [squeeze] atl1c: AR8152: "transmit queue 0 timed out" and > network is unusable until reset > > Hi, Xiong, > > everything has been running stable without any problems with these patches > (whereas without them it never worked), so… > > $ ls -l kern.log* > -rw-r- 1 root adm 688988 Jul 5 23:12 kern.log > -rw-r- 1 root adm 421701 Jul 2 05:50 kern.log.1 > -rw-r- 1 root adm 141255 Jun 28 19:27 kern.log.2.gz > -rw-r- 1 root adm 151227 Jun 18 20:09 kern.log.3.gz > -rw-r- 1 root adm 210761 Jun 10 11:50 kern.log.4.gz > > …and my oldest log entry is from June 3. Sorry. > > Axel > > On Wed, 4 Jul 2012, Huang, Xiong wrote: > > > Hi Axel > >Just curious, it seems that the kern log is un-complete, you missed > > some lines just before the line of Mar 18 08:14:54 bamboo kernel: > [ 1379.37] [ cut here ] > > Could you paste here ?
Bug#664461: [squeeze] atl1c: AR8152: "transmit queue 0 timed out" and network is unusable until reset
Hi Jonathan
I review the code porting, everything look ok, but vlan,
adapter->vlgrp is used for packet receive, but the code of :
if (unlikely(adapter->vlgrp && vlan_tx_tag_present(skb))) {
in file atl1c_main.c is used for tx, this might be an issue.
Thanks
Xiong
> -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: "transmit queue 0 timed out" and
> network is unusable until reset
>
>
> Adding my personal address as there were some questions regarding compat.
> I'll reply over there.
>
> Luis
>
> From: Jonathan Nieder [jrnie...@gmail.com]
> Sent: Wednesday, July 04, 2012 10:46 AM
> 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 unusable until reset
>
> Hi Ben and Atheros folks,
>
> Ben Hutchings wrote:
> > On Thu, 2012-05-10 at 02:14 +, Huang, Xiong wrote:
>
> >> 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
> >
> > 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 hardware to test). The major difference I'm concerned
> > about is in VLAN handling;
>
> In the meantime would it be sensible to apply the three patches I suggested to
> squeeze? Axel Stammler tested them with an AR8152 for several months and
> found them to have two good results:
>
> (1) Without those patches, he would often experience tx queue 0 timeouts
> and not be able to use his connection again until a reboot. With the
> patches, the timeouts went away.
>
> (2) No noticeable regressions.
>
> [...]
> >> Most of the time, the issue of tx q0 timeout is caused by wrong
> >> HW configuration and bad cable condition.
> >> It will cause the PHY/cable link unstable, and the driver doesn't
> >> correctly reset the DMA engine and clear all Pending tx-packet while
> >> link down --- and timeout issue will appear.
> > [...]
> >
> > So is this fixed in the current driver version? Or are you saying
> > that this is a hardware bug that can't be fixed?
>
> At least in Axel's case, it seems to be fixed by v2.6.36-rc1~571^2~706
> "atl1c: Add AR8151 v2 support and change L0s/L1 routine".
>
> Luis R. Rodriguez wrote:
>
> > FWIW we already provide daily backports of code through compat-wireless.
> > compat-wireless will eventually be changed to "compat-drivers" to
> > reflect that it has drivers backported other than 802.11. We also have
> > stable releases of the Linux kernel backported for use on older releases.
>
> I looked at the relevant repositories and am afraid I am too dim to see how to
> use them. Can you please provide step-by-step instructions for producing an
> mbox file with the appropriate compat-drivers patches to apply to a 2.6.32.y
> kernel from kernel.org?
>
> I am also concerned about the support policy --- it seems that compat-drivers
> tracks mainline and even newer developments fairly closely and does not
> restrict itself to bugfixes, support for new hardware, and other changes that
> are important enough to outweigh the risk of regressions. The cost of a
> regression is higher on a machine that is normally only updated every couple
> of months or so, as is the case for many machines running Debian squeeze. Is
> there something like compat-drivers that tracks some more stable tree such
> as 3.0.y instead of mainline?
>
> Thanks and hope that helps,
> Jonathan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#664461: [squeeze] atl1c: AR8152: "transmit queue 0 timed out" and network is unusable until reset
Hi Jonathan I download your git tree, but don't found your patch added to atl1c, it's almost same as non-updated atl1c. The code in the git still have TX q0 time issue because the netif_stope_queue is called when cable link down, but Not restart it when cable link resume. Would 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; Rodriguez, Luis > Subject: Re: [squeeze] atl1c: AR8152: "transmit queue 0 timed out" and > network is unusable until reset > > Hi Ben and Atheros folks, > > Ben Hutchings wrote: > > On Thu, 2012-05-10 at 02:14 +, Huang, Xiong wrote: > > >> 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 > > > > 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 hardware to test). The major difference I'm concerned > > about is in VLAN handling; > > In the meantime would it be sensible to apply the three patches I suggested to > squeeze? Axel Stammler tested them with an AR8152 for several months and > found them to have two good results: > > (1) Without those patches, he would often experience tx queue 0 timeouts > and not be able to use his connection again until a reboot. With the > patches, the timeouts went away. > > (2) No noticeable regressions. > > [...] > >> Most of the time, the issue of tx q0 timeout is caused by wrong > >> HW configuration and bad cable condition. > >> It will cause the PHY/cable link unstable, and the driver doesn't > >> correctly reset the DMA engine and clear all Pending tx-packet while > >> link down --- and timeout issue will appear. > > [...] > > > > So is this fixed in the current driver version? Or are you saying > > that this is a hardware bug that can't be fixed? > > At least in Axel's case, it seems to be fixed by v2.6.36-rc1~571^2~706 > "atl1c: Add AR8151 v2 support and change L0s/L1 routine". > > Luis R. Rodriguez wrote: > > > FWIW we already provide daily backports of code through compat-wireless. > > compat-wireless will eventually be changed to "compat-drivers" to > > reflect that it has drivers backported other than 802.11. We also have > > stable releases of the Linux kernel backported for use on older releases. > > I looked at the relevant repositories and am afraid I am too dim to see how to > use them. Can you please provide step-by-step instructions for producing an > mbox file with the appropriate compat-drivers patches to apply to a 2.6.32.y > kernel from kernel.org? > > I am also concerned about the support policy --- it seems that compat-drivers > tracks mainline and even newer developments fairly closely and does not > restrict itself to bugfixes, support for new hardware, and other changes that > are important enough to outweigh the risk of regressions. The cost of a > regression is higher on a machine that is normally only updated every couple > of months or so, as is the case for many machines running Debian squeeze. Is > there something like compat-drivers that tracks some more stable tree such > as 3.0.y instead of mainline? > > Thanks and hope that helps, > Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#664461: [squeeze] atl1c: AR8152: "transmit queue 0 timed out" and network is unusable until reset
Hi Axel Just curious, it seems that the kern log is un-complete, you missed some lines just before the line of Mar 18 08:14:54 bamboo kernel: [ 1379.37] [ cut here ] Could you paste here ? 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; Rodriguez, Luis > Subject: Re: [squeeze] atl1c: AR8152: "transmit queue 0 timed out" and > network is unusable until reset > > Hi Ben and Atheros folks, > > Ben Hutchings wrote: > > On Thu, 2012-05-10 at 02:14 +, Huang, Xiong wrote: > > >> 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 > > > > 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 hardware to test). The major difference I'm concerned > > about is in VLAN handling; > > In the meantime would it be sensible to apply the three patches I suggested to > squeeze? Axel Stammler tested them with an AR8152 for several months and > found them to have two good results: > > (1) Without those patches, he would often experience tx queue 0 timeouts > and not be able to use his connection again until a reboot. With the > patches, the timeouts went away. > > (2) No noticeable regressions. > > [...] > >> Most of the time, the issue of tx q0 timeout is caused by wrong > >> HW configuration and bad cable condition. > >> It will cause the PHY/cable link unstable, and the driver doesn't > >> correctly reset the DMA engine and clear all Pending tx-packet while > >> link down --- and timeout issue will appear. > > [...] > > > > So is this fixed in the current driver version? Or are you saying > > that this is a hardware bug that can't be fixed? > > At least in Axel's case, it seems to be fixed by v2.6.36-rc1~571^2~706 > "atl1c: Add AR8151 v2 support and change L0s/L1 routine". > > Luis R. Rodriguez wrote: > > > FWIW we already provide daily backports of code through compat-wireless. > > compat-wireless will eventually be changed to "compat-drivers" to > > reflect that it has drivers backported other than 802.11. We also have > > stable releases of the Linux kernel backported for use on older releases. > > I looked at the relevant repositories and am afraid I am too dim to see how to > use them. Can you please provide step-by-step instructions for producing an > mbox file with the appropriate compat-drivers patches to apply to a 2.6.32.y > kernel from kernel.org? > > I am also concerned about the support policy --- it seems that compat-drivers > tracks mainline and even newer developments fairly closely and does not > restrict itself to bugfixes, support for new hardware, and other changes that > are important enough to outweigh the risk of regressions. The cost of a > regression is higher on a machine that is normally only updated every couple > of months or so, as is the case for many machines running Debian squeeze. Is > there something like compat-drivers that tracks some more stable tree such > as 3.0.y instead of mainline? > > Thanks and hope that helps, > Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#664461: [squeeze] atl1c: AR8152: "transmit queue 0 timed out" and network is unusable until reset
Hi Jonath For backport of atl1c/alx, you could get the driver from http://www.linuxfoundation.org/collaborate/workgroups/networking/alx or go directly to http://www.orbit-lab.org/kernel/compat-wireless-2.6/2012/ thanks Xiong > -Original Message- > From: Jonathan Nieder [mailto: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 unusable until reset > > Jonathan Nieder wrote: > > Luis R. Rodriguez wrote: > > >> FWIW we already provide daily backports of code through compat-wireless. > >> compat-wireless will eventually be changed to "compat-drivers" to > >> reflect that it has drivers backported other than 802.11. We also > >> have stable releases of the Linux kernel backported for use on older > releases. > > > > I looked at the relevant repositories and am afraid I am too dim to > > see how to use them. > > Ok, it's becoming a little clearer now. Is the appropriate procedure > something > like this? > > git clone git://github.com/mcgrof/compat.git > git clone git://github.com/mcgrof/compat-wireless.git > cd compat-wireless > git checkout linux-3.0.y > GIT_COMPAT_TREE=$(pwd)/compat/ > NEXT_TREE=/path/to/src/linux > GIT_TREE=/path/to/linux/repo > export GIT_TREE GIT_COMPAT_TREE > > scripts/gen-stable-release.sh > > And then this will not generate a list of patches but just a patched source > code > tree with appropriate #ifdefs to make the code build against old kernels. > > That sounds useful. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#664461: [squeeze] atl1c: AR8152: "transmit queue 0 timed out" and network is unusable until reset
> > 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 hardware to test). The major difference I'm concerned about is in > VLAN handling; I'm not sure that the backported version of the driver will > configure the MAC properly for VLAN tag removal whenever it should. > I will review it. but I have not environment to test VLAN :( > > Most of the time, the issue of tx q0 timeout is caused by wrong > > HW configuration and bad cable condition. > > It will cause the PHY/cable link unstable, and the driver doesn't > > correctly reset the DMA engine and clear all Pending tx-packet while > > link down --- and timeout issue will appear. > [...] > > So is this fixed in the current driver version? Or are you saying that this > is a > hardware bug that can't be fixed? > You can think so, I mean the latest driver. -Xiong
Bug#664461: [squeeze] atl1c: AR8152: "transmit queue 0 timed out" and network is unusable until reset
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 will cause the PHY/cable link unstable, and the driver doesn't correctly reset the DMA engine and clear all Pending tx-packet while link down --- and timeout issue will appear. Thanks Xiong > -Original Message- > From: Jonathan Nieder [mailto:jrnie...@gmail.com] > Sent: Thursday, May 10, 2012 6:16 > To: a...@users.sourceforge.net > Cc: 664...@bugs.debian.org; nic-devel; Rodriguez, Luis > Subject: Re: [squeeze] atl1c: AR8152: "transmit queue 0 timed out" and > network is unusable until reset > > a...@users.sourceforge.net wrote[1]: > > > My latest call to 'aptitude safe-upgrade' installed version #44 > > replacing my patched version #41 − and, unfortunately, I have to > > report that the bug immediately reappeared when I rebooted. So I had > > to downgrade back to my patched #41, which continues to work without > problems. > > Thanks again for testing. > > Debian kernel maintainers: please apply the attached patch, which applies > the following changes from upstream: > > v2.6.36-rc1~571^2~706 atl1c: Add AR8151 v2 support and change L0s/L1 > routine > v2.6.39-rc6~7^2~26atl1c: Fix work event interrupt/task races > v2.6.38-rc4~15^2~14 atl1c: Add missing PCI device ID > > Axel has been testing the first two since the middle of April. The third just > adds a new PCI id and there haven't been any relevant changes upstream > since then so I think it should be safe, but I'd nonetheless prefer to see > these > changes get a little exposure in squeeze-proposed-updates before the > corresponding point release to be safe. > > Atheros maintainers: after this change, the list of atl1c patches queued for > Debian 6.0r6 on top of 2.6.32.y would be > > 496c185c9495 atl1c: Add support for Atheros AR8152 and AR8152 > 33ac0b84eeca atl1c: Fix hardware type check for enabling OTP CLK > 8f574b35f22f atl1c: Add AR8151 v2 support and change L0s/L1 routine > cb771838715b atl1c: Fix work event interrupt/task races 94dde7e451fa atl1c: > Add missing PCI device ID > > Is that list missing any important fixes? If you'd like a git tree, source > tarball, > or Debian package to test, feel free to ask. > > Thoughts welcome, as usual. Alas, the patch is too large for the upstream - > stable tree (where new hardware support is not as much of a priority), so I > don't think it would be easy to get help from there. > > Hope that helps, > Jonathan > > [1] http://bugs.debian.org/664461
