Bug#664461: [squeeze] atl1c: AR8152: "transmit queue 0 timed out" and network is unusable until reset

["Huang, Xiong" <xiong@qca.qualcomm.com>]

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; 664461@bugs.debian.org; axst@users.sourceforge.net; nic-
> devel; mcgrof@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 [jrnieder@gmail.com]
> Sent: Wednesday, July 04, 2012 10:46 AM
> To: Ben Hutchings
> Cc: Huang, Xiong; 664461@bugs.debian.org; axst@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 +0000, 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