Re: [ath9k-devel] txop bursts issues
Hello. Some updates follow inline. On 05/24/2012 04:14 PM, Claudio Pisa wrote: I am working on a research project that uses the txop mechanism to distinguish, on a 802.11b/g STA, between packet losses caused by collisions and by noise. I found some issues that are not clear to me on both mac80211 and ath9k, but hopefully you can help. The first one is the motivation behind commit 133a3ff2c934223a8143bfa52401bba962a97165, cfg80211: allow setting TXQ parameters only in AP mode. Is this just a temporary fix? It looks like this is in the standard, as section 9.9.1.2 EDCA TXOPs says that The TXOP limit duration values are advertised by the AP. Sorry. To get around this, and activate the txop functionality on a STA, I am just hardcoding the burstTime (qi.tqi_burstTime = 102;) I rolled back these changes and configured the AP to advertise the txoplimit duration values. However, from our tests, the TXOP mechanism is still not working for the setup ath9k+AR5008, while it works for other setups (madwifi+AR242x). Is this a driver or just a hardware issue? Then: is the duration field set by the hardware? We are using a D-Link AR5008 NIC. It seems like the driver is always setting the duration to 0 due to (what I think is) a bug in net/mac80211/tx.c I have submitted a (1 byte) patch to fix this: http://marc.info/?l=linux-wirelessm=133820812304929w=2 thanks and regards, Claudio ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] DISABLE AMPDU AGGREGATION
Hi Shafi, I cleared the following flag in init.c: hw-flags |= IEEE80211_HW_AMPDU_AGGREGATION; and I confirm that AMPDU aggregation is disabled, as the function: static enum ATH_AGGR_STATUS ath_tx_form_aggr does not anymore print the information I have inserted in order to print the aggregation length. Moreover, I provide some Iperf UDP tests with and without AMPDU aggregation: DISABLED: [ 4] 0.0- 1.0 sec 4.36 MBytes 36.6 Mbits/sec 0.488 ms0/ 3113 (0%) [ 4] 1.0- 2.0 sec 4.72 MBytes 39.6 Mbits/sec 0.457 ms0/ 3364 (0%) [ 4] 2.0- 3.0 sec 4.26 MBytes 35.8 Mbits/sec 0.466 ms0/ 3041 (0%) [ 4] 3.0- 4.0 sec 4.50 MBytes 37.7 Mbits/sec 0.341 ms0/ 3208 (0%) [ 4] 4.0- 5.0 sec 4.78 MBytes 40.1 Mbits/sec 0.591 ms0/ 3412 (0%) ENABLED: [ 3] 0.0- 1.0 sec 13.9 MBytes 117 Mbits/sec 0.199 ms 1230/11151 (11%) [ 3] 1.0- 2.0 sec 15.2 MBytes 128 Mbits/sec 0.079 ms 1170/12037 (9.7%) [ 3] 2.0- 3.0 sec 16.8 MBytes 141 Mbits/sec 0.067 ms 1779/13730 (13%) [ 3] 3.0- 4.0 sec 15.5 MBytes 130 Mbits/sec 0.162 ms 1807/12897 (14%) [ 3] 4.0- 5.0 sec 18.3 MBytes 154 Mbits/sec 0.032 ms 993/14078 (7.1%) Thank you, Shafi. On Wed, May 30, 2012 at 8:26 AM, Mohammed Shafi shafi.wirel...@gmail.com wrote: On Wed, May 30, 2012 at 4:28 AM, Stratos Keranidis efker...@gmail.com wrote: HI, hi, I checked in the archives and found that a proper way to disable AMPDU aggregation is to replace these two lines in /drivers/net/wireless/ath/ath9k/init.c of function ath9k_init_misc() sc-sc_flags |= SC_OP_TXAGGR; sc-sc_flags |= SC_OP_RXAGGR; with the following: sc-sc_flags = ~SC_OP_TXAGGR sc-sc_flags = ~SC_OP_RXAGGR these flags were removed in the latest wireless-testing However, when I recompile and reload the modules, my PC hangs, just after associating with the AP. it could be a problem in the older stuff, where we would access aggregation related tid structures without checking those flags, did you try a somewhat newer version of compat wireless where this flags were still present ? Did anyone have some relevant problem? Is there some other proper way to disable packet aggregation? clearing the below flag in init.c will not start aggregation session 682 hw-flags |= IEEE80211_HW_AMPDU_AGGREGATION; if you got any freeze even after clearing the above flags please let me know. we may need to disable the flag ATH9K_HW_CAP_HT Thank you, Stratos. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- thanks, shafi ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] DISABLE AMPDU AGGREGATION
On Wed, May 30, 2012 at 4:13 PM, Stratos Keranidis efker...@gmail.com wrote: Hi Shafi, Hi Stratos, I cleared the following flag in init.c: hw-flags |= IEEE80211_HW_AMPDU_AGGREGATION; and I confirm that AMPDU aggregation is disabled, as the function: static enum ATH_AGGR_STATUS ath_tx_form_aggr does not anymore print the information I have inserted in order to print the aggregation length. fine! Moreover, I provide some Iperf UDP tests with and without AMPDU aggregation: DISABLED: [ 4] 0.0- 1.0 sec 4.36 MBytes 36.6 Mbits/sec 0.488 ms 0/ 3113 (0%) [ 4] 1.0- 2.0 sec 4.72 MBytes 39.6 Mbits/sec 0.457 ms 0/ 3364 (0%) [ 4] 2.0- 3.0 sec 4.26 MBytes 35.8 Mbits/sec 0.466 ms 0/ 3041 (0%) [ 4] 3.0- 4.0 sec 4.50 MBytes 37.7 Mbits/sec 0.341 ms 0/ 3208 (0%) [ 4] 4.0- 5.0 sec 4.78 MBytes 40.1 Mbits/sec 0.591 ms 0/ 3412 (0%) ENABLED: [ 3] 0.0- 1.0 sec 13.9 MBytes 117 Mbits/sec 0.199 ms 1230/11151 (11%) [ 3] 1.0- 2.0 sec 15.2 MBytes 128 Mbits/sec 0.079 ms 1170/12037 (9.7%) [ 3] 2.0- 3.0 sec 16.8 MBytes 141 Mbits/sec 0.067 ms 1779/13730 (13%) [ 3] 3.0- 4.0 sec 15.5 MBytes 130 Mbits/sec 0.162 ms 1807/12897 (14%) [ 3] 4.0- 5.0 sec 18.3 MBytes 154 Mbits/sec 0.032 ms 993/14078 (7.1%) thanks for sharing the result. its very useful! Thank you, Shafi. On Wed, May 30, 2012 at 8:26 AM, Mohammed Shafi shafi.wirel...@gmail.com wrote: On Wed, May 30, 2012 at 4:28 AM, Stratos Keranidis efker...@gmail.com wrote: HI, hi, I checked in the archives and found that a proper way to disable AMPDU aggregation is to replace these two lines in /drivers/net/wireless/ath/ath9k/init.c of function ath9k_init_misc() sc-sc_flags |= SC_OP_TXAGGR; sc-sc_flags |= SC_OP_RXAGGR; with the following: sc-sc_flags = ~SC_OP_TXAGGR sc-sc_flags = ~SC_OP_RXAGGR these flags were removed in the latest wireless-testing However, when I recompile and reload the modules, my PC hangs, just after associating with the AP. it could be a problem in the older stuff, where we would access aggregation related tid structures without checking those flags, did you try a somewhat newer version of compat wireless where this flags were still present ? Did anyone have some relevant problem? Is there some other proper way to disable packet aggregation? clearing the below flag in init.c will not start aggregation session 682 hw-flags |= IEEE80211_HW_AMPDU_AGGREGATION; if you got any freeze even after clearing the above flags please let me know. we may need to disable the flag ATH9K_HW_CAP_HT Thank you, Stratos. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- thanks, shafi -- thanks, shafi ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Spectral Scan in ath9k
Hi, It's easy to get raw FFT data from the card, but then some cryptoanalytic work should be done in MathLab. Actualy I'm busy (lazy) man... will wait for open information which Adrian promised. :) I beleave the open source community can implement these features better than MicroTik did it. Best regards, Alex. On Sat, Mar 24, 2012 at 03:53:40PM -0700, Adrian Chadd wrote: On 24 March 2012 08:50, Saulo Queiroz ssaulojo...@gmail.com wrote: Hello, I intend to use ath9k to perform some tests on demodulated FFT samples. I found out the definition #define AR_PHY_SPECTRAL_SCAN 0x9910 /* AR9280 spectral scan configuration register but since I am a beginner in the ath9k, I have no idea about using it to achieve my goal. I really would be very grateful if some can provide me with informations that help me to access such data in the code. Hi, People keep asking about spectral scan, bah. :-) There are some plans afoot to try and get this stuff opened and documented. Like anything, it's more complicated than just provide register details, as it's not as easy as just flipping on some bits and getting FFT samples. Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] help!!!!!!!!!!
Hello Sir, I have some more question. Actually I used ubuntu operating system with kernel version 2.6.38-13-generic-pae which it self has default ath9k driver. But I also used compact-wireless-2.6.38.2-2-ns ,n when I wanted to work with compact wireless ath9k driver, I used following step 1]To disable default ath9k driver of ubuntu I used rmmod ath9k 2]Then go inside compact wireless n say modprobe ath9k..but m not sure whether it's proper way or not. So I want to know how to disable default ath9k driver in kernel in order to used ath9k driver from compact wireless package Sir I m using Atheros* *AR9380 [TP-LINK tl-wdn-4800] chip set.With this chipset I used hostapd version 0.7.3. With this setting I m able to achieve throughput ranges from 230-250Mbps for udp traffic[iperf is generation tool] . But I m not able to set various HT capabilities introduced by 802.11n standard Like I want to measure throughput for various size of A-MPDU, various MCS index. I am follow your suggestion for MPDU n MCS issues as you send me in previous mail. Thank you Regards, Yashashree On Tue, May 29, 2012 at 10:35 AM, Yashashree Jadhav yashashreejadha...@gmail.com wrote: Hello Sir, Thank you very much for your guidance and quick reply. I will try to follow your suggestion. Thank you Regards, Yashashree On Mon, May 28, 2012 at 11:24 PM, shashank ks shashank...@gmail.comwrote: On Mon, May 28, 2012 at 2:14 AM, Yashashree Jadhav yashashreejadha...@gmail.com wrote: Hello Sir/Madam, Hi This is Yashashree. I wanted to know which rate adaptation mechanism used by ath9k driver. By default ath9k uses ath9k_rate_control algorithm How to set various rate adaptation mechanism in 802.11n. The other available rc is minstrel_ht. Look in config.mk to use minstrel_ht. You can enable ath9k rate contorl in the .config CONFIG_ATH9K_RATE_CONTROL=y and to enable/disbale change the folowing default things CONFIG_MAC80211_HAS_RC=y CONFIG_MAC80211_RC_MINSTREL=y CONFIG_MAC80211_RC_MINSTREL_HT=y CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y CONFIG_MAC80211_RC_DEFAULT=minstrel_ht Please search in mail list archive for more information. I can able to set A-MSDU with hostapd ,but how to set various MCS and A-MPDU for 802.11n. As far as my understanding A-MSDU tx is not supported by ath9k. For setting MCS you have to patch the driver. Refer http://thread.gmane.org/gmane.linux.drivers.ath9k.devel/8373/focus=8392 Thank you Regards, Yashashree ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Throughput
Hi, We are working on Wi-Fi device in STA mode and find that the uplink throughput is very poor. Whereas when the same device is configured in AP mode its throughput performance is as expected. The application is based on AR93xx platform and drivers are from version U10_1020. Any help for the same will be highly appreciated. Regards, Sunil. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] help!!!!!!!!!!
Hello Sir, Re: [ath9k-devel] Low Throughput while Using minstrel_ht fixed-rate Solu:-attached Rajkumar's fixed MCS patch Where to find this patch sir.Is it available for users.If you can provide this path it's one of the big help for me. As per your suggestion I disable the ath9k_rate_control and enable minstrel_ht in config.mk and measure the throughput ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Throughput
On Wed, May 30, 2012 at 6:41 PM, Sunil Mehta sun...@telenetsystems.com wrote: Hi, hi, We are working on Wi-Fi device in STA mode and find that the uplink throughput is very poor. Whereas when the same device is configured in AP mode its throughput performance is as expected. The application is based on AR93xx platform and drivers are from version U10_1020. which chipset you are using. please upgrade http://linuxwireless.org/en/users/Download#Where_to_download_bleeding_edge Any help for the same will be highly appreciated. Regards, Sunil. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- thanks, shafi ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Throughput
Hi, Chipset is AR9331. Thanks for the link. Shall try the same. On 5/30/12 6:57 PM, Mohammed Shafi shafi.wirel...@gmail.com wrote: On Wed, May 30, 2012 at 6:41 PM, Sunil Mehta sun...@telenetsystems.com wrote: Hi, hi, We are working on Wi-Fi device in STA mode and find that the uplink throughput is very poor. Whereas when the same device is configured in AP mode its throughput performance is as expected. The application is based on AR93xx platform and drivers are from version U10_1020. which chipset you are using. please upgrade http://linuxwireless.org/en/users/Download#Where_to_download_bleeding_edge Any help for the same will be highly appreciated. Regards, Sunil. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- thanks, shafi ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [RFC] ath9k: Fix softlockup in AR9485
From: Mohammed Shafi Shajakhan moham...@qca.qualcomm.com
steps to recreate:
load latest ath9k driver with AR9485
stop the network-manager and wpa_supplicant
bring the interface up
Call Trace:
[a0517490] ? ath_hw_check+0xe0/0xe0 [ath9k]
[812cd1e8] __const_udelay+0x28/0x30
[a03bae7a] ar9003_get_pll_sqsum_dvc+0x4a/0x80 [ath9k_hw]
[a05174eb] ath_hw_pll_work+0x5b/0xe0 [ath9k]
[810744fe] process_one_work+0x11e/0x470
[8107530f] worker_thread+0x15f/0x360
[810751b0] ? manage_workers+0x230/0x230
[81079af3] kthread+0x93/0xa0
[815fd3a4] kernel_thread_helper+0x4/0x10
[81079a60] ? kthread_freezable_should_stop+0x70/0x70
[815fd3a0] ? gs_change+0x13/0x13
before the STA is associated PLL4(0x1618c) always seem to dump
zero, which causes a softlockup as we keep on polling infinitely
PLL4's 8th bit. Once PLL4'S 8th bit is set indicates we can take
PLL3(0x16188) readings which tells us whether PLL is locked or not.
if the PLL is not locked we have a rx hang.
It does not looks safe to poll PLL4 before the STA is associated.
so it is safe to check this rx hang after association, where we might
have a possibility of rx hang under stress testing. digging into the
PLL stuff did not yield anything much better.
previously the register dumped 0xdeadbeef and the hw_pll_work
itself is cancelled by ath_radio_disable(obselete)
fixes https://bugzilla.redhat.com/show_bug.cgi?id=811142
Reported-by: Rolf Offermanns rolf.offerma...@gmx.net
Cc: sta...@vger.kernel.org
Signed-off-by: Mohammed Shafi Shajakhan moham...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/main.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c
b/drivers/net/wireless/ath/ath9k/main.c
index dfa78e8..a03ad3e 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -970,6 +970,9 @@ void ath_hw_pll_work(struct work_struct *work)
hw_pll_work.work);
u32 pll_sqsum;
+ if (!(sc-sc_flags SC_OP_PRIM_STA_VIF))
+ return;
+
if (AR_SREV_9485(sc-sc_ah)) {
ath9k_ps_wakeup(sc);
--
1.7.0.4
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Proposed 3x3 Dual band chipsets
Hello, I am about to order some new cards for testing capabilities of ath9k. Currently I have cards with the AR5008, AR5418 chipset, which does not support 3x3 MIMO. I looked in the list of ath9k-supported chipsets to find cards that support 3x3 MIMO and I have concluded in the following options: AR5008: AR5418+AR5133 (= 2.6.27) AR5418 = DB 11n PCIe, AR5133 = 3x3 DB 11n AR5416+AR2133 (= 2.6.27) AR2133 = 3x3 SB 11n AR9001: AR9103 (= 2.6.30, AHB) 3x3 SB 11n AR9003: AR9380 (= 2.6.36) 3x3 DB 11n PCIe My AR5418 card supports Dual Band operation, but I am not able to set 5GHz channels in my regulatory domain (GR). As I am interested in buying Dual-band compatible chipsets only, my options are limited between the AR5008:AR5133 and the AR9003:AR9380 chipsets. Can you propose any of these, or any other chipset that might fit my needs? Thank you in advance, Stratos. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Proposed 3x3 Dual band chipsets
On 05/30/2012 10:57 AM, Stratos Keranidis wrote: Hello, I am about to order some new cards for testing capabilities of ath9k. Currently I have cards with the AR5008, AR5418 chipset, which does not support 3x3 MIMO. I looked in the list of ath9k-supported chipsets to find cards that support 3x3 MIMO and I have concluded in the following options: AR5008: AR5418+AR5133 (= 2.6.27) AR5418 = DB 11n PCIe, AR5133 = 3x3 DB 11n AR5416+AR2133 (= 2.6.27) AR2133 = 3x3 SB 11n AR9001: AR9103 (= 2.6.30, AHB) 3x3 SB 11n AR9003: AR9380 (= 2.6.36) 3x3 DB 11n PCIe My AR5418 card supports Dual Band operation, but I am not able to set 5GHz channels in my regulatory domain (GR). As I am interested in buying Dual-band compatible chipsets only, my options are limited between the AR5008:AR5133 and the AR9003:AR9380 chipsets. I've had good luck with the AR9380. Specifically, I'm using WPEA-127N NICs currently. I just ordered some AR9390 NICs for testing, but no idea how they will turn out. Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC] ath9k: Fix softlockup in AR9485
(Yes, this is a public response.) Hi, That has me a bit concerned. Waiting for the STA to be associated is really just some kind of settling delay. You're still TX/RXing at that point. I think we need to speak to the baseband/clock teams and figure out why this is actually occuring. Can we please leave this out of the tree (but in the bug report) until this gets root caused internally? Thanks, adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Proposed 3x3 Dual band chipsets
On May 30, 2012, at 10:57 AM, Stratos Keranidis wrote: Hello, I am about to order some new cards for testing capabilities of ath9k. Currently I have cards with the AR5008, AR5418 chipset, which does not support 3x3 MIMO. I looked in the list of ath9k-supported chipsets to find cards that support 3x3 MIMO and I have concluded in the following options: AR5008: AR5418+AR5133 (= 2.6.27) AR5418 = DB 11n PCIe, AR5133 = 3x3 DB 11n AR5416+AR2133 (= 2.6.27) AR2133 = 3x3 SB 11n AR9001: AR9103 (= 2.6.30, AHB) 3x3 SB 11n AR9003: AR9380 (= 2.6.36) 3x3 DB 11n PCIe My AR5418 card supports Dual Band operation, but I am not able to set 5GHz channels in my regulatory domain (GR). As I am interested in buying Dual-band compatible chipsets only, my options are limited between the AR5008:AR5133 and the AR9003:AR9380 chipsets. Can you propose any of these, or any other chipset that might fit my needs? Thank you in advance, Stratos This may be helpful reading: http://en.wikipedia.org/wiki/802.11n#Number_of_antennas You want to go with a AR9003, probably AR9380. It supports true 3x3:3 configurations. This means it has the ability to transmit on 3 antennas at once, or receive on 3 antennas at once. It can also handle 3 spatial streams, meaning you can get up to 450 megabits per second with 40 MHz channels. It also features superior DSP to better process the MIMO signals and beamforming to aim the signal. The AR9001 family of chipsets are much more limited. They cannot handle 3 spatial streams, so you cannot get more than 300 megabits. I am not sure about the 3x3 capabilities on the AR9103 but I know they are much inferior to the AR9003 family. I am not even sure if they are really processing the signal with DSP or if they are just switching between antennas intelligently. In any case, the AR9003 has immense improvements on every front as compared to AR9001. The AR5008 family is best avoided if you are buying a new card. I believe they do not consider this card fully supported in ath9k. It does work. I think there may still be some bugs left. I believe the 3x3 is really just 2 transmitting that switches between antennas intelligently. As for the AR9380, it is a single-chip solution. Amplifier, everything on a single chip. As a result, there will be vastly less variation from brand to brand. I would just look for a cheap one on eBay. They are $30 on eBay. The SparkLAN products are also solid, but may be more expensive. I have not evaluated sufficiently to see if there is any benefit. As for the regulatory stuff - search the list and also check with OpenWRT. There are many ways to make the radio function on whatever channel you wish. -Galen ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Anyone doing WiFi throughput tests?
Ben Greear wrote: We started testing with two AR9380 NICs today (one AP, the other STA). I applied Felix's skb optimization patch, and the ath9k memleak fix patch on top of 3.3.7+. When we generate traffic using a modified version of pktgen, the STA interface transmits at around 310Mbps for a minute or two, but then the system dies of OOM (and maybe worse..having trouble getting useful serial console log). It died much faster before Felix's two patches were applied. I disabled all of our network related buffer adjustments (ie, no longer increasing tcp_wmem, etc), and it still crashes. The system has 2GB RAM, but it is 32-bit kernel, so not all is available to the networking code... That said, the OOM killer kills VNC and such. Anyway, I'll try some memleak debugging to see if I can find any leaks. It seems to me that we should not actually OOM just by trying to transmit too fast on a station interface :P In my setup, UDP RX (AP-STA) locks up the station hard and eventually I get this: [ 292.093359] BUG: soft lockup - CPU#0 stuck for 23s! [syslog-ng:403] [ 292.093555] irq event stamp: 12065793 [ 292.093560] hardirqs last enabled at (12065792): [81490855] _raw_spin_unlock_irqrestore+0x65/0x80 [ 292.093579] hardirqs last disabled at (12065793): [814922ea] apic_timer_interrupt+0x6a/0x80 [ 292.093591] softirqs last enabled at (4271834): [81059507] __do_softirq+0x137/0x240 [ 292.093605] softirqs last disabled at (4273355): [81492cec] call_softirq+0x1c/0x30 [ 292.093617] CPU 0 [ 292.093826] Pid: 403, comm: syslog-ng Tainted: G O 3.4.0-wl #21 LENOVO 7661GN4/7661GN4 [ 292.093841] RIP: 0010:[8149085a] [8149085a] _raw_spin_unlock_irqrestore+0x6a/0x80 [ 292.093855] RSP: 0018:88007d403c90 EFLAGS: 0282 [ 292.093862] RAX: 880037526dd0 RBX: RCX: 0002 [ 292.093869] RDX: 0002 RSI: 880037527428 RDI: 0282 [ 292.093876] RBP: 88007d403ca0 R08: 8800755f5048 R09: 0005 [ 292.093883] R10: R11: R12: 88007d403c08 [ 292.093889] R13: 814922ef R14: 88007d403ca0 R15: 81a65c80 [ 292.093897] FS: 7f6c0dc5db00() GS:88007d40() knlGS: [ 292.093905] CS: 0010 DS: ES: CR0: 80050033 [ 292.093911] CR2: 7f35a1fbe1c3 CR3: 7549 CR4: 07f0 [ 292.093918] DR0: DR1: DR2: [ 292.093925] DR3: DR6: 0ff0 DR7: 0400 [ 292.093933] Process syslog-ng (pid: 403, threadinfo 8800789de000, task 880037526dd0) [ 292.093939] Stack: [ 292.093943] 8800755f5000 0282 88007d403cc0 81270aa2 [ 292.093960] 07b6 0040 88007d403d10 812720fe [ 292.093975] 0100 88007d403d10 880075155700 [ 292.093990] Call Trace: [ 292.093995] IRQ [ 292.094006] [81270aa2] dma_entry_alloc+0x62/0x90 [ 292.094017] [812720fe] debug_dma_map_page+0x7e/0x140 [ 292.094037] [a06b3669] ath_rx_tasklet+0x969/0x1f10 [ath9k] [ 292.094056] [a06b0054] ath9k_tasklet+0x104/0x180 [ath9k] [ 292.094068] [8105a073] tasklet_action+0x83/0x110 [ 292.094079] [81059498] __do_softirq+0xc8/0x240 [ 292.094091] [81492cec] call_softirq+0x1c/0x30 [ 292.094102] [81016855] do_softirq+0xa5/0xe0 [ 292.094113] [81059986] irq_exit+0xa6/0xe0 [ 292.094124] [81493583] do_IRQ+0x63/0xe0 [ 292.094134] [81490cef] common_interrupt+0x6f/0x6f [ 292.094140] EOI [ 292.094150] [810aeafc] ? mark_held_locks+0x8c/0x110 [ 292.094162] [8149085a] ? _raw_spin_unlock_irqrestore+0x6a/0x80 [ 292.094173] [8107fd23] __wake_up+0x53/0x70 [ 292.094196] [a022af3c] jbd2_journal_stop+0x24c/0x2c0 [jbd2] [ 292.094246] [a0275788] __ext4_journal_stop+0x78/0xa0 [ext4] [ 292.094278] [a025a5ad] ext4_da_write_end+0xad/0x390 [ext4] [ 292.094293] [81116d03] generic_file_buffered_write+0x1a3/0x2c0 [ 292.094309] [8148dba7] ? mutex_lock_nested+0x2f7/0x3d0 [ 292.094321] [81118c4a] __generic_file_aio_write+0x22a/0x440 [ 292.094334] [81118ed3] generic_file_aio_write+0x73/0xe0 [ 292.094363] [a025136f] ext4_file_write+0xaf/0x270 [ext4] [ 292.094374] [810adcf0] ? lock_release_non_nested+0xa0/0x2e0 [ 292.094403] [a02512c0] ? ext4_file_mmap+0x60/0x60 [ext4] [ 292.094415] [8117c472] do_sync_readv_writev+0xd2/0x110 [ 292.094427] [8113bd23] ? might_fault+0x53/0xb0 [ 292.094438] [8120aa0c] ? security_file_permission+0x2c/0xb0 [ 292.094449] [8117bb91] ? rw_verify_area+0x61/0xf0 [ 292.094460] [8117c75b] do_readv_writev+0xdb/0x1f0 [ 292.094470]
[ath9k-devel] [RFC] ath9k: Fix softlockup in AR9485
Mohammed Shafi Shajakhan wrote:
before the STA is associated PLL4(0x1618c) always seem to dump
zero, which causes a softlockup as we keep on polling infinitely
PLL4's 8th bit. Once PLL4'S 8th bit is set indicates we can take
PLL3(0x16188) readings which tells us whether PLL is locked or not.
if the PLL is not locked we have a rx hang.
It does not looks safe to poll PLL4 before the STA is associated.
so it is safe to check this rx hang after association, where we might
have a possibility of rx hang under stress testing. digging into the
PLL stuff did not yield anything much better.
previously the register dumped 0xdeadbeef and the hw_pll_work
itself is cancelled by ath_radio_disable(obselete)
fixes https://bugzilla.redhat.com/show_bug.cgi?id=811142
Reported-by: Rolf Offermanns rolf.offerma...@gmx.net
Cc: sta...@vger.kernel.org
Signed-off-by: Mohammed Shafi Shajakhan moham...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/main.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c
b/drivers/net/wireless/ath/ath9k/main.c
index dfa78e8..a03ad3e 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -970,6 +970,9 @@ void ath_hw_pll_work(struct work_struct *work)
hw_pll_work.work);
u32 pll_sqsum;
+ if (!(sc-sc_flags SC_OP_PRIM_STA_VIF))
+ return;
+
if (AR_SREV_9485(sc-sc_ah)) {
ath9k_ps_wakeup(sc);
All this is really racy, I think. In the various callsites where we issue a HW
reset by queuing a work, there is no guarantee that the caller would not be
invoked once again before the reset work has had a chance to kick in. And there
is
nothing that prevents the various poll routines from checking the HW while a
reset in progress.
And why are we using HZ for the pll_work ?
Sujith
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Ath9k performance testing results (AR9380)
Ben Greear wrote: I am not sure why there is such a big difference, but possibly sending wifi is harder than receiving it, and the Atom processor just can't keep up. I have a small Atom-based netbook, I'll try with it and see what numbers can be seen. It's a pain to pry it open and bolt a different card, though. :) Sujith ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC] ath9k: Fix softlockup in AR9485
Hi Adrian, On Thursday 31 May 2012 12:18 AM, Adrian Chadd wrote: (Yes, this is a public response.) Hi, That has me a bit concerned. Waiting for the STA to be associated is really just some kind of settling delay. You're still TX/RXing at that point. yeah, but i am pretty sure in the STA mode we have this PLL registers having sane values once the STA is associated. i checked if i am missing hardware code/init_pll routine or if its actually overwritten by INI values, but no. i also checked this issue with IBSS and monitor mode even under shield room, still it did not show much improvements or more clue. I think we need to speak to the baseband/clock teams and figure out why this is actually occuring. oh yes and i had been already sending some mails internally, checking with people who might have good knowledge about this. Can we please leave this out of the tree (but in the bug report) until this gets root caused internally? one thing i observed was this rx hang detection is based on the 'delta of rx unicast packets' for a particular time. if its lesser than 5 this rx hang detection kicks off. another system expert told me this rx hang itself can be specific to AP rather than STA. finally i would check with one system expert and another Engineer to get some thoughts, then send it as a PATCH. Thanks, adrian -- thanks, shafi ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Ath9k performance testing results (AR9380)
On 05/30/2012 07:48 PM, Sujith Manoharan wrote: Ben Greear wrote: I am not sure why there is such a big difference, but possibly sending wifi is harder than receiving it, and the Atom processor just can't keep up. I have a small Atom-based netbook, I'll try with it and see what numbers can be seen. It's a pain to pry it open and bolt a different card, though. :) We had to install a hacked 'white-listed' BIOS to get a Lenovo laptop to even POST with an Atheros NIC in it, so if your NIC works w/out having to hack the BIOS, please let me know :) Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC] ath9k: Fix softlockup in AR9485
Hi Sujith,
On Thursday 31 May 2012 08:14 AM, Sujith Manoharan wrote:
Mohammed Shafi Shajakhan wrote:
before the STA is associated PLL4(0x1618c) always seem to dump
zero, which causes a softlockup as we keep on polling infinitely
PLL4's 8th bit. Once PLL4'S 8th bit is set indicates we can take
PLL3(0x16188) readings which tells us whether PLL is locked or not.
if the PLL is not locked we have a rx hang.
It does not looks safe to poll PLL4 before the STA is associated.
so it is safe to check this rx hang after association, where we might
have a possibility of rx hang under stress testing. digging into the
PLL stuff did not yield anything much better.
previously the register dumped 0xdeadbeef and the hw_pll_work
itself is cancelled by ath_radio_disable(obselete)
fixes https://bugzilla.redhat.com/show_bug.cgi?id=811142
Reported-by: Rolf Offermannsrolf.offerma...@gmx.net
Cc: sta...@vger.kernel.org
Signed-off-by: Mohammed Shafi Shajakhanmoham...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/main.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c
b/drivers/net/wireless/ath/ath9k/main.c
index dfa78e8..a03ad3e 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -970,6 +970,9 @@ void ath_hw_pll_work(struct work_struct *work)
hw_pll_work.work);
u32 pll_sqsum;
+if (!(sc-sc_flags SC_OP_PRIM_STA_VIF))
+return;
+
if (AR_SREV_9485(sc-sc_ah)) {
ath9k_ps_wakeup(sc);
All this is really racy, I think. In the various callsites where we issue a HW
reset by queuing a work, there is no guarantee that the caller would not be
invoked once again before the reset work has had a chance to kick in. And
there is
nothing that prevents the various poll routines from checking the HW while a
reset in progress.
should we check if (work_pending(sc-hw_reset_work)) like we do in
ath_beacon_tasklet in all the other work routine that access hardware
registers in case the hw_reset_work is not cancelled(possible in
ath_set_channel)
And why are we using HZ for the pll_work ?
don't know, i put a printk to see the routine seems to get executed for
every 200ms(HZ/5). scan work in mac80211 seems to use HZ
ieee80211_queue_delayed_work(local-hw, local-scan_work, next_delay);
Sujith
--
thanks,
shafi
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC] ath9k: Fix softlockup in AR9485
Mohammed Shafi Shajakhan wrote: should we check if (work_pending(sc-hw_reset_work)) like we do in ath_beacon_tasklet in all the other work routine that access hardware registers in case the hw_reset_work is not cancelled(possible in ath_set_channel) Probably, but this needs to be done in a clean manner. don't know, i put a printk to see the routine seems to get executed for every 200ms(HZ/5). scan work in mac80211 seems to use HZ ieee80211_queue_delayed_work(local-hw, local-scan_work, next_delay); HZ can be configured to a user-defined value, so we need to make sure that the timing for the PLL work is what we want. Sujith ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC] ath9k: Fix softlockup in AR9485
On Thursday 31 May 2012 11:11 AM, Sujith Manoharan wrote: Mohammed Shafi Shajakhan wrote: should we check if (work_pending(sc-hw_reset_work)) like we do in ath_beacon_tasklet in all the other work routine that access hardware registers in case the hw_reset_work is not cancelled(possible in ath_set_channel) Probably, but this needs to be done in a clean manner. ok. don't know, i put a printk to see the routine seems to get executed for every 200ms(HZ/5). scan work in mac80211 seems to use HZ ieee80211_queue_delayed_work(local-hw,local-scan_work, next_delay); HZ can be configured to a user-defined value, so we need to make sure that the timing for the PLL work is what we want. ok, then we will change it. Sujith -- thanks, shafi ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
