[ath9k-devel] Probable incorrect constant in ath9k

2013-02-21 Thread Blaise Gassend
Hi, While reviewing the ath9k source, I came across the following line which is probably wrong: #define ATH_RSSI_DUMMY_MARKER 0x127 Given that RSSI is stored in a byte, I suspect that this constant was supposed to be 127 or 0x7F, rather than 0x127. I am unfortunately not set up to easily

Re: [ath9k-devel] Probable incorrect constant in ath9k

2013-02-21 Thread Blaise Gassend
Actually, given that -128 is returned for antennas that are not present, I wonder if -128 is the correct value here. But this is just guesswork. On Wed, Feb 20, 2013 at 11:19 PM, Blaise Gassend bla...@suitabletech.comwrote: Hi, While reviewing the ath9k source, I came across the following

Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

2013-02-21 Thread Adrian Chadd
Hm, that's quite a CC, for people who are mostly on the list :-) How's the vap setup look? Are you running two hostapds, one on each vap of a single card? Or is it two hostaps, each one to a separate vap on a separate NIC? Adrian ___ ath9k-devel

Re: [ath9k-devel] Probable incorrect constant in ath9k

2013-02-21 Thread Adrian Chadd
Yes, that's wrong. ;) Adrian On 20 February 2013 23:19, Blaise Gassend bla...@suitabletech.com wrote: Hi, While reviewing the ath9k source, I came across the following line which is probably wrong: #define ATH_RSSI_DUMMY_MARKER 0x127 Given that RSSI is stored in a byte, I suspect

Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

2013-02-21 Thread Felix Liao
the vap setup as following, I should add these into reproduce.sh. phy phy0 interface add ath1 type __ap iwconfig ath1 power off phy phy0 interface add ath2 type __ap iwconfig ath2 power off yes, I was running two hostapds, one on each vap of a single phy. -Original Message- From:

Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

2013-02-21 Thread Felix Liao
indeed, in order to set vap power off, I just create a station vap and set power off then change its type to AP. diff --git a/reproduce.sh b/reproduce.sh index 7f7ce2a..05a6410 --- a/reproduce.sh +++ b/reproduce.sh @@ -14,6 +14,17 @@ brctl addif eth1-bridge eth1 brctl addif eth2-bridge eth2

[ath9k-devel] [RFC] ath9k: Detect and work-around tx-queue hang.

2013-02-21 Thread greearb
From: Ben Greear gree...@candelatech.com We see TX lockups on ar9380 NICs when running 32 stations each with a 56kbps stream of MTU sized UDP packets. We see lockups on the AP and also on the station, seems random which hits first. The test case further involves a programmable attenuator, and

Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

2013-02-21 Thread Felix Liao
I also test the following patches, but they can't resolve my problem. [46/93] ath9k_hw: fix chain swap setting when setting rx chainmask to 5 http://patchwork.ozlabs.org/patch/218409/ [45/93] ath9k_hw: fix calibration issues on chainmask that don't include chain 0

Re: [ath9k-devel] [RFC] ath9k: Detect and work-around tx-queue hang.

2013-02-21 Thread Ben Greear
On 02/21/2013 08:28 PM, Sujith Manoharan wrote: Hi, This is definitely a work-around. :) I think we should debug a bit more to find out the actual bug rather than add more hacks to the already hackish TX poll routine. I'll be happy to test patches, but I'm not sure how to go about debugging

Re: [ath9k-devel] [RFC] ath9k: Detect and work-around tx-queue hang.

2013-02-21 Thread Sujith Manoharan
Ben Greear wrote: I'll be happy to test patches, but I'm not sure how to go about debugging the real problem on my own. Maybe some stats could be added to the xmit debugfs file to help diagnose the problem, or maybe some other debugfs info will help? I can't reproduce the problem with

Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

2013-02-21 Thread Adrian Chadd
And it doesn't happen with the same vap setup if you have one hostapd controlling both? Adrian On 21 February 2013 17:19, Felix Liao felix.l...@watchguard.com wrote: the vap setup as following, I should add these into reproduce.sh. phy phy0 interface add ath1 type __ap iwconfig ath1 power

Re: [ath9k-devel] [RFC] ath9k: Detect and work-around tx-queue hang.

2013-02-21 Thread Ben Greear
On 02/21/2013 08:49 PM, Sujith Manoharan wrote: Ben Greear wrote: I'll be happy to test patches, but I'm not sure how to go about debugging the real problem on my own. Maybe some stats could be added to the xmit debugfs file to help diagnose the problem, or maybe some other debugfs info will

Re: [ath9k-devel] [RFC] ath9k: Detect and work-around tx-queue hang.

2013-02-21 Thread Sujith Manoharan
Hi, This is definitely a work-around. :) I think we should debug a bit more to find out the actual bug rather than add more hacks to the already hackish TX poll routine. Sujith gree...@candelatech.com wrote: From: Ben Greear gree...@candelatech.com We see TX lockups on ar9380 NICs when

[ath9k-devel] Please help; WLAN and BT Co-existence

2013-02-21 Thread sandeep suresh
Good morning dear experts,   As I am new to the group , need your help in addressing the following questions, Please. Please help on this: 1. The basic question I had was, is it possible say every 500ms, I can allocate the media for WLAN for 300ms and for BT for 200ms? How can we do

Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

2013-02-21 Thread Felix Liao
I just test this case about 4 hours, using one hostapd to driver these two APs, that is, - hostapd hostapd1.conf -t -d -K 1 hostapd1.log - hostapd hostapd2.conf -t -d -K 1 hostapd2.log + hostapd hostapd1.conf hostapd2.conf -t -d -K 1 hostapd.log seems works well so far.

Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

2013-02-21 Thread Adrian Chadd
Ok, that's a good debugging point. It means there's only one concurrent sending path. Are you using a multi-core board? Can you try booting it single core and see if it still behaves this way? Adrian On 21 February 2013 22:43, Felix Liao felix.l...@watchguard.com wrote: I just test this

Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

2013-02-21 Thread Felix Liao
The CPU is only one core in my board. -Original Message- From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On Behalf Of Adrian Chadd Sent: Friday, February 22, 2013 3:19 PM To: Felix Liao Cc: ath9k-devel@lists.ath9k.org; lindner_ma...@yahoo.de; Joe Qiao; Hao Wang; Bryan