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:jrnieder@gmail.com]
> Sent: Thursday, July 05, 2012 1:47
> 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
Reply to: