Bug#622971: Fixed!
Linux-Image-3.2.9-1 does not freeze AND the atheros card works!! I noticed that it sometimes (very rarely) goes off line but recovers itself in a couple seconds unlike before that it needed modprobe -r ath9k, modprobe ath9k to come up again. I have been testing for about 3 days with no issues, THANKS! Marcos -- 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/201203150658.01387.marcos.ca...@gmail.com
Bug#622971: Still not good
Sorry to report, but after several weeks of usage, it still happens, in the two systems where I have this wireless card. If there is anything I can do to help figure out what the issue is (other than check the code!), let me know. Cheers, Marcos -- 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/201108301620.51641.marcos.ca...@gmail.com
Bug#622971: Testing now with 3.0
Hi Maximilian! Now that Linux 3.0 has hit testing, I am using it. So far so good, but will email you in a couple of days of usage to be sure. Thanks! -- 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/201108091317.26793.marcos.ca...@gmail.com
Bug#622971: Still happening with Kernel 2.6.39 in testing.
Just letting you know that this is still an issue. Any extra info that I can provide I am happy to collect. -- 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/201106211800.53260.marcos.ca...@gmail.com
Bug#622971: 2.6.38-5 behaviour
After using it for some days, the issue seems to still be there but manifests itself in a different way. Before 38-5 when the disconnection happened, the only way to get it back was to modprobe -r ath9k, modprobe ath9k and try to reconect, which usually but not always worked. With 38-5 the drop of connectivity seems to happen less often (still several times a day) and it seems to recover itself most times, with no modprobe -r required. dmesg shows this: [44312.352130] cfg80211: Calling CRDA to update world regulatory domain [44313.248381] wlan0: authenticate with my:mac:address (try 1) [44313.250236] wlan0: authenticated [44313.254280] wlan0: associate with my:mac:address (try 1) [44313.258528] wlan0: RX AssocResp from my:mac:address (capab=0x431 status=0 aid=3) [44313.258530] wlan0: associated [44341.789307] AIF:Dropped INPUT packet: IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:my:other:mac:address SRC=192.168.1.100 DST=192.168.1.255 LEN=214 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=631 DPT=631 LEN=194 [44369.424137] cfg80211: Calling CRDA to update world regulatory domain [44370.298538] wlan0: authenticate with my:mac:address (try 1) [44370.300392] wlan0: authenticated [44370.304403] wlan0: associate with my:mac:address (try 1) [44370.308617] wlan0: RX AssocResp from my:mac:address (capab=0x431 status=0 aid=3) [44370.308620] wlan0: associated [44372.825414] AIF:Dropped INPUT packet: IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:my:other:mac:address SRC=192.168.1.100 DST=192.168.1.255 LEN=214 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=631 DPT=631 LEN=194 [44375.592228] AIF:Dropped INPUT packet: IN=wlan0 OUT= MAC= SRC=192.168.1.160 DST=224.0.0.251 LEN=107 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=87 [44393.227972] AIF:Dropped INPUT packet: IN=wlan0 OUT= MAC=01:00:5e:00:00:01:my:mac:address:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2 [44403.851936] AIF:Dropped INPUT packet: IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:my:other:mac:address SRC=192.168.1.100 DST=192.168.1.255 LEN=214 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=631 DPT=631 LEN=194 [44406.412155] cfg80211: Calling CRDA to update world regulatory domain [44407.174061] ADDRCONF(NETDEV_UP): wlan0: link is not ready [44411.158926] ADDRCONF(NETDEV_UP): wlan0: link is not ready [44412.202305] ADDRCONF(NETDEV_UP): wlan0: link is not ready [44412.331082] ADDRCONF(NETDEV_UP): wlan0: link is not ready [44414.807154] wlan0: authenticate with my:mac:address (try 1) [44414.812624] wlan0: authenticated [44414.816742] wlan0: associate with my:mac:address (try 1) [44414.821100] wlan0: RX AssocResp from my:mac:address (capab=0x431 status=0 aid=3) [44414.821104] wlan0: associated [44414.824372] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [44420.591791] AIF:Dropped INPUT packet: IN=wlan0 OUT= MAC= SRC=192.168.1.160 DST=224.0.0.251 LEN=107 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=87 [44420.666170] AIF:Dropped INPUT packet: IN=wlan0 OUT= MAC= SRC=192.168.1.160 DST=224.0.0.251 LEN=463 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=443 [44420.686355] AIF:Dropped INPUT packet: IN=wlan0 OUT= MAC= SRC=192.168.1.160 DST=224.0.0.251 LEN=236 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=216 [44420.917282] AIF:Dropped INPUT packet: IN=wlan0 OUT= MAC= SRC=192.168.1.160 DST=224.0.0.251 LEN=463 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=443 [44421.167817] AIF:Dropped INPUT packet: IN=wlan0 OUT= MAC= SRC=192.168.1.160 DST=224.0.0.251 LEN=463 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=443 [44421.592844] AIF:Dropped INPUT packet: IN=wlan0 OUT= MAC= SRC=192.168.1.160 DST=224.0.0.251 LEN=107 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=87 [44423.593468] AIF:Dropped INPUT packet: IN=wlan0 OUT= MAC= SRC=192.168.1.160 DST=224.0.0.251 LEN=107 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=87 Is there any other info that could be useful? Cheers, Marcos -- 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/201105191828.46021.marcos.ca...@gmail.com
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: wpa_supplicant?
This bug may not be in ath9k but in wpa_supplicant as it has the same sympthoms as this error in ubuntu: https://bugs.launchpad.net/ubuntu/+source/wpasupplicant/+bug/548992 Cheers! -- 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/201104191703.07668.marcos.ca...@gmail.com
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
Bug#622971: China?
Does this line: 128408.330298] cfg80211: Calling CRDA for country: CN mean that it is trying to set the country to China? I am in Australia, and as far as I can tell the locale of my system is properly set. -- 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/201104161758.51823.marcos.ca...@gmail.com
