Bug#622971: ath9k: Ath9K wireless quite unreliable since upgrade to 2.6.38
Marcos Raul Carot Collins wrote: On Domingo 26 Febrero 2012 11:00:43 usted escribió: Marcos Raul Carot Collins wrote: Looks like the kernel 3.2 always freezes after this message is recorded in /var/log/messages: cfg80211: Calling CRDA to update world regulatory domain. Mind if I forward this message to the bug log? You are making me a favor if you do :) As a little test I disabled ath9k with modprobe -r ath9k and the system kept without freezing for a couple hours (I had to reboot then for other reasons). It usually freezes in the first 15 minutes. with ath9k loaded. Ok, thanks. Forwarding to the bug log; for the future, you can do the same by cc-ing 622...@bugs.debian.org, for example by using your mailer's reply-to-all feature. -- 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/20120226064937.GE3030@burratino
Bug#622971: ath9k: Ath9K wireless quite unreliable since upgrade to 2.6.38
Hi Marcos, Marcos Raul Carot Collins wrote: Sorry to report, but after several weeks of usage, it still happens, in the two systems where I have this wireless card. What is the newest unaffected version you know of? If you can reproduce this with 3.2.y or newer, please report it upstream to ath9k-de...@lists.ath9k.org, cc-ing linux-wirel...@vger.kernel.org and either me or this bug log so we can track it. Be sure to mention: - steps to reproduce the problem, assuming one has the same hardware - expected result, actual result, and how the difference indicates a bug - which kernel versions you have tested and what happened with each - full dmesg output from an affected kernel, as an attachment - what kind of tests you would be able to perform (e.g., if someone provides debugging patches, would you be willing to test them?) - any other weird observations or workarounds - a link to this bug log for the full story If it doesn't reproduce the problem, that would be interesting too, but no need to bother upstream in that case. :) 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/20120216001114.GA29649@burratino
Bug#622971: ath9k: Ath9K wireless quite unreliable since upgrade to 2.6.38
Jose A. Medrano wrote: Same issue, starts working but suddenly it fails, and modprobe -r ath9k doesn't fix it. Unfortunately I suspect this bug is tracking a batch of related issues, since details like that vary from submitter to submitter. :/ Please feel free to file a separate report with something reproducible and concrete (we can merge reports that turn out to have the same cause later). What is the newest version you've tried that worked without trouble and the oldest that exhibited problems? Can you narrow the regression range with a bisection search through packages at snapshot.debian.org? Thanks, 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/20110912181730.GB28856@elie
Bug#622971: ath9k: Ath9K wireless quite unreliable since upgrade to 2.6.38
Hi
Neither crda nor wpasupplicant are responsible for such a behaviour,
but this bug is likely fixed by the attached patch, which will end up
in the upcoming 2.6.38.5 kernel.
Regards
Stefan Lippers-Hollmann
-- Forwarded Message --
Betreff: Patch ath9k_hw: partially revert fix dma descriptor rx error bit
parsing has been added to the 2.6.38-stable tree
Date: Monday 25 April 2011
From: gre...@suse.de
To: n...@openwrt.org, gre...@suse.de, linvi...@tuxdriver.com
This is a note to let you know that I've just added the patch titled
ath9k_hw: partially revert fix dma descriptor rx error bit parsing
to the 2.6.38-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ath9k_hw-partially-revert-fix-dma-descriptor-rx-error-bit-parsing.patch
and it can be found in the queue-2.6.38 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let sta...@kernel.org know about it.
From 115dad7a7f42e68840392767323ceb9306dbdb36 Mon Sep 17 00:00:00 2001
From: Felix Fietkau n...@openwrt.org
Date: Fri, 14 Jan 2011 00:06:27 +0100
Subject: ath9k_hw: partially revert fix dma descriptor rx error bit parsing
From: Felix Fietkau n...@openwrt.org
commit 115dad7a7f42e68840392767323ceb9306dbdb36 upstream.
The rx error bit parsing was changed to consider PHY errors and various
decryption errors separately. While correct according to the documentation,
this is causing spurious decryption error reports in some situations.
Fix this by restoring the original order of the checks in those places,
where the errors are meant to be mutually exclusive.
If a CRC error is reported, then MIC failure and decryption errors
are irrelevant, and a PHY error is unlikely.
Signed-off-by: Felix Fietkau n...@openwrt.org
Signed-off-by: John W. Linville linvi...@tuxdriver.com
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
---
drivers/net/wireless/ath/ath9k/ar9003_mac.c |8
drivers/net/wireless/ath/ath9k/mac.c| 14 ++
2 files changed, 14 insertions(+), 8 deletions(-)
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -615,7 +615,7 @@ int ath9k_hw_process_rxdesc_edma(struct
*/
if (rxsp-status11 AR_CRCErr)
rxs-rs_status |= ATH9K_RXERR_CRC;
- if (rxsp-status11 AR_PHYErr) {
+ else if (rxsp-status11 AR_PHYErr) {
phyerr = MS(rxsp-status11, AR_PHYErrCode);
/*
* If we reach a point here where AR_PostDelimCRCErr is
@@ -638,11 +638,11 @@ int ath9k_hw_process_rxdesc_edma(struct
rxs-rs_phyerr = phyerr;
}
- }
- if (rxsp-status11 AR_DecryptCRCErr)
+ } else if (rxsp-status11 AR_DecryptCRCErr)
rxs-rs_status |= ATH9K_RXERR_DECRYPT;
- if (rxsp-status11 AR_MichaelErr)
+ else if (rxsp-status11 AR_MichaelErr)
rxs-rs_status |= ATH9K_RXERR_MIC;
+
if (rxsp-status11 AR_KeyMiss)
rxs-rs_status |= ATH9K_RXERR_DECRYPT;
}
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -690,17 +690,23 @@ int ath9k_hw_rxprocdesc(struct ath_hw *a
rs-rs_flags |= ATH9K_RX_DECRYPT_BUSY;
if ((ads.ds_rxstatus8 AR_RxFrameOK) == 0) {
+ /*
+* Treat these errors as mutually exclusive to avoid spurious
+* extra error reports from the hardware. If a CRC error is
+* reported, then decryption and MIC errors are irrelevant,
+* the frame is going to be dropped either way
+*/
if (ads.ds_rxstatus8 AR_CRCErr)
rs-rs_status |= ATH9K_RXERR_CRC;
- if (ads.ds_rxstatus8 AR_PHYErr) {
+ else if (ads.ds_rxstatus8 AR_PHYErr) {
rs-rs_status |= ATH9K_RXERR_PHY;
phyerr = MS(ads.ds_rxstatus8, AR_PHYErrCode);
rs-rs_phyerr = phyerr;
- }
- if (ads.ds_rxstatus8 AR_DecryptCRCErr)
+ } else if (ads.ds_rxstatus8 AR_DecryptCRCErr)
rs-rs_status |= ATH9K_RXERR_DECRYPT;
- if (ads.ds_rxstatus8 AR_MichaelErr)
+ else if (ads.ds_rxstatus8 AR_MichaelErr)
rs-rs_status |= ATH9K_RXERR_MIC;
+
if (ads.ds_rxstatus8 AR_KeyMiss)
rs-rs_status |= ATH9K_RXERR_DECRYPT;
}
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
Bug#622971: ath9k: Ath9K wireless quite unreliable since upgrade to 2.6.38
Thanks Stefan,
I will test as soon as 38.5 hits testing (or maybe I will game enough to do it
from unstable!)
Cheers,
Marcos
On Martes 26 Abril 2011 06:01:27 usted escribió:
Hi
Neither crda nor wpasupplicant are responsible for such a behaviour,
but this bug is likely fixed by the attached patch, which will end up
in the upcoming 2.6.38.5 kernel.
Regards
Stefan Lippers-Hollmann
-- Forwarded Message --
Betreff: Patch ath9k_hw: partially revert fix dma descriptor rx error bit
parsing has been added to the 2.6.38-stable tree Date: Monday 25 April
2011
From: gre...@suse.de
To: n...@openwrt.org, gre...@suse.de, linvi...@tuxdriver.com
This is a note to let you know that I've just added the patch titled
ath9k_hw: partially revert fix dma descriptor rx error bit parsing
to the 2.6.38-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=su
mmary
The filename of the patch is:
ath9k_hw-partially-revert-fix-dma-descriptor-rx-error-bit-parsing.patch
and it can be found in the queue-2.6.38 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let sta...@kernel.org know about it.
From 115dad7a7f42e68840392767323ceb9306dbdb36 Mon Sep 17 00:00:00 2001
From: Felix Fietkau n...@openwrt.org
Date: Fri, 14 Jan 2011 00:06:27 +0100
Subject: ath9k_hw: partially revert fix dma descriptor rx error bit
parsing
From: Felix Fietkau n...@openwrt.org
commit 115dad7a7f42e68840392767323ceb9306dbdb36 upstream.
The rx error bit parsing was changed to consider PHY errors and various
decryption errors separately. While correct according to the documentation,
this is causing spurious decryption error reports in some situations.
Fix this by restoring the original order of the checks in those places,
where the errors are meant to be mutually exclusive.
If a CRC error is reported, then MIC failure and decryption errors
are irrelevant, and a PHY error is unlikely.
Signed-off-by: Felix Fietkau n...@openwrt.org
Signed-off-by: John W. Linville linvi...@tuxdriver.com
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
---
drivers/net/wireless/ath/ath9k/ar9003_mac.c |8
drivers/net/wireless/ath/ath9k/mac.c| 14 ++
2 files changed, 14 insertions(+), 8 deletions(-)
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -615,7 +615,7 @@ int ath9k_hw_process_rxdesc_edma(struct
*/
if (rxsp-status11 AR_CRCErr)
rxs-rs_status |= ATH9K_RXERR_CRC;
- if (rxsp-status11 AR_PHYErr) {
+ else if (rxsp-status11 AR_PHYErr) {
phyerr = MS(rxsp-status11, AR_PHYErrCode);
/*
* If we reach a point here where AR_PostDelimCRCErr is
@@ -638,11 +638,11 @@ int ath9k_hw_process_rxdesc_edma(struct
rxs-rs_phyerr = phyerr;
}
- }
- if (rxsp-status11 AR_DecryptCRCErr)
+ } else if (rxsp-status11 AR_DecryptCRCErr)
rxs-rs_status |= ATH9K_RXERR_DECRYPT;
- if (rxsp-status11 AR_MichaelErr)
+ else if (rxsp-status11 AR_MichaelErr)
rxs-rs_status |= ATH9K_RXERR_MIC;
+
if (rxsp-status11 AR_KeyMiss)
rxs-rs_status |= ATH9K_RXERR_DECRYPT;
}
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -690,17 +690,23 @@ int ath9k_hw_rxprocdesc(struct ath_hw *a
rs-rs_flags |= ATH9K_RX_DECRYPT_BUSY;
if ((ads.ds_rxstatus8 AR_RxFrameOK) == 0) {
+ /*
+ * Treat these errors as mutually exclusive to avoid spurious
+ * extra error reports from the hardware. If a CRC error is
+ * reported, then decryption and MIC errors are irrelevant,
+ * the frame is going to be dropped either way
+ */
if (ads.ds_rxstatus8 AR_CRCErr)
rs-rs_status |= ATH9K_RXERR_CRC;
- if (ads.ds_rxstatus8 AR_PHYErr) {
+ else if (ads.ds_rxstatus8 AR_PHYErr) {
rs-rs_status |= ATH9K_RXERR_PHY;
phyerr = MS(ads.ds_rxstatus8, AR_PHYErrCode);
rs-rs_phyerr = phyerr;
- }
- if (ads.ds_rxstatus8 AR_DecryptCRCErr)
+ } else if (ads.ds_rxstatus8 AR_DecryptCRCErr)
rs-rs_status |= ATH9K_RXERR_DECRYPT;
- if (ads.ds_rxstatus8 AR_MichaelErr)
+ else if (ads.ds_rxstatus8 AR_MichaelErr)
rs-rs_status |= ATH9K_RXERR_MIC;
+
if (ads.ds_rxstatus8 AR_KeyMiss)
rs-rs_status |=
Bug#622971: ath9k: Ath9K wireless quite unreliable since upgrade to 2.6.38
Package: linux-2.6 Version: 2.6.38-3 Severity: important File: ath9k ath9k disconects quite often (around 10 times a day) since upgrading the kernel to 2.6.38-2. Workaround is to modprob -r ath9k and then modprob ath9k. I am happy to test and collect more info, just tell me what to do. Cheers, Marcos -- Package-specific info: ** Version: Linux version 2.6.38-2-amd64 (Debian 2.6.38-3) (b...@decadent.org.uk) (gcc version 4.4.5 (Debian 4.4.5-15) ) #1 SMP Thu Apr 7 04:28:07 UTC 2011 ** Command line: BOOT_IMAGE=/vmlinuz-2.6.38-2-amd64 root=/dev/md0 ro quiet ** Tainted: PO (4097) * Proprietary module has been loaded. * Out-of-tree module has been loaded. ** Kernel log: [128307.280528] ath: Unable to set channel [128307.403124] ath: Unable to reset channel (2427 MHz), reset status -5 [128307.972551] ath: Unable to reset channel (2427 MHz), reset status -5 [128308.100140] ath: Unable to set channel [128308.100183] ath: Unable to set channel [128308.100220] ath: Unable to set channel [128308.100256] ath: Unable to set channel [128308.100291] ath: Unable to set channel [128308.100327] ath: Unable to set channel [128308.100362] ath: Unable to set channel [128308.100397] ath: Unable to set channel [128308.100433] ath: Unable to set channel [128308.100468] ath: Unable to set channel [128308.100504] ath: Unable to set channel [128308.100550] ath: Unable to set channel [128308.223125] ath: Unable to reset channel (2427 MHz), reset status -5 [128308.845761] ath: Unable to reset channel (2427 MHz), reset status -5 [128308.972129] ath: Unable to set channel [128308.972172] ath: Unable to set channel [128308.972208] ath: Unable to set channel [128308.972244] ath: Unable to set channel [128308.972279] ath: Unable to set channel [128308.972315] ath: Unable to set channel [128308.972350] ath: Unable to set channel [128308.972386] ath: Unable to set channel [128308.972421] ath: Unable to set channel [128308.972456] ath: Unable to set channel [128308.972492] ath: Unable to set channel [128308.972538] ath: Unable to set channel [128309.095171] ath: Unable to reset channel (2427 MHz), reset status -5 [128315.158076] ath: Unable to reset channel (2427 MHz), reset status -5 [128315.284105] ath: Unable to set channel [128315.284182] ath: Unable to set channel [128315.284251] ath: Unable to set channel [128315.284319] ath: Unable to set channel [128315.284387] ath: Unable to set channel [128315.284455] ath: Unable to set channel [128315.284523] ath: Unable to set channel [128315.284591] ath: Unable to set channel [128315.284659] ath: Unable to set channel [128315.284726] ath: Unable to set channel [128315.284794] ath: Unable to set channel [128315.284873] ath: Unable to set channel [128315.407475] ath: Unable to reset channel (2427 MHz), reset status -5 [128320.532887] ath9k :05:06.0: PCI INT A disabled [128320.532936] ath9k: Driver unloaded [128325.380139] cfg80211: Calling CRDA to update world regulatory domain [128325.825609] ath9k :05:06.0: PCI INT A - GSI 20 (level, low) - IRQ 20 [128326.257128] ath: EEPROM regdomain: 0x809c [128326.257130] ath: EEPROM indicates we should expect a country code [128326.257131] ath: doing EEPROM country-regdmn map search [128326.257132] ath: country maps to regdmn code: 0x52 [128326.257133] ath: Country alpha2 being used: CN [128326.257134] ath: Regpair used: 0x52 [128326.260718] ieee80211 phy0: Selected rate control algorithm 'ath9k_rate_control' [128326.261221] Registered led device: ath9k-phy0::radio [128326.261234] Registered led device: ath9k-phy0::assoc [128326.261248] Registered led device: ath9k-phy0::tx [128326.261260] Registered led device: ath9k-phy0::rx [128326.261263] ieee80211 phy0: Atheros AR5416 MAC/BB Rev:2 AR2133 RF Rev:81 mem=0xc900117a, irq=20 [128330.909935] ADDRCONF(NETDEV_UP): wlan0: link is not ready [128335.849109] ADDRCONF(NETDEV_UP): wlan0: link is not ready [128336.106890] ADDRCONF(NETDEV_UP): wlan0: link is not ready [128339.564767] wlan0: authenticate with 94:0c:6d:fe:2d:84 (try 1) [128339.567338] wlan0: authenticated [128339.567385] wlan0: associate with 94:0c:6d:fe:2d:84 (try 1) [128339.571810] wlan0: RX AssocResp from 94:0c:6d:fe:2d:84 (capab=0x431 status=0 aid=3) [128339.571819] wlan0: associated [128339.577286] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [128350.552085] wlan0: no IPv6 routers present [128408.330298] cfg80211: Calling CRDA for country: CN [128409.180804] wlan0: authenticate with 94:0c:6d:fe:2d:84 (try 1) [128409.182719] wlan0: authenticated [128409.182771] wlan0: associate with 94:0c:6d:fe:2d:84 (try 1) [128409.187199] wlan0: RX AssocResp from 94:0c:6d:fe:2d:84 (capab=0x431 status=0 aid=3) [128409.187207] wlan0: associated [128441.356567] cfg80211: Calling CRDA to update world regulatory domain [128442.208994] wlan0: authenticate with 94:0c:6d:fe:2d:84 (try 1) [128442.210933] wlan0: authenticated [128442.210978] wlan0: associate with 94:0c:6d:fe:2d:84 (try 1) [128442.215339] wlan0: RX AssocResp from
