BTW I'll reply tomorrow :D
Luis
________________________________________
From: Rodriguez, Luis
Sent: Wednesday, July 04, 2012 4:49 PM
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 +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
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/7a9adffa56024346aae90b6babc3bd15dd6...@nasanexd02b.na.qualcomm.com
