date:20131213

Re: [ath9k-devel] [Cerowrt-devel] Wireless failures 3.10.17-3

2013-12-13 Thread Sujith Manoharan

Dave Taht wrote:
> OK, I couldn't help myself but boot up that release. Wet paint! It
> successfully brought up
> the 5ghz radio, but did not manage to assign an ip address to it
> (netifd bug?) and failed on the 2ghz radio utterly.
> 
> trying to restart it manually fails to bring up the 5ghz radio as well.
> Here's an strace of that.
> 
> http://snapon.lab.bufferbloat.net/~d/hostapd.strace.txt
> 
> I don't see it beacon, either.
> 
> Now, I don't have a grip on what started happening two releases back
> (I was out of town) but I figure it is perhaps more relevant than
> chasing the DMA tx thing. And ENOTIME for me on this til sunday. I
> will revert this patch and bisect backwards.

I am not sure how the patch would break things.

Booting OpenWrt trunk (with the patch) on an AP96 reference board seems
to work fine: http://pastebin.com/3rPSfuad

Sujith
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [Cerowrt-devel] Wireless failures 3.10.17-3

2013-12-13 Thread Dave Taht

OK, I couldn't help myself but boot up that release. Wet paint! It
successfully brought up
the 5ghz radio, but did not manage to assign an ip address to it
(netifd bug?) and failed on the 2ghz radio utterly.

trying to restart it manually fails to bring up the 5ghz radio as well.
Here's an strace of that.

http://snapon.lab.bufferbloat.net/~d/hostapd.strace.txt

I don't see it beacon, either.

Now, I don't have a grip on what started happening two releases back
(I was out of town) but I figure it is perhaps more relevant than
chasing the DMA tx thing. And ENOTIME for me on this til sunday. I
will revert this patch and bisect backwards.

root@CMTS:~# wifi enable
command failed: Device or resource busy (-16)
Configuration file: /var/run/hostapd-phy0.conf
nl80211: Could not configure driver mode
nl80211 driver initialization failed.
hostapd_free_hapd_data: Interface gw00 wasn't started
hostapd_free_hapd_data: Interface gw00 wasn't started
hostapd_free_hapd_data: Interface sw00 wasn't started
Failed to start hostapd for phy0
command failed: Too many open files in system (-23)
command failed: Too many open files in system (-23)
ifconfig: SIOCSIFHWADDR: Device or resource busy
command failed: Device or resource busy (-16)
Configuration file: /var/run/hostapd-phy1.conf
nl80211: Could not configure driver mode
nl80211 driver initialization failed.
hostapd_free_hapd_data: Interface gw10 wasn't started
hostapd_free_hapd_data: Interface sw10 wasn't started
Failed to start hostapd for phy1
netifd: Interface 'sw10' is enabled



On Fri, Dec 13, 2013 at 12:56 PM, Dave Taht  wrote:
> On Fri, Dec 13, 2013 at 1:27 AM, Sujith Manoharan  wrote:
>> Sebastian Moeller wrote:
>>> It is a net gear WNDR3700 v2, so according to:
>>> http://wiki.openwrt.org/toh/netgear/wndr3700 it is a Atheros AR7161 rev 2 
>>> 680
>>> MHz soc with the following wireless parts: Atheros AR9223 802.11bgn / 
>>> Atheros
>>> AR9220 802.11an.
>>>
>>> Sure, I hope I got the right one. Now this is not from the same boot as the
>>> one with the errors, but I assume that does not make a difference… Since I 
>>> am
>>> located in Germany I set the regulatory domain to DE. please let me know if 
>>> I
>>> you need any additional information or testing (note I am not set up to 
>>> build
>>> cerowrt myself, so I would need Dave Täht's help to build a modified 
>>> firmware)
>
> THANK YOU!
>
> I have applied the patch to the next build of cerowrt-3.10.24-1 for
> the wndr3700v2 and 3800 which will be here when the build completes:
>
> http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.24-1
>
> 100% completely untested by me til sunday! Don't try this on your
> default home router.
>
> While I'm here on linux-wireless:
>
> Cerowrt really needs a new maintainer and more people able to build
> it. I am generally working on some queuing theory (in wireless/wifi)
> right now, fixing a new chipset in a new box that I can't talk about
> (yet), and low on free time, and working on standardizing fq_codel in
> the ietf is eating what little spare time I have left.
>
> Although dedicating my sundays to Cero, I'm losing the general purpose
> skill set required to keep the continuous integration phase from
> openwrt to cero on the wndr3800 going. I care about keeping cero
> going, but after 3 years of building it and after struggling to make
> it stable since august, I'm feeling washed up and burned out on it. I
> think we are very close to a stable release, though, and I'll feel
> much better about things after this bug is gone…
>
> But while I'm limping along...
>
> Any volunteers to help get the next release after this one out? Any
> suggestions for doing it mo better? Or a better strategy for testing
> more fixes for bufferbloat?
>
> There MIGHT be some funding for Cero next year. There never has been
> before, and there have been too many broken promises, sooo the only
> true reward I know of for working on bufferbloat with cerowrt (and it
> is major!) is doing bleeding edge research on the Internet's most
> nagging problems…. and *solving them*.
>
> OK, then there's also the user base, which is wonderful. And the
> notoriety. And kicking the vendors and ISPs making crappy routers in
> the shins on a regular basis. Etc.
>
> I'd like to add a next-generation bleeding edge chip to the effort but
> can't without more funding and more volunteers.
>
>> Can you try this patch ?
>
> I have folded this into cerowrt-3.10.24-1. Note that in addition to
> this problem the last couple builds have been testing dnsmasq 2.68
> which may have also broke at the same time, and I am far from the
> yurtlab right now so I am unable to test before sunday. (use fixed ip
> addrs if it's still busted)
>
> :Crossed fingers:
>
> I note that I don't know if there is a cause or effect relationship in
> the DMA tx bug to what we are actually seeing, with radios falling off
> the net. I have a similar long-standing bug with babel doing ipv6
> ad-hoc mode multicasts and receives and seeing othe

Re: [ath9k-devel] [Cerowrt-devel] Wireless failures 3.10.17-3

2013-12-13 Thread Dave Taht

On Fri, Dec 13, 2013 at 1:27 AM, Sujith Manoharan  wrote:
> Sebastian Moeller wrote:
>> It is a net gear WNDR3700 v2, so according to:
>> http://wiki.openwrt.org/toh/netgear/wndr3700 it is a Atheros AR7161 rev 2 680
>> MHz soc with the following wireless parts: Atheros AR9223 802.11bgn / Atheros
>> AR9220 802.11an.
>>
>> Sure, I hope I got the right one. Now this is not from the same boot as the
>> one with the errors, but I assume that does not make a difference… Since I am
>> located in Germany I set the regulatory domain to DE. please let me know if I
>> you need any additional information or testing (note I am not set up to build
>> cerowrt myself, so I would need Dave Täht's help to build a modified 
>> firmware)

THANK YOU!

I have applied the patch to the next build of cerowrt-3.10.24-1 for
the wndr3700v2 and 3800 which will be here when the build completes:

http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.24-1

100% completely untested by me til sunday! Don't try this on your
default home router.

While I'm here on linux-wireless:

Cerowrt really needs a new maintainer and more people able to build
it. I am generally working on some queuing theory (in wireless/wifi)
right now, fixing a new chipset in a new box that I can't talk about
(yet), and low on free time, and working on standardizing fq_codel in
the ietf is eating what little spare time I have left.

Although dedicating my sundays to Cero, I'm losing the general purpose
skill set required to keep the continuous integration phase from
openwrt to cero on the wndr3800 going. I care about keeping cero
going, but after 3 years of building it and after struggling to make
it stable since august, I'm feeling washed up and burned out on it. I
think we are very close to a stable release, though, and I'll feel
much better about things after this bug is gone…

But while I'm limping along...

Any volunteers to help get the next release after this one out? Any
suggestions for doing it mo better? Or a better strategy for testing
more fixes for bufferbloat?

There MIGHT be some funding for Cero next year. There never has been
before, and there have been too many broken promises, sooo the only
true reward I know of for working on bufferbloat with cerowrt (and it
is major!) is doing bleeding edge research on the Internet's most
nagging problems…. and *solving them*.

OK, then there's also the user base, which is wonderful. And the
notoriety. And kicking the vendors and ISPs making crappy routers in
the shins on a regular basis. Etc.

I'd like to add a next-generation bleeding edge chip to the effort but
can't without more funding and more volunteers.

> Can you try this patch ?

I have folded this into cerowrt-3.10.24-1. Note that in addition to
this problem the last couple builds have been testing dnsmasq 2.68
which may have also broke at the same time, and I am far from the
yurtlab right now so I am unable to test before sunday. (use fixed ip
addrs if it's still busted)

:Crossed fingers:

I note that I don't know if there is a cause or effect relationship in
the DMA tx bug to what we are actually seeing, with radios falling off
the net. I have a similar long-standing bug with babel doing ipv6
ad-hoc mode multicasts and receives and seeing other nodes, but no
actual unicast traffic being capable of being transmitted. That too
seems to happen after seeing the DMA tx bug and days of uptime.

I have also setup an ath9k in several x86 boxes to see if this problem
occurs there. I'd thought it didn't, and that pointed to some sort of
write barrier problem, maybe...

thanks again for taking a stab at the problem! I was merely going to
add a WARN_ON to start searching, didn't think this would arrive in my
mailbox this morning!

> diff --git a/drivers/net/wireless/ath/ath9k/ar9002_mac.c 
> b/drivers/net/wireless/ath/ath9k/ar9002_mac.c
> index 8d78253..0337de7 100644
> --- a/drivers/net/wireless/ath/ath9k/ar9002_mac.c
> +++ b/drivers/net/wireless/ath/ath9k/ar9002_mac.c
> @@ -76,9 +76,16 @@ static bool ar9002_hw_get_isr(struct ath_hw *ah, enum 
> ath9k_int *masked)
> mask2 |= ATH9K_INT_CST;
> if (isr2 & AR_ISR_S2_TSFOOR)
> mask2 |= ATH9K_INT_TSFOOR;
> +
> +   if (!(pCap->hw_caps & ATH9K_HW_CAP_RAC_SUPPORTED)) {
> +   REG_WRITE(ah, AR_ISR_S2, isr2);
> +   isr &= ~AR_ISR_BCNMISC;
> +   }
> }
>
> -   isr = REG_READ(ah, AR_ISR_RAC);
> +   if (pCap->hw_caps & ATH9K_HW_CAP_RAC_SUPPORTED)
> +   isr = REG_READ(ah, AR_ISR_RAC);
> +
> if (isr == 0x) {
> *masked = 0;
> return false;
> @@ -97,11 +104,23 @@ static bool ar9002_hw_get_isr(struct ath_hw *ah, enum 
> ath9k_int *masked)
>
> *masked |= ATH9K_INT_TX;
>
> -

Re: [ath9k-devel] [Cerowrt-devel] Wireless failures 3.10.17-3

2013-12-13 Thread Sebastian Moeller

Hello Felix,


On Dec 13, 2013, at 17:51 , Felix Fietkau  wrote:

> On 2013-12-13 10:48, Sebastian Moeller wrote:
>> Hi Sujith,
>> 
>> On Dec 13, 2013, at 10:27 , Sujith Manoharan  wrote:
>> 
>>> Sebastian Moeller wrote:
 It is a net gear WNDR3700 v2, so according to:
 http://wiki.openwrt.org/toh/netgear/wndr3700 it is a Atheros AR7161 rev 2 
 680
 MHz soc with the following wireless parts: Atheros AR9223 802.11bgn / 
 Atheros
 AR9220 802.11an.
 
 Sure, I hope I got the right one. Now this is not from the same boot as the
 one with the errors, but I assume that does not make a difference… Since I 
 am
 located in Germany I set the regulatory domain to DE. please let me know 
 if I
 you need any additional information or testing (note I am not set up to 
 build
 cerowrt myself, so I would need Dave Täht's help to build a modified 
 firmware)
>>> 
>>> Can you try this patch ?
>> 
>>  I will, but it will take some time, as I cannot build the firmware for 
>> this device myself, but need help. So I let you know once I tested the 
>> patched kernel.
> On OpenWrt/CeroWrt you should not patch it into the kernel. You need to
> add it as a patch for package/kernel/mac80211.

Ah, thanks, good to know. Vielen Dank. (I still need Dave's help in 
integrating this patch into a firmware image so I can actually test it...)

Best Regards
Sebastian

> 
> - Felix
> ___
> Cerowrt-devel mailing list
> cerowrt-de...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [Cerowrt-devel] Wireless failures 3.10.17-3

2013-12-13 Thread Felix Fietkau

On 2013-12-13 10:48, Sebastian Moeller wrote:
> Hi Sujith,
> 
> On Dec 13, 2013, at 10:27 , Sujith Manoharan  wrote:
> 
>> Sebastian Moeller wrote:
>>> It is a net gear WNDR3700 v2, so according to:
>>> http://wiki.openwrt.org/toh/netgear/wndr3700 it is a Atheros AR7161 rev 2 
>>> 680
>>> MHz soc with the following wireless parts: Atheros AR9223 802.11bgn / 
>>> Atheros
>>> AR9220 802.11an.
>>> 
>>> Sure, I hope I got the right one. Now this is not from the same boot as the
>>> one with the errors, but I assume that does not make a difference… Since I 
>>> am
>>> located in Germany I set the regulatory domain to DE. please let me know if 
>>> I
>>> you need any additional information or testing (note I am not set up to 
>>> build
>>> cerowrt myself, so I would need Dave Täht's help to build a modified 
>>> firmware)
>> 
>> Can you try this patch ?
> 
>   I will, but it will take some time, as I cannot build the firmware for 
> this device myself, but need help. So I let you know once I tested the 
> patched kernel.
On OpenWrt/CeroWrt you should not patch it into the kernel. You need to
add it as a patch for package/kernel/mac80211.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Key Cache corruption

2013-12-13 Thread Antonio Quartulli

Oky!

Meanwhile you get a reply from the MAC guys I will try to test again the
"check & fix" approach. It is really strange that I can't recognize any
corruption.

However, the problem of the TX key corruption still remains. It seems we
can't do much about that.


Cheers (and thanks a lot so far!),

On 13/12/13 13:35, Adrian Chadd wrote:
> There's a work around, yeah. Much like I've/we've described.
> 
> 
> 
> -adrian
> 
> On 12 December 2013 01:17, Antonio Quartulli  wrote:
>> Hi Adrian!
>>
>> but as far as you know, isn't the internal Atheros driver applying any
>> workaround or strange hack to circumvent this problem?
>> Or simply there is no "clear" workaround at all? (maybe this is what you
>> expect to be told from the MAC guys?)
>>
>>
>>
>> Cheers,
>>
>>
>> On 09/12/13 20:38, Adrian Chadd wrote:
>>> Hi!
>>>
>>> I've emailed them - they're tossing it around internally.
>>>
>>>
>>> -a
>>>
>>> On 9 December 2013 02:17, Antonio Quartulli  wrote:
>>> Hoi Adrian,
>>>
>>> I don't want to push (I am just polling here ;-)), but have you been
>>> able to squeeze any information out of the MAC guys?
>>>
>>> Cheers,
>>>
>>> On 04/12/13 18:08, Adrian Chadd wrote:
>> Hi,
>>
>> I'll see if I can organise a chat with the MAC guys this week at
>> Atheros and ask them about this. Stay tuned...
>>
>>
>> -a
>>
>> On 4 December 2013 05:23, Antonio Quartulli 
>> wrote: Hi list, hi Adrian, hi Sujith (just added to the cc list),
>>
>> sorry for the silence, but I have been busy testing different
>> approaches on how to solve this.
>>
>> On 22/11/13 10:42, Adrian Chadd wrote:
>>
>>
>> Mh, that is true with TKIP.
>>
>> This means we have no way to recognize a TX key corruption. For
>> this reason a periodic worker that unconditionally checks the cache
>> and possibly refresh it looked like the best solution.
>>
>> However, after testing this strategy I realised that the worker is
>> not able to see the cache corruption: what it reads from the memory
>> always matches what we have in mac80211 (but I am sure we had a
>> corruption).
>>
>> My opinion is that the corruption is really happening at a low-low
>> level and so the memory content is not even altered. This may be
>> one of the reasons why this bug is so difficult to catch.
>>
>> The only solution I see to this problem is to make the periodic
>> worker refresh the key cache every second, no matter if a
>> corruption is found or not.
>>
>> However it does not sound like a good solution..any thought?
>>
>>
>>
>> Another experiment I have done was to refresh the whole key cache
>> each time a new key is pushed into ath9k. I did this because I
>> observed that the corruption was triggered upon GTK upload (on
>> re-keying). This fix seemed to make things better.
>>
>> So another plausible strategy could be a mix of the above
>> solutions:
>>
>> 1) refresh the entire cache on each set_key(cmd=SET_KEY) call 2)
>> upon detection of a number of RX decrypt errors schedule a worker
>> that refresh the entire cache (not the single slot...because that
>> could be the cause for another corruption...).
>>
>>
>> Still we have the problem of the TX key corruption with TKIP. If
>> this happens we can't detect it and we need to wait for the next
>> set_key() before the key can be properly restored.
>>
>>
>> Any better idea?
>>
>>
>> Regards,
>>
>>
>>>
>>
>> --
>> Antonio Quartulli
>>


-- 
Antonio Quartulli



signature.asc
Description: OpenPGP digital signature
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Key Cache corruption

2013-12-13 Thread Adrian Chadd

There's a work around, yeah. Much like I've/we've described.



-adrian

On 12 December 2013 01:17, Antonio Quartulli  wrote:
> Hi Adrian!
>
> but as far as you know, isn't the internal Atheros driver applying any
> workaround or strange hack to circumvent this problem?
> Or simply there is no "clear" workaround at all? (maybe this is what you
> expect to be told from the MAC guys?)
>
>
>
> Cheers,
>
>
> On 09/12/13 20:38, Adrian Chadd wrote:
>> Hi!
>>
>> I've emailed them - they're tossing it around internally.
>>
>>
>> -a
>>
>> On 9 December 2013 02:17, Antonio Quartulli  wrote:
>> Hoi Adrian,
>>
>> I don't want to push (I am just polling here ;-)), but have you been
>> able to squeeze any information out of the MAC guys?
>>
>> Cheers,
>>
>> On 04/12/13 18:08, Adrian Chadd wrote:
> Hi,
>
> I'll see if I can organise a chat with the MAC guys this week at
> Atheros and ask them about this. Stay tuned...
>
>
> -a
>
> On 4 December 2013 05:23, Antonio Quartulli 
> wrote: Hi list, hi Adrian, hi Sujith (just added to the cc list),
>
> sorry for the silence, but I have been busy testing different
> approaches on how to solve this.
>
> On 22/11/13 10:42, Adrian Chadd wrote:
>
>
> Mh, that is true with TKIP.
>
> This means we have no way to recognize a TX key corruption. For
> this reason a periodic worker that unconditionally checks the cache
> and possibly refresh it looked like the best solution.
>
> However, after testing this strategy I realised that the worker is
> not able to see the cache corruption: what it reads from the memory
> always matches what we have in mac80211 (but I am sure we had a
> corruption).
>
> My opinion is that the corruption is really happening at a low-low
> level and so the memory content is not even altered. This may be
> one of the reasons why this bug is so difficult to catch.
>
> The only solution I see to this problem is to make the periodic
> worker refresh the key cache every second, no matter if a
> corruption is found or not.
>
> However it does not sound like a good solution..any thought?
>
>
>
> Another experiment I have done was to refresh the whole key cache
> each time a new key is pushed into ath9k. I did this because I
> observed that the corruption was triggered upon GTK upload (on
> re-keying). This fix seemed to make things better.
>
> So another plausible strategy could be a mix of the above
> solutions:
>
> 1) refresh the entire cache on each set_key(cmd=SET_KEY) call 2)
> upon detection of a number of RX decrypt errors schedule a worker
> that refresh the entire cache (not the single slot...because that
> could be the cause for another corruption...).
>
>
> Still we have the problem of the TX key corruption with TKIP. If
> this happens we can't detect it and we need to wait for the next
> set_key() before the key can be properly restored.
>
>
> Any better idea?
>
>
> Regards,
>
>
>>
>
> --
> Antonio Quartulli
>
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Fwd: ath9k: set 5/10 MHz supported channels

2013-12-13 Thread sotouki

Hi all,

finally managed to change the channel width through ath9k driver. In the
main.c you can play with the channelFlags variable. You can set this to
QUARTER or HALF. I do not know if this way is correct but it works for
my case.

Greetings

Tomas

On 11/23/2013 04:18 PM, Kamran Nishat wrote:
>
>
> -- Forwarded message --
> From: *Kamran Nishat*  >
> Date: Sat, Nov 23, 2013 at 12:00 PM
> Subject: Re: [ath9k-devel] ath9k: set 5/10 MHz supported channels
> To: Simon Wunderlich  >
>
>
> Simon
> Can we merge openwrt source and iwreless-next tree? what will happen
> if we do this?
> Best
>
> Kamran
>
>
> On Fri, Nov 22, 2013 at 3:30 PM, Simon Wunderlich
> mailto:s...@simonwunderlich.de>> wrote:
>
> Kamran,
>
> > I have an AP with  AR9160 tunning openWRT. When I set chennel to
> 10MHz from
> > debugfs entry. I can still connect it with other boards running
> OpenWrt.
> > But from computers running latest linux kernel it was visible in
> scan when
> > I was using AR5416 but I was not able to connect to my AP.
> > Then I changed NIC to Atheros AR9227 based card not I can even
> see openwrt
> > AP with 10MHz channel.
>
> Please note that the OpenWRT and the mainline Linux implementation
> of 5/10 MHz
> are different. In Linux we have a limited but (hopefully)
> standard-conforming
> implementation, that means that also bitrates are interpreted for
> their
> respective frequencies. For example on mainline LInux in 5 MHz
> mode you have
> OFDM bitrates of 1.5, 2.25, 3, 4.5 Mbit/s etc what would be 6, 9,
> 12, 18
> Mbit/s on 20 MHz. OpenWRT will just announce the 20 MHz bitrates
> even on 5 MHz
> (it's more of a hack). This will likely confuse the Linux clients.
> There might
> also be other knobs not complete, as I said I've only tested the
> IBSS mode.
>
> For the record I tested AR9220 and AR5213 in 5 and 10 MHz mode and
> after some
> timing corrections (patches have been merged upstream) this worked
> quite well.
>
> I'd recommend to use only the same implementation together.
>
> Cheers,
> Simon
>
>
>
>
>
> ___
> 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] ath9k/AR9380: Is it possible to increase the number of supported BSS

2013-12-13 Thread michael-dev

Hi,

to whom it may concern.

I'm currently using the following patch and it seems to work for me 
using 12 BSS (just some short superficial testing). Not sure if 
BSTUCK_THRESH modification is needed.
No warranty given ;)

Regards,
  M. Braun

--- compat-wireless-2013-11-05/drivers/net/wireless/ath/ath9k/init.c
2013-12-12 22:16:49.905847035 +0100
+++ compat-wireless-2013-11-05/drivers/net/wireless/ath/ath9k/init.c
2013-12-12 22:16:59.122863038 +0100
@@ -843,7 +843,7 @@
 { .max = 2048,  .types = BIT(NL80211_IFTYPE_STATION) |
  BIT(NL80211_IFTYPE_P2P_CLIENT) |
  BIT(NL80211_IFTYPE_WDS) },
-   { .max = 8, .types =
+   { .max = 16,.types =
  #ifdef CPTCFG_MAC80211_MESH
  BIT(NL80211_IFTYPE_MESH_POINT) |
  #endif
--- compat-wireless-2013-11-05/drivers/net/wireless/ath/ath9k/ath9k.h   
2013-12-13 10:03:08.957657934 +0100
+++ compat-wireless-2013-11-05/drivers/net/wireless/ath/ath9k/ath9k.h   
2013-12-13 10:03:32.212694050 +0100
@@ -381,8 +381,8 @@
   * number of BSSIDs) if a given beacon does not go out even after 
waiting this
   * number of beacon intervals, the game's up.
   */
-#define BSTUCK_THRESH  9
-#defineATH_BCBUF   8
+#define BSTUCK_THRESH  17
+#defineATH_BCBUF   16
  #define ATH_DEFAULT_BINTVAL100 /* TU */
  #define ATH_DEFAULT_BMISS_LIMIT10
  #define IEEE80211_MS_TO_TU(x)   (((x) * 1000) / 1024)

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [Cerowrt-devel] Wireless failures 3.10.17-3

2013-12-13 Thread Sebastian Moeller

Hi Sujith,

On Dec 13, 2013, at 10:27 , Sujith Manoharan  wrote:

> Sebastian Moeller wrote:
>> It is a net gear WNDR3700 v2, so according to:
>> http://wiki.openwrt.org/toh/netgear/wndr3700 it is a Atheros AR7161 rev 2 680
>> MHz soc with the following wireless parts: Atheros AR9223 802.11bgn / Atheros
>> AR9220 802.11an.
>> 
>> Sure, I hope I got the right one. Now this is not from the same boot as the
>> one with the errors, but I assume that does not make a difference… Since I am
>> located in Germany I set the regulatory domain to DE. please let me know if I
>> you need any additional information or testing (note I am not set up to build
>> cerowrt myself, so I would need Dave Täht's help to build a modified 
>> firmware)
> 
> Can you try this patch ?

I will, but it will take some time, as I cannot build the firmware for 
this device myself, but need help. So I let you know once I tested the patched 
kernel.

Best Regards & many thanks
Sebastian


> 
> diff --git a/drivers/net/wireless/ath/ath9k/ar9002_mac.c 
> b/drivers/net/wireless/ath/ath9k/ar9002_mac.c
> index 8d78253..0337de7 100644
> --- a/drivers/net/wireless/ath/ath9k/ar9002_mac.c
> +++ b/drivers/net/wireless/ath/ath9k/ar9002_mac.c
> @@ -76,9 +76,16 @@ static bool ar9002_hw_get_isr(struct ath_hw *ah, enum 
> ath9k_int *masked)
>   mask2 |= ATH9K_INT_CST;
>   if (isr2 & AR_ISR_S2_TSFOOR)
>   mask2 |= ATH9K_INT_TSFOOR;
> +
> + if (!(pCap->hw_caps & ATH9K_HW_CAP_RAC_SUPPORTED)) {
> + REG_WRITE(ah, AR_ISR_S2, isr2);
> + isr &= ~AR_ISR_BCNMISC;
> + }
>   }
> 
> - isr = REG_READ(ah, AR_ISR_RAC);
> + if (pCap->hw_caps & ATH9K_HW_CAP_RAC_SUPPORTED)
> + isr = REG_READ(ah, AR_ISR_RAC);
> +
>   if (isr == 0x) {
>   *masked = 0;
>   return false;
> @@ -97,11 +104,23 @@ static bool ar9002_hw_get_isr(struct ath_hw *ah, enum 
> ath9k_int *masked)
> 
>   *masked |= ATH9K_INT_TX;
> 
> - s0_s = REG_READ(ah, AR_ISR_S0_S);
> + if (pCap->hw_caps & ATH9K_HW_CAP_RAC_SUPPORTED) {
> + s0_s = REG_READ(ah, AR_ISR_S0_S);
> + s1_s = REG_READ(ah, AR_ISR_S1_S);
> + } else {
> + s0_s = REG_READ(ah, AR_ISR_S0);
> + REG_WRITE(ah, AR_ISR_S0, s0_s);
> + s1_s = REG_READ(ah, AR_ISR_S1);
> + REG_WRITE(ah, AR_ISR_S1, s1_s);
> +
> + isr &= ~(AR_ISR_TXOK |
> +  AR_ISR_TXDESC |
> +  AR_ISR_TXERR |
> +  AR_ISR_TXEOL);
> + }
> +
>   ah->intr_txqs |= MS(s0_s, AR_ISR_S0_QCU_TXOK);
>   ah->intr_txqs |= MS(s0_s, AR_ISR_S0_QCU_TXDESC);
> -
> - s1_s = REG_READ(ah, AR_ISR_S1_S);
>   ah->intr_txqs |= MS(s1_s, AR_ISR_S1_QCU_TXERR);
>   ah->intr_txqs |= MS(s1_s, AR_ISR_S1_QCU_TXEOL);
>   }
> @@ -120,7 +139,12 @@ static bool ar9002_hw_get_isr(struct ath_hw *ah, enum 
> ath9k_int *masked)
>   if (isr & AR_ISR_GENTMR) {
>   u32 s5_s;
> 
> - s5_s = REG_READ(ah, AR_ISR_S5_S);
> + if (pCap->hw_caps & ATH9K_HW_CAP_RAC_SUPPORTED) {
> + s5_s = REG_READ(ah, AR_ISR_S5_S);
> + } else {
> + s5_s = REG_READ(ah, AR_ISR_S5);
> + }
> +
>   ah->intr_gen_timer_trigger =
>   MS(s5_s, AR_ISR_S5_GENTIMER_TRIG);
> 
> @@ -133,6 +157,16 @@ static bool ar9002_hw_get_isr(struct ath_hw *ah, enum 
> ath9k_int *masked)
>   if ((s5_s & AR_ISR_S5_TIM_TIMER) &&
>   !(pCap->hw_caps & ATH9K_HW_CAP_AUTOSLEEP))
>   *masked |= ATH9K_INT_TIM_TIMER;
> +
> + if (!(pCap->hw_caps & ATH9K_HW_CAP_RAC_SUPPORTED)) {
> + REG_WRITE(ah, AR_ISR_S5, s5_s);
> + isr &= ~AR_ISR_GENTMR;
> + }
> + }
> +
> + if (!(pCap->hw_caps & ATH9K_HW_CAP_RAC_SUPPORTED)) {
> + REG_WRITE(ah, AR_ISR, isr);
> + REG_READ(ah, AR_ISR);
>   }
> 
>   if (sync_cause) {
> 
> 
> A version that applies over OpenWrt trunk is here:
> http://msujith.org/dir/patches/wl/Dec-13-2013/0001-ath9k-Interrupt-handling-fix-for-AR9002-family.patch
> 
> Sujith

-- 
Sandra, Okko, Joris, & Sebastian Moeller
Telefon: +49 7071 96 49 783, +49 7071 96 49 784, +49 7071 96 49 785
GSM: +49-1577-190 31 41
GSM: +49-1517-00 70 355

Moltkestrasse 6
72072 Tuebingen
Deutschland

__

Re: [ath9k-devel] Atheros QCWB335 / AR9565 / QCA9565 Bluetooth

2013-12-13 Thread Sujith Manoharan

Joshua Richenhagen wrote:
> Dear Sujith,
> 
> I was just wondering that the patch still didn't landed upstream until
> 3.13-rc3. Are you holding the patch back until the firmware bug is
> solved?

The patch has been merged in bluetooth-next:
https://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=35580d223b6b04d9a570e4fe377c46a102413fe8

Sujith
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [Cerowrt-devel] Wireless failures 3.10.17-3

2013-12-13 Thread Sujith Manoharan

Sebastian Moeller wrote:
> It is a net gear WNDR3700 v2, so according to:
> http://wiki.openwrt.org/toh/netgear/wndr3700 it is a Atheros AR7161 rev 2 680
> MHz soc with the following wireless parts: Atheros AR9223 802.11bgn / Atheros
> AR9220 802.11an.
> 
> Sure, I hope I got the right one. Now this is not from the same boot as the
> one with the errors, but I assume that does not make a difference… Since I am
> located in Germany I set the regulatory domain to DE. please let me know if I
> you need any additional information or testing (note I am not set up to build
> cerowrt myself, so I would need Dave Täht's help to build a modified firmware)

Can you try this patch ?

diff --git a/drivers/net/wireless/ath/ath9k/ar9002_mac.c 
b/drivers/net/wireless/ath/ath9k/ar9002_mac.c
index 8d78253..0337de7 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_mac.c
@@ -76,9 +76,16 @@ static bool ar9002_hw_get_isr(struct ath_hw *ah, enum 
ath9k_int *masked)
mask2 |= ATH9K_INT_CST;
if (isr2 & AR_ISR_S2_TSFOOR)
mask2 |= ATH9K_INT_TSFOOR;
+
+   if (!(pCap->hw_caps & ATH9K_HW_CAP_RAC_SUPPORTED)) {
+   REG_WRITE(ah, AR_ISR_S2, isr2);
+   isr &= ~AR_ISR_BCNMISC;
+   }
}
 
-   isr = REG_READ(ah, AR_ISR_RAC);
+   if (pCap->hw_caps & ATH9K_HW_CAP_RAC_SUPPORTED)
+   isr = REG_READ(ah, AR_ISR_RAC);
+
if (isr == 0x) {
*masked = 0;
return false;
@@ -97,11 +104,23 @@ static bool ar9002_hw_get_isr(struct ath_hw *ah, enum 
ath9k_int *masked)
 
*masked |= ATH9K_INT_TX;
 
-   s0_s = REG_READ(ah, AR_ISR_S0_S);
+   if (pCap->hw_caps & ATH9K_HW_CAP_RAC_SUPPORTED) {
+   s0_s = REG_READ(ah, AR_ISR_S0_S);
+   s1_s = REG_READ(ah, AR_ISR_S1_S);
+   } else {
+   s0_s = REG_READ(ah, AR_ISR_S0);
+   REG_WRITE(ah, AR_ISR_S0, s0_s);
+   s1_s = REG_READ(ah, AR_ISR_S1);
+   REG_WRITE(ah, AR_ISR_S1, s1_s);
+
+   isr &= ~(AR_ISR_TXOK |
+AR_ISR_TXDESC |
+AR_ISR_TXERR |
+AR_ISR_TXEOL);
+   }
+
ah->intr_txqs |= MS(s0_s, AR_ISR_S0_QCU_TXOK);
ah->intr_txqs |= MS(s0_s, AR_ISR_S0_QCU_TXDESC);
-
-   s1_s = REG_READ(ah, AR_ISR_S1_S);
ah->intr_txqs |= MS(s1_s, AR_ISR_S1_QCU_TXERR);
ah->intr_txqs |= MS(s1_s, AR_ISR_S1_QCU_TXEOL);
}
@@ -120,7 +139,12 @@ static bool ar9002_hw_get_isr(struct ath_hw *ah, enum 
ath9k_int *masked)
if (isr & AR_ISR_GENTMR) {
u32 s5_s;
 
-   s5_s = REG_READ(ah, AR_ISR_S5_S);
+   if (pCap->hw_caps & ATH9K_HW_CAP_RAC_SUPPORTED) {
+   s5_s = REG_READ(ah, AR_ISR_S5_S);
+   } else {
+   s5_s = REG_READ(ah, AR_ISR_S5);
+   }
+
ah->intr_gen_timer_trigger =
MS(s5_s, AR_ISR_S5_GENTIMER_TRIG);
 
@@ -133,6 +157,16 @@ static bool ar9002_hw_get_isr(struct ath_hw *ah, enum 
ath9k_int *masked)
if ((s5_s & AR_ISR_S5_TIM_TIMER) &&
!(pCap->hw_caps & ATH9K_HW_CAP_AUTOSLEEP))
*masked |= ATH9K_INT_TIM_TIMER;
+
+   if (!(pCap->hw_caps & ATH9K_HW_CAP_RAC_SUPPORTED)) {
+   REG_WRITE(ah, AR_ISR_S5, s5_s);
+   isr &= ~AR_ISR_GENTMR;
+   }
+   }
+
+   if (!(pCap->hw_caps & ATH9K_HW_CAP_RAC_SUPPORTED)) {
+   REG_WRITE(ah, AR_ISR, isr);
+   REG_READ(ah, AR_ISR);
}
 
if (sync_cause) {


A version that applies over OpenWrt trunk is here:
http://msujith.org/dir/patches/wl/Dec-13-2013/0001-ath9k-Interrupt-handling-fix-for-AR9002-family.patch

Sujith
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] ath9k/AR9380: Is it possible to increase the number of supported BSS

2013-12-13 Thread michael-dev

Hi,

currently ath9k is limited to at most 8 BSS in AP-Mode.
Would it be possible to increase this limit or is it a hardware 
limitation?

Thanks,
  M. Braun
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [Cerowrt-devel] Wireless failures 3.10.17-3

Re: [ath9k-devel] [Cerowrt-devel] Wireless failures 3.10.17-3

Re: [ath9k-devel] [Cerowrt-devel] Wireless failures 3.10.17-3

Re: [ath9k-devel] [Cerowrt-devel] Wireless failures 3.10.17-3

Re: [ath9k-devel] [Cerowrt-devel] Wireless failures 3.10.17-3

Re: [ath9k-devel] Key Cache corruption

Re: [ath9k-devel] Key Cache corruption

Re: [ath9k-devel] Fwd: ath9k: set 5/10 MHz supported channels

Re: [ath9k-devel] ath9k/AR9380: Is it possible to increase the number of supported BSS

Re: [ath9k-devel] [Cerowrt-devel] Wireless failures 3.10.17-3

Re: [ath9k-devel] Atheros QCWB335 / AR9565 / QCA9565 Bluetooth

Re: [ath9k-devel] [Cerowrt-devel] Wireless failures 3.10.17-3

[ath9k-devel] ath9k/AR9380: Is it possible to increase the number of supported BSS

13 matches

Site Navigation

Mail list logo

Footer information