Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
On Sun, 2012-08-12 at 09:03 -0600, Jesse Rhodes wrote: > Yes, it does! Confirmed on both bcf3655... and 3.2.0-3 from sid. Why > would a cpufreq module break a PCI wireless card like that? According to a comment in the code that logs the error message: * If we are in a noisy environment, AGC calibration may time * out and/or noise floor calibration might timeout. Maybe the CPU frequency changes create additional noise in the wifi band. If so, I don't know how this can reasonably be avoided. CPU frequency scaling should normally be enabled, and Debian has for long a time enabled it by default on any computer detected as being a laptop or similar. (The kernel change just automated this at a slightly lower level.) ath5k developers, have you seen this failure mode before? The comment suggests there is a known hardware bug that can cause it; is it possible to work around that by retrying? Or is the timeout actually too low? Ben. > On Sat, Aug 11, 2012 at 9:43 PM, Ben Hutchings > wrote: > On Sat, 2012-08-11 at 21:17 -0600, Jesse Rhodes wrote: > > sney@bivouac:~/data/debian/linux$ git bisect good > > bcf3655971d24d7f08f373ed5830e8e11010088a is the first bad > commit > > commit bcf3655971d24d7f08f373ed5830e8e11010088a > > Author: Andi Kleen > > Date: Thu Jan 26 00:09:12 2012 +0100 > > > > cpufreq: Add support for x86 cpuinfo auto loading v4 > > [...] > > So does the problem go away if you unload the cpufreq driver > (powernow_k8)? > > Ben. > > -- > Ben Hutchings > Sturgeon's Law: Ninety percent of everything is crap. > -- Ben Hutchings Sturgeon's Law: Ninety percent of everything is crap. signature.asc Description: This is a digitally signed message part
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
I should also note that if I load powernow_k8 *after* my wireless is already working, the bug does not return. It only seems to happen if powernow_k8 loads first. On Sun, Aug 12, 2012 at 9:03 AM, Jesse Rhodes wrote: > Yes, it does! Confirmed on both bcf3655... and 3.2.0-3 from sid. Why would > a cpufreq module break a PCI wireless card like that? > > On Sat, Aug 11, 2012 at 9:43 PM, Ben Hutchings wrote: > >> On Sat, 2012-08-11 at 21:17 -0600, Jesse Rhodes wrote: >> > sney@bivouac:~/data/debian/linux$ git bisect good >> > bcf3655971d24d7f08f373ed5830e8e11010088a is the first bad commit >> > commit bcf3655971d24d7f08f373ed5830e8e11010088a >> > Author: Andi Kleen >> > Date: Thu Jan 26 00:09:12 2012 +0100 >> > >> > cpufreq: Add support for x86 cpuinfo auto loading v4 >> [...] >> >> So does the problem go away if you unload the cpufreq driver >> (powernow_k8)? >> >> Ben. >> >> -- >> Ben Hutchings >> Sturgeon's Law: Ninety percent of everything is crap. >> > >
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
Yes, it does! Confirmed on both bcf3655... and 3.2.0-3 from sid. Why would a cpufreq module break a PCI wireless card like that? On Sat, Aug 11, 2012 at 9:43 PM, Ben Hutchings wrote: > On Sat, 2012-08-11 at 21:17 -0600, Jesse Rhodes wrote: > > sney@bivouac:~/data/debian/linux$ git bisect good > > bcf3655971d24d7f08f373ed5830e8e11010088a is the first bad commit > > commit bcf3655971d24d7f08f373ed5830e8e11010088a > > Author: Andi Kleen > > Date: Thu Jan 26 00:09:12 2012 +0100 > > > > cpufreq: Add support for x86 cpuinfo auto loading v4 > [...] > > So does the problem go away if you unload the cpufreq driver > (powernow_k8)? > > Ben. > > -- > Ben Hutchings > Sturgeon's Law: Ninety percent of everything is crap. >
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
On Sat, 2012-08-11 at 21:17 -0600, Jesse Rhodes wrote: > sney@bivouac:~/data/debian/linux$ git bisect good > bcf3655971d24d7f08f373ed5830e8e11010088a is the first bad commit > commit bcf3655971d24d7f08f373ed5830e8e11010088a > Author: Andi Kleen > Date: Thu Jan 26 00:09:12 2012 +0100 > > cpufreq: Add support for x86 cpuinfo auto loading v4 [...] So does the problem go away if you unload the cpufreq driver (powernow_k8)? Ben. -- Ben Hutchings Sturgeon's Law: Ninety percent of everything is crap. signature.asc Description: This is a digitally signed message part
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
sney@bivouac:~/data/debian/linux$ git bisect good bcf3655971d24d7f08f373ed5830e8e11010088a is the first bad commit commit bcf3655971d24d7f08f373ed5830e8e11010088a Author: Andi Kleen Date: Thu Jan 26 00:09:12 2012 +0100 cpufreq: Add support for x86 cpuinfo auto loading v4 commit fa8031aefec0cf7ea6c2387c93610d99d9659aa2 upstream. This marks all the x86 cpuinfo tables to the CPU specific device drivers, to allow auto loading by udev. This should simplify the distribution startup scripts for this greatly. I didn't add MODULE_DEVICE_IDs to the centrino and p4-clockmod drivers, because those probably shouldn't be auto loaded and the acpi driver be used instead (not fully sure on that, would appreciate feedback) The old nforce drivers autoload based on the PCI ID. ACPI cpufreq is autoloaded in another patch. v3: Autoload gx based on PCI IDs only. Remove cpu check (Dave Jones) v4: Use newly introduce HW_PSTATE feature for powernow-k8 loading Cc: Dave Jones Cc: Kay Sievers Signed-off-by: Andi Kleen Signed-off-by: Thomas Renninger Acked-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman :04 04 9e8261ec125a438b1e1f36930cecbc9e72b55854 b5ede0d25adad661eb02fc4c9126cdf935eb01d5 Mdrivers sney@bivouac:~/data/debian/linux$ git bisect log git bisect start # good: [8499e79e9ee4c946ae38fd12e5d3afe8b68f2dfd] Linux 3.2.21 git bisect good 8499e79e9ee4c946ae38fd12e5d3afe8b68f2dfd # bad: [8846d9ca633324ae8596a13a511b77518061333e] Input: add Synaptics USB device driver git bisect bad 8846d9ca633324ae8596a13a511b77518061333e # good: [d2f0f9a196fe7120062ed23401b24a63609b5c98] x86, efi: Fix endian issues and unaligned accesses git bisect good d2f0f9a196fe7120062ed23401b24a63609b5c98 # good: [118c0878a89079ea69938680e78141169a0a21c1] be2net: Fix traffic stall INTx mode git bisect good 118c0878a89079ea69938680e78141169a0a21c1 # good: [4e197eba189f61cccb5ec25902ae45317d12be76] ethtool: allow ETHTOOL_GSSET_INFO for users git bisect good 4e197eba189f61cccb5ec25902ae45317d12be76 # bad: [7e2a68c51b56ef8a56ee331becb5f01f56b78865] x86/cpu: Fix overrun check in arch_print_cpu_modalias() git bisect bad 7e2a68c51b56ef8a56ee331becb5f01f56b78865 # good: [48532cdd091297c71fffa8a12e0064dc58218ff4] CPU: Introduce ARCH_HAS_CPU_AUTOPROBE and X86 parts git bisect good 48532cdd091297c71fffa8a12e0064dc58218ff4 # good: [e7b92c939bc8690e2c1188be1675aa106cdaf4c4] ACPI: Load acpi-cpufreq from processor driver automatically git bisect good e7b92c939bc8690e2c1188be1675aa106cdaf4c4 # good: [3a5874ab17f55524ec61176a81b5f9448d4eccad] HWMON: Convert coretemp to x86 cpuid autoprobing git bisect good 3a5874ab17f55524ec61176a81b5f9448d4eccad # bad: [bcf3655971d24d7f08f373ed5830e8e11010088a] cpufreq: Add support for x86 cpuinfo auto loading v4 git bisect bad bcf3655971d24d7f08f373ed5830e8e11010088a # good: [d339ab6933c6d8413ac002bda196ff3c0f3455aa] X86: Introduce HW-Pstate scattered cpuid feature git bisect good d339ab6933c6d8413ac002bda196ff3c0f3455aa Hope this helps you find the cause. On Fri, Aug 10, 2012 at 8:32 AM, Jesse Rhodes wrote: > Ok: > > 3.2.0-3 (3.2.23-1) also produces the timeouts. So, just "use the kernel > from sid" isn't even a workaround. I will continue bisecting. > > On Thu, Aug 9, 2012 at 10:41 AM, Ben Hutchings wrote: > >> On Thu, Aug 09, 2012 at 09:57:17AM -0600, Jesse Rhodes wrote: >> > Bisecting away. >> > >> > Is 3.2.0-3 (3.2.23-1) from sid exempt from the freeze? I'm going to try >> > that one as well. If it works, at least it'll likely work for the >> release, >> > though we should probably keep hunting for the cause of this bug lest it >> > surface again. >> >> The kernel and release teams are in close contact, and all linux >> uploads to sid are expected to be eligible for freeze exceptions. >> >> Ben. >> >> -- >> Ben Hutchings >> We get into the habit of living before acquiring the habit of thinking. >> - Albert >> Camus >> > >
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
Ok: 3.2.0-3 (3.2.23-1) also produces the timeouts. So, just "use the kernel from sid" isn't even a workaround. I will continue bisecting. On Thu, Aug 9, 2012 at 10:41 AM, Ben Hutchings wrote: > On Thu, Aug 09, 2012 at 09:57:17AM -0600, Jesse Rhodes wrote: > > Bisecting away. > > > > Is 3.2.0-3 (3.2.23-1) from sid exempt from the freeze? I'm going to try > > that one as well. If it works, at least it'll likely work for the > release, > > though we should probably keep hunting for the cause of this bug lest it > > surface again. > > The kernel and release teams are in close contact, and all linux > uploads to sid are expected to be eligible for freeze exceptions. > > Ben. > > -- > Ben Hutchings > We get into the habit of living before acquiring the habit of thinking. > - Albert > Camus >
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
On Thu, Aug 09, 2012 at 09:57:17AM -0600, Jesse Rhodes wrote: > Bisecting away. > > Is 3.2.0-3 (3.2.23-1) from sid exempt from the freeze? I'm going to try > that one as well. If it works, at least it'll likely work for the release, > though we should probably keep hunting for the cause of this bug lest it > surface again. The kernel and release teams are in close contact, and all linux uploads to sid are expected to be eligible for freeze exceptions. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20120809164108.gr1...@decadent.org.uk
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
Bisecting away. Is 3.2.0-3 (3.2.23-1) from sid exempt from the freeze? I'm going to try that one as well. If it works, at least it'll likely work for the release, though we should probably keep hunting for the cause of this bug lest it surface again.
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
tags 681232 - patch quit Jesse Rhodes wrote: > (iii) broke, > (iv) worked. Weird. I can't find any obvious candidate for a patch that would have broken the driver. Can you bisect? Even a few iterations would help a lot in narrowing down the search. It works like so: cd linux git bisect start git checkout v3.2.21; # vanilla kernel make deb-pkg; # optionally with -j for parallel build dpkg -i ../; # as root reboot ... test test test ... # hopefully it avoids the bug, so cd linux git bisect good git checkout debian/wheezy; # patched kernel make deb-pkg; # maybe with -j4 dpkg -i ../; # as root reboot ... test test test ... # hopefully it reproduces the bug, so cd linux git bisect bad # a rev halfway between is automatically checked out # to test make deb-pkg; # maybe with -j4 dpkg -i ../; # as root reboot ... test test test ... cd linux git bisect bad; # if it reproduces the bug git bisect good; # if it reliably does not git bisect skip; # if some other bug makes it hard to test # another rev to test is automatically checked out ... continue until it finds the "first bad rev" ... At any step you can watch the regression range narrowing by running "git bisect visualize" if the gitk package is installed. When finished or bored, please run "git bisect log" to list revs it has tested so others can analyze your results or pick up where you left off. Thanks again, and sorry I have no better ideas. Sincerely, 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/20120809071322.GF174@mannheim-rule.local
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
(iii) broke, (iv) worked. On Tue, Aug 7, 2012 at 1:17 PM, Jonathan Nieder wrote: > Hi again, > > Jesse Rhodes wrote: > > > (i) 3.2.21-1 from snapshot produces the gain calibration timeouts. > > > > (ii) so does a rebuild of debian patched 3.2.21-3. > > Ok, perfect. > > Two more tests: > > (iii) patched 3.2.21-3 with .config used for vanilla 3.2.21? > (iv) vanilla 3.2.21 with Debian .config > > Thanks for your patience, > Jonathan >
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
Hi again, Jesse Rhodes wrote: > (i) 3.2.21-1 from snapshot produces the gain calibration timeouts. > > (ii) so does a rebuild of debian patched 3.2.21-3. Ok, perfect. Two more tests: (iii) patched 3.2.21-3 with .config used for vanilla 3.2.21? (iv) vanilla 3.2.21 with Debian .config Thanks for your patience, 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/20120807191752.GA181@mannheim-rule.local
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
(i) 3.2.21-1 from snapshot produces the gain calibration timeouts. (ii) so does a rebuild of debian patched 3.2.21-3. Other kernels tried so far in order (we'll use "worked" for functional wifi, and "broke" for calibration timeouts): debian 3.2.0-2 (3.2.20-1) worked debian 3.2.0-3 (3.2.21-3) broke vanilla 3.2.20 worked vanilla 3.2.21 worked snapshot.d.o 3.3.0-rc6 (3.3~rc6-1~experimental.1) worked patched 3.2.y (3.2.25 with previous attached patches) worked debian 3.2.0-3 (3.2.21-3) still broke # got paranoid, tried it again On Tue, Aug 7, 2012 at 1:08 AM, Jonathan Nieder wrote: > Jesse Rhodes wrote: > > > Well, it's not going to happen when I'm using 3.2.0-2, and it always > > happens on 3.2.0-3 rendering it basically useless for a working system > > Thanks for clarifying. I missed that you had tried 3.2.21-3 again. > > Could you list the versions you've tested, in order, and what happened > with each for future reference? > > [...] > > Since 3.2.0-3 reports itself as Version: 3.2.21-3, and vanilla 3.2.21 > > worked fine, > > Ok, here are two tests to try. > > (i) Am I correct in guessing 3.2.21-1 from snapshot.debian.org > produces the gain calibration timeouts, too? > > (ii) Here is a way of testing if the build process changed anything, > by building the same source with the same configuration: > > cd linux > > # fetch Debian-patched kernel > git remote add debian \ > git://git.debian.org/kernel/linux.git > git fetch debian > > # configure, build, test > git checkout debian/wheezy > cp /boot/config-3.2.0-3-amd64 .config > scripts/config --disable DEBUG_INFO > make deb-pkg; # optionally with -j for parallel build > dpkg -i ../; # as root > ... test test test ... > > Thanks again, and sorry for the fuss, > Jonathan >
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
Jesse Rhodes wrote: > Well, it's not going to happen when I'm using 3.2.0-2, and it always > happens on 3.2.0-3 rendering it basically useless for a working system Thanks for clarifying. I missed that you had tried 3.2.21-3 again. Could you list the versions you've tested, in order, and what happened with each for future reference? [...] > Since 3.2.0-3 reports itself as Version: 3.2.21-3, and vanilla 3.2.21 > worked fine, Ok, here are two tests to try. (i) Am I correct in guessing 3.2.21-1 from snapshot.debian.org produces the gain calibration timeouts, too? (ii) Here is a way of testing if the build process changed anything, by building the same source with the same configuration: cd linux # fetch Debian-patched kernel git remote add debian \ git://git.debian.org/kernel/linux.git git fetch debian # configure, build, test git checkout debian/wheezy cp /boot/config-3.2.0-3-amd64 .config scripts/config --disable DEBUG_INFO make deb-pkg; # optionally with -j for parallel build dpkg -i ../; # as root ... test test test ... Thanks again, and sorry for the fuss, 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/20120807070847.GA19456@mannheim-rule.local
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
Well, it's not going to happen when I'm using 3.2.0-2, and it always happens on 3.2.0-3 rendering it basically useless for a working system - not only is my network controller unusable, it also constantly spams the console with those "gain calibration timeout" messages. Since 3.2.0-3 reports itself as Version: 3.2.21-3, and vanilla 3.2.21 worked fine, it must be some difference between the debian build and the upstream 3.2.21 that is causing this issue. Right? On Sun, Aug 5, 2012 at 6:41 PM, Jonathan Nieder wrote: > Jesse Rhodes wrote: > > > Steps a. and c.: Neither 3.3.0-rc6 (from snapshots), nor 3.2.21, nor > 3.2.20 > > reproduced the bug. I'm typing this email from 3.2.21 right now with a > > fully functional wireless connection. > > Thanks, Jesse. I'd suggest using whatever kernel is most convenient > and letting us know whether it's happened again in a few days. > > Do you mind if I forward your reply to the bug log? > > Ciao, > Jonathan >
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
copying my message to everyone else manually because gmail ate my CC. Hi there, Steps a. and c.: Neither 3.3.0-rc6 (from snapshots), nor 3.2.21, nor 3.2.20 reproduced the bug. I'm typing this email from 3.2.21 right now with a fully functional wireless connection. I skipped step b. due to not having a bad bisect to refer to. Step d.: 3.2.25+ including the attached patches also failed to reproduce the bug. Not sure where to go from here but I'll keep digging if you point me in the right direction. sney On Sun, Aug 5, 2012 at 2:37 AM, Jonathan Nieder wrote: > tags 681232 + patch moreinfo > quit > > Hi, > > Russ Lind wrote: > > > For what it's worth, the 3.5-1 kernel from experimental works for me > [...] > > I'd also built the 3.4.7 kernel from the sources at kernel.org. > [...] > > I've read about a number of people having this issue thru the 3.3 > > kernels with various distros, and read the issue was supposedly > > fixed in the 3.4 branch. I get the impression it's an upstream > > issue. > > Maybe one of the following patches helped. > > v3.3-rc1~182^2~44^2~292 ath5k: Calibration re-work > > v3.4-rc1~177^2~108^2~108 ath5k: do not stop queues for full >calibration > > v3.4-rc1~177^2~108^2~107 ath5k: do not re-run AGC calibration >periodically > > What seems oddest to me is that I'm not aware of any patches from > the range 3.2.20->3.2.21 that might have had this effect. Are you > sure that 3.2.20 did not reproduce the bug? If you have time to try > one of the following, I'd be interested: > > a. Please test v3.2.20 and v3.2.21 from kernel.org, following > instructions from [1] or the following steps: > > # get the kernel history, if you don't already have it > git clone \ > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > # fetch point releases: > cd linux > git remote add stable \ > git:// > git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git > git fetch stable > > # configure, build, test: > git checkout v3.2.21 > cp /boot/config-$(uname -r) .config; # current configuration > scripts/config --disable DEBUG_INFO > make localmodconfig; # optional: minimize configuration > make deb-pkg; # optionally with -j for parallel build > dpkg -i ../; # as root > reboot > ... test test test ... > > # hopefully it reproduces the bug, so try the older kernel: > cd linux > git checkout v3.2.20 > make deb-pkg; # maybe with -j4 > dpkg -i ../; # as root > reboot > ... test test test ... > > # hopefully it does not reproduce the bug > > b. If (a) goes well, please bisect to find which patch introduced > the bug, as described at [2]: > > cd linux > git bisect start > git bisect good > git bisect bad v3.2.21 > > # a version halfway between is automatically checked out > make deb-pkg; # maybe with -j4 > dpkg -i ../; # as root > reboot > ... test test test ... > cd linux > git bisect good; # if it works well > git bisect bad; # if it reproduces the calibration timeouts > git bisect skip; # if some other bug makes it hard to test > > ... rinse and repeat until it prints the "first bad commit" > or until bored ... > > # at any step, to see the regression range narrowing > apt-get install gitk > git bisect visualize > > # to get a log of revs tested so far, which will let someone > # else pick up where you left off > git bisect log > > c. How does a pre-compiled 3.3 kernel from http://snapshot.debian.org > do? > > d. Please test the three attached patches together against a 3.2.y > kernel, following the directions at [3] or the following > instructions: > > cd linux > git checkout stable/linux-3.2.y > git am -3sc $(ls -1 /path/to/patches/0[123]-*) > make deb-pkg; # maybe with -j4 > dpkg -i ../; # as root > reboot > ... test test test ... > > Hope that helps, > Jonathan > > [1] > http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-kernel-org-package > [2] http://kernel-handbook.alioth.debian.org/ch-bugs.html#s9.2.1 > [3] > http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official >
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
whoa, I'll see what I can do. Building the 3.4.7 kernel was my first try at building the kernel, I downloaded the bz2 file from kernel.org and followed the steps in Telemachus' post (post #5) in the following thread: http://forums.debian.net/viewtopic.php?f=16&t=36525 I haven't used git before but I will give your steps a try. I definitely did not have this problem with the 3.2.20 Debian kernel build. I diff'd the 3.2.20 and 3.2.21 kernel code (from kernel.org) in net/wireless/ath and I didn't see any differences so I was surprised the issue started happening with 3.2.21. On 08/05/2012 01:37 AM, Jonathan Nieder wrote: tags 681232 + patch moreinfo quit Hi, Russ Lind wrote: For what it's worth, the 3.5-1 kernel from experimental works for me [...] I'd also built the 3.4.7 kernel from the sources at kernel.org. [...] I've read about a number of people having this issue thru the 3.3 kernels with various distros, and read the issue was supposedly fixed in the 3.4 branch. I get the impression it's an upstream issue. Maybe one of the following patches helped. v3.3-rc1~182^2~44^2~292 ath5k: Calibration re-work v3.4-rc1~177^2~108^2~108 ath5k: do not stop queues for full calibration v3.4-rc1~177^2~108^2~107 ath5k: do not re-run AGC calibration periodically What seems oddest to me is that I'm not aware of any patches from the range 3.2.20->3.2.21 that might have had this effect. Are you sure that 3.2.20 did not reproduce the bug? If you have time to try one of the following, I'd be interested: a. Please test v3.2.20 and v3.2.21 from kernel.org, following instructions from [1] or the following steps: # get the kernel history, if you don't already have it git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git # fetch point releases: cd linux git remote add stable \ git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git git fetch stable # configure, build, test: git checkout v3.2.21 cp /boot/config-$(uname -r) .config; # current configuration scripts/config --disable DEBUG_INFO make localmodconfig; # optional: minimize configuration make deb-pkg; # optionally with -j for parallel build dpkg -i ../; # as root reboot ... test test test ... # hopefully it reproduces the bug, so try the older kernel: cd linux git checkout v3.2.20 make deb-pkg; # maybe with -j4 dpkg -i ../; # as root reboot ... test test test ... # hopefully it does not reproduce the bug b. If (a) goes well, please bisect to find which patch introduced the bug, as described at [2]: cd linux git bisect start git bisect good git bisect bad v3.2.21 # a version halfway between is automatically checked out make deb-pkg; # maybe with -j4 dpkg -i ../; # as root reboot ... test test test ... cd linux git bisect good; # if it works well git bisect bad; # if it reproduces the calibration timeouts git bisect skip; # if some other bug makes it hard to test ... rinse and repeat until it prints the "first bad commit" or until bored ... # at any step, to see the regression range narrowing apt-get install gitk git bisect visualize # to get a log of revs tested so far, which will let someone # else pick up where you left off git bisect log c. How does a pre-compiled 3.3 kernel from http://snapshot.debian.org do? d. Please test the three attached patches together against a 3.2.y kernel, following the directions at [3] or the following instructions: cd linux git checkout stable/linux-3.2.y git am -3sc $(ls -1 /path/to/patches/0[123]-*) make deb-pkg; # maybe with -j4 dpkg -i ../; # as root reboot ... test test test ... Hope that helps, Jonathan [1] http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-kernel-org-package [2] http://kernel-handbook.alioth.debian.org/ch-bugs.html#s9.2.1 [3] http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official -- 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/501e8d6b.6060...@comcast.net
Bug#681232: [3.2.20->3.2.21 regression] Atheros WiFi Adapter couldn't find networks "gain calibration timeout"
tags 681232 + patch moreinfo quit Hi, Russ Lind wrote: > For what it's worth, the 3.5-1 kernel from experimental works for me [...] > I'd also built the 3.4.7 kernel from the sources at kernel.org. [...] > I've read about a number of people having this issue thru the 3.3 > kernels with various distros, and read the issue was supposedly > fixed in the 3.4 branch. I get the impression it's an upstream > issue. Maybe one of the following patches helped. v3.3-rc1~182^2~44^2~292 ath5k: Calibration re-work v3.4-rc1~177^2~108^2~108 ath5k: do not stop queues for full calibration v3.4-rc1~177^2~108^2~107 ath5k: do not re-run AGC calibration periodically What seems oddest to me is that I'm not aware of any patches from the range 3.2.20->3.2.21 that might have had this effect. Are you sure that 3.2.20 did not reproduce the bug? If you have time to try one of the following, I'd be interested: a. Please test v3.2.20 and v3.2.21 from kernel.org, following instructions from [1] or the following steps: # get the kernel history, if you don't already have it git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git # fetch point releases: cd linux git remote add stable \ git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git git fetch stable # configure, build, test: git checkout v3.2.21 cp /boot/config-$(uname -r) .config; # current configuration scripts/config --disable DEBUG_INFO make localmodconfig; # optional: minimize configuration make deb-pkg; # optionally with -j for parallel build dpkg -i ../; # as root reboot ... test test test ... # hopefully it reproduces the bug, so try the older kernel: cd linux git checkout v3.2.20 make deb-pkg; # maybe with -j4 dpkg -i ../; # as root reboot ... test test test ... # hopefully it does not reproduce the bug b. If (a) goes well, please bisect to find which patch introduced the bug, as described at [2]: cd linux git bisect start git bisect good git bisect bad v3.2.21 # a version halfway between is automatically checked out make deb-pkg; # maybe with -j4 dpkg -i ../; # as root reboot ... test test test ... cd linux git bisect good; # if it works well git bisect bad; # if it reproduces the calibration timeouts git bisect skip; # if some other bug makes it hard to test ... rinse and repeat until it prints the "first bad commit" or until bored ... # at any step, to see the regression range narrowing apt-get install gitk git bisect visualize # to get a log of revs tested so far, which will let someone # else pick up where you left off git bisect log c. How does a pre-compiled 3.3 kernel from http://snapshot.debian.org do? d. Please test the three attached patches together against a 3.2.y kernel, following the directions at [3] or the following instructions: cd linux git checkout stable/linux-3.2.y git am -3sc $(ls -1 /path/to/patches/0[123]-*) make deb-pkg; # maybe with -j4 dpkg -i ../; # as root reboot ... test test test ... Hope that helps, Jonathan [1] http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-kernel-org-package [2] http://kernel-handbook.alioth.debian.org/ch-bugs.html#s9.2.1 [3] http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official From: Nick Kossifidis Date: Fri, 25 Nov 2011 20:40:23 +0200 Subject: ath5k: Calibration re-work commit ce169aca0d823d38465127023e3d571816ec upstream. Noise floor calibration does not interfere with traffic and should run more often as part of our "short calibration". The full calibration is not the noise floor calibration but the AGC + Gain_F (on RF5111 and RF5112) calibration and should run less often because it does interfere with traffic. So Short calibration -> I/Q & NF Calibration Long calibration -> Short + AGC + Gain_F This patch was for some time on my pub/ dir on www.kernel.org and has been tested by a few people and me. I think it's O.K. to go in. I also changed ah_calibration to ah_iq_cal_needed to make more sense. v2 Use a workqueue instead of a tasklet for calibration Signed-off-by: Nick Kossifidis Signed-off-by: John W. Linville Signed-off-by: Jonathan Nieder --- drivers/net/wireless/ath/ath5k/ath5k.h | 15 ++--- drivers/net/wireless/ath/ath5k/base.c | 112 ++-- drivers/net/wireless/ath/ath5k/phy.c | 82 +-- 3 files changed, 147 insertions(+), 62 deletions(-) diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h index fecbcd9..9f9a681 100644 --- a/drivers/net/wireless/ath/ath5k/ath5k.h +++ b/drivers/net/wireless/ath/ath5k/ath5k.h @@ -187,10 +187,9 @@ #define AR5K_TUNE_MAX_TXPOWER 63 #define AR5K_TUNE_D
