Re: [ath9k-devel] [RFC 0/3] of: add common bindings to (de)activate IEEE 802.11 bands

On 2016-10-05 22:31, Rob Herring wrote: > On Wed, Oct 5, 2016 at 1:36 PM, Felix Fietkau <n...@nbd.name> wrote: >> On 2016-10-05 20:25, Martin Blumenstingl wrote: >>> On Mon, Oct 3, 2016 at 5:22 PM, Rob Herring <robh...@kernel.org> wrote: >>>> On Sun, O

Re: [ath9k-devel] [RFC 0/3] of: add common bindings to (de)activate IEEE 802.11 bands

On 2016-10-05 20:25, Martin Blumenstingl wrote: > On Mon, Oct 3, 2016 at 5:22 PM, Rob Herring wrote: >> On Sun, Oct 2, 2016 at 5:50 PM, Martin Blumenstingl >> wrote: >>> There are at least two drivers (ath9k and mt76) out there, where >>>

Re: [ath9k-devel] [v3] ath9k: Switch to using mac80211 intermediate software queues.

On 2016-07-08 18:28, Toke Høiland-Jørgensen wrote: > Felix Fietkau <n...@nbd.name> writes: > >> On 2016-07-08 17:53, Toke Høiland-Jørgensen wrote: >>> Kalle Valo <kv...@qca.qualcomm.com> writes: >>> >>>> Toke Høiland-Jørgensen wrote

Re: [ath9k-devel] [PATCH v2] ath9k: Switch to using mac80211 intermediate software queues.

On 2016-07-06 20:52, Toke Høiland-Jørgensen wrote: > Felix Fietkau <n...@nbd.name> writes: > >> On 2016-07-06 18:16, Toke Høiland-Jørgensen wrote: >>> This switches ath9k over to using the mac80211 intermediate software >>> queueing mechanism for data pac

Re: [ath9k-devel] [PATCH v2] ath9k: Switch to using mac80211 intermediate software queues.

gt; > Based on Tim's original patch set, but reworked quite thoroughly. > > Cc: Tim Shepard <s...@alum.mit.edu> > Cc: Felix Fietkau <n...@nbd.name> > Signed-off-by: Toke Høiland-Jørgensen <t...@toke.dk> > --- > Changes since v1: > - Remove the ol

Re: [ath9k-devel] [PATCH] ath9k: Switch to using mac80211 intermediate software queues.

On 2016-07-04 19:46, Toke Høiland-Jørgensen wrote: > Tim Shepard writes: > >> Thanks for unconfusing me a couple weeks ago, and cluing me into how >> the limit on ->pending_frames is not really relevant for the data >> packets that go through the new intermediate queues. >> >>

Re: [ath9k-devel] [PATCH RFC v2 1/2] Documentation: dt: net: add ath9k wireless device binding

On 2016-06-27 14:57, Mark Rutland wrote: > On Thu, Jun 23, 2016 at 08:14:29PM +0200, Martin Blumenstingl wrote: >> On Thu, Jun 23, 2016 at 7:58 PM, Mark Rutland wrote: >> > On Thu, Jun 23, 2016 at 07:45:35PM +0200, Martin Blumenstingl wrote: >> >> +- qca,eeprom-name: The

Re: [ath9k-devel] [PATCH v3 2/3] ath9k: add a helper to get the string representation of ath_bus_type

On 2016-06-24 14:34, Martin Blumenstingl wrote: > Signed-off-by: Martin Blumenstingl > --- > this is a new patch which didn't exist in v2 yet, it prepares the new > function ath_bus_type_to_string which will be used in patch #3 > >

Re: [ath9k-devel] [PATCH 1/2] ath9k: use mac80211 intermediate software queues

On 2016-06-17 15:48, Felix Fietkau wrote: > On 2016-06-17 15:43, Toke Høiland-Jørgensen wrote: >> Felix Fietkau <n...@nbd.name> writes: >> >>> On 2016-06-17 11:09, Toke Høiland-Jørgensen wrote: >>>> This patch leaves the code for ath9k's internal per-

Re: [ath9k-devel] [PATCH 1/2] ath9k: use mac80211 intermediate software queues

On 2016-06-17 15:41, Tim Shepard wrote: >> > diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h >> > b/drivers/net/wireless/ath/ath9k/ath9k.h >> > index 93b3793..caeae10 100644 >> > --- a/drivers/net/wireless/ath/ath9k/ath9k.h >> > +++ b/drivers/net/wireless/ath/ath9k/ath9k.h >> > @@ -145,8

Re: [ath9k-devel] [PATCH 1/2] ath9k: use mac80211 intermediate software queues

On 2016-06-17 15:43, Toke Høiland-Jørgensen wrote: > Felix Fietkau <n...@nbd.name> writes: > >> On 2016-06-17 11:09, Toke Høiland-Jørgensen wrote: >>> This patch leaves the code for ath9k's internal per-node per-tid >>> queues in place and just modifies the

Re: [ath9k-devel] [PATCH 1/2] ath9k: use mac80211 intermediate software queues

On 2016-06-17 11:09, Toke Høiland-Jørgensen wrote: > This patch leaves the code for ath9k's internal per-node per-tid > queues in place and just modifies the driver to also pull from > the new mac80211 intermediate software queues, and implements > the .wake_tx_queue method, which will cause

Re: [ath9k-devel] [PATCH 5/6] ath9k: Use defined constants consistently.

On 2016-06-07 15:10, Benjamin Berg wrote: > From: Benjamin Berg > > Signed-off-by: Benjamin Berg > --- > drivers/net/wireless/ath/ath9k/main.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git

Re: [ath9k-devel] [PATCH v2] ath9k: interpret requested txpower in EIRP domain

On 2016-05-17 12:54, Zefir Kurtisi wrote: > On 05/14/2016 02:50 PM, Felix Fietkau wrote: >> On 2016-04-01 11:37, Zefir Kurtisi wrote: >>> Tx power limitations at upper layers are interpreted in >>> the EIRP domain. When the user requests a given maximum >>> txpo

Re: [ath9k-devel] [PATCH v2] ath9k: interpret requested txpower in EIRP domain

On 2016-04-01 11:37, Zefir Kurtisi wrote: > Tx power limitations at upper layers are interpreted in > the EIRP domain. When the user requests a given maximum > txpower, e.g. with: 'iw phy0 set txpower fixed 1500', > he expects the EIRP to be at or below 15dBm. > > In ath9k_hw_apply_txpower(), the

Re: [ath9k-devel] [PATCH] ath9k: Fix symbol overlap window for half/quarter channels

> > Fix this by using the available IS_CHAN_HALF_RATE and IS_CHAN_QUARTER_RATE > marcros instead. > > Signed-off-by: Helmut Schaa <helmut.sc...@googlemail.com> > Cc: Felix Fietkau <n...@openwrt.org> > --- > Just stumbled over that piece of code while looking

Re: [ath9k-devel] [PATCH 2/3] ath9k: make rxfilter per HW

On 2015-06-22 13:59, Johannes Berg wrote: On Mon, 2015-06-22 at 13:58 +0200, Johannes Berg wrote: On Mon, 2015-06-22 at 13:43 +0200, Janusz Dziedzic wrote: mac80211 configure rxfilter per HW, so we don't need this per channel. As I said before, I think there's value in mac80211 doing it

Re: [ath9k-devel] [RFC] ath9k: allow to receive probe request when offchannel

On 2015-06-10 07:03, Janusz Dziedzic wrote: This fix problem that p2p group negotiation didn't work correctly when chanctx used, because we didn't receive probe requests when offchannel and use_chanctx=1 Signed-off-by: Janusz Dziedzic janusz.dzied...@tieto.com --- @Felix, Sujith could you

Re: [ath9k-devel] [PATCH] ath9k: add phy.c

On 2015-05-16 07:24, Oleksij Rempel wrote: Am 15.05.2015 um 21:34 schrieb Felix Fietkau: On 2015-05-15 14:35, Oleksij Rempel wrote: ... and move dup code from ar5008_phy.c and ar9002_phy.c to phy.c Signed-off-by: Oleksij Rempel li...@rempel-privat.de We already have base functionality

Re: [ath9k-devel] [PATCH] ath9k: add phy.c

On 2015-05-15 14:35, Oleksij Rempel wrote: ... and move dup code from ar5008_phy.c and ar9002_phy.c to phy.c Signed-off-by: Oleksij Rempel li...@rempel-privat.de We already have base functionality for AR5008-AR9002 provided in some ar5008_phy.c, and ar5008_hw_attach_phy_ops is called for those

Re: [ath9k-devel] [PATCH 18/18] ath9k: use REG_RMW and rmw buffer in ath9k_hw_def_set_gain

On 2015-03-20 13:38, Oleksij Rempel wrote: Signed-off-by: Oleksij Rempel li...@rempel-privat.de --- drivers/net/wireless/ath/ath9k/eeprom_def.c | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/eeprom_def.c

Re: [ath9k-devel] [PATCH 16/18] ath9k: use REG_RMW and rmw buffer in ath9k_hw_4k_set_gain

On 2015-03-20 13:38, Oleksij Rempel wrote: it is possible to reduce time needed for this function by rplacing REG_WRITE with REG_RMW (plus dummy 0) and putt all commands in same buffer. Signed-off-by: Oleksij Rempel li...@rempel-privat.de --- drivers/net/wireless/ath/ath9k/eeprom_4k.c |

Re: [ath9k-devel] [PATCH] ath9k: Configure beacons for AP vif if this has not happened yet

. Cc: sta...@vger.kernel.org Signed-off-by: Felix Fietkau n...@openwrt.org --- drivers/net/wireless/ath/ath9k/beacon.c | 20 drivers/net/wireless/ath/ath9k/common.h | 2 +- 2 files changed, 13 insertions(+), 9 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/beacon.c b

Re: [ath9k-devel] [PATCHv2] ath9k_htc: add adaptive usb receive flow control to repair soft lockup with monitor mode

On 2015-02-10 11:34, Yuwei Zheng wrote: The ath9k_hif_usb_rx_cb function excute on the interrupt context, and ath9k_rx_tasklet excute on the soft irq context. In other words, the ath9k_hif_usb_rx_cb have more chance to excute than ath9k_rx_tasklet. So in the worst condition, the rx.rxbuf

Re: [ath9k-devel] strange MPDU loss pattern

Hi Seongho, that paper looks quite interesting. Are you planning to publish code/patches for your implementation as well? It would be nice to have dynamic A-MPDU limiting integrated in minstrel_ht. Thanks, - Felix On 26/10/2014 12:14 AM, Seongho Byeon wrote: Hi, I am Ph.d. student in Seoul

Re: [ath9k-devel] [Cerowrt-devel] periodic hang of ath9k

On 2014-07-14 06:25, Sujith Manoharan wrote: Dave Taht wrote: cc-ing ath9k-devel for this update on http://www.bufferbloat.net/issues/442 this bug, which some people (usually on macs with low signal strength) can get to occur fairly rapidly, but I can't, is driving me 9 kinds of crazy...

Re: [ath9k-devel] [RFCv2 09/10] ath9k: disable dynack algorithm when coverage class is set

On 2014-07-13 12:18, Lorenzo Bianconi wrote: Disable ack timeout estimation algorithm if the coverage class has been configured Signed-off-by: Lorenzo Bianconi lorenzo.biancon...@gmail.com I think this is broken, since it doesn't allow you to re-enable dynack through the same way as it was

Re: [ath9k-devel] [RFC 03/10] ath9k: add dynamic ack timeout estimation

On 2014-07-07 13:41, Thomas Hühn wrote: +{ +struct ath_node *an; +u32 to = 0; +struct ath_dynack *da = ah-dynack; +struct ath_common *common = ath9k_hw_common(ah); + +list_for_each_entry(an, da-nodes, list) +if (an-ackto to) +to =

Re: [ath9k-devel] [PATCH] ath9k: fix NULL-deref in hw_per_calibration() for ar9002

On 2014-05-07 21:54, John W. Linville wrote: On Wed, May 07, 2014 at 09:22:58AM +0200, David Herrmann wrote: ah-caldata may be NULL if no channel is selected. Check for that before accessing it. Signed-off-by: David Herrmann dh.herrm...@gmail.com --- Hi This is _definitely_ only a

Re: [ath9k-devel] [PATCH 2/2] ath9k: add a recv budget

On 2014-04-29 14:04, Tim Harvey wrote: On Tue, Apr 22, 2014 at 2:09 AM, Felix Fietkau n...@openwrt.org wrote: On 2014-04-22 01:14, Tim Harvey wrote: Implement a recv budget so that in cases of high traffic we still allow other taskets to get processed. Without this, we can encounter a host

Re: [ath9k-devel] extreme latency, regression in 3.13.7

the correct TID if we are processing a data frame. Furthermore, prevent non-data frames to get a sequence number from a TID sequence counter by adding a check to ath_tx_setup_buffer. Cc: Felix Fietkau n...@openwrt.org Signed-off-by: Helmut Schaa helmut.sc...@googlemail.com

Re: [ath9k-devel] [PATCH] ath9k: Prevent divide by zero kernel crash.

On 2014-04-17 02:40, gree...@candelatech.com wrote: From: Ben Greear gree...@candelatech.com Make sure we cannot ever assign beacon interval to zero. Signed-off-by: Ben Greear gree...@candelatech.com --- drivers/net/wireless/ath/ath9k/beacon.c | 4

Re: [ath9k-devel] [RFC] ath9k: use more than one slot per bss for multicast in staggered mode

On 2014-03-10 15:40, Michael Braun wrote: Before, ath9k divided time in ATH_BCBUF many equally sized slots. Each bss then was assigned to a single slot, leaving some or more slots empty. The beacons of a bss were sent at the beginning of the slot for this bss, and then the buffered multicast

Re: [ath9k-devel] Slow connection when using eduroam (AR9285)

On 2014-02-23 20:44, Marco André Dinis wrote: Hi I started downloding a file and this is the output from ''dmesg'' (less than 30 sec) [ 167.654939] wlp5s0: associated [ 167.654953] IPv6: ADDRCONF(NETDEV_CHANGE): wlp5s0: link becomes ready [ 174.900658] net_ratelimit: 47 callbacks

Re: [ath9k-devel] [PATCH] ath9k: Fix ETSI compliance for AR9462 2.0

On 2014-02-17 03:27, Sujith Manoharan wrote: Felix Fietkau wrote: Wouldn't it be better to do this for all AR93xx chipsets in ar9003_hw_apply_minccapwr_thresh instead of initvals? I'm pretty sure this patch will leave most other devices non-compliant. The threshold values are adjusted

Re: [ath9k-devel] Interrupt mitigation for USB Atheros dongles

On 2014-02-14 02:45, Dimosthenis Pediaditakis wrote: Hi all, I am using a capacity and available bandwidth measurement software that compute estimates based on the gaps among packet trains/pairs. For that reason I need to disable RX/TX interrupt mitigation for the devices that I take the

Re: [ath9k-devel] [PATCH] ath9k: Fix ETSI compliance for AR9462 2.0

On 2014-02-14 03:45, Sujith Manoharan wrote: From: Sujith Manoharan c_man...@qca.qualcomm.com The minimum CCA power threshold values have to be adjusted for existing cards to be in compliance with new regulations. Newer cards will make use of the values obtained from EEPROM, support for

Re: [ath9k-devel] [PATCH 05/13] ath9k_htc: add rx header converter to make it usable by ath9k

On 2014-02-03 12:22, Oleksij Rempel wrote: Am 03.02.2014 03:09, schrieb Sujith Manoharan: Oleksij Rempel wrote: + rx_stats = kzalloc(sizeof(struct ath_rx_status), GFP_KERNEL); + if (unlikely(rx_stats == NULL)) { + ath_err(common, rx_stats allocation filed!\n); + goto

Re: [ath9k-devel] [PATCH] ath9k: Fix uninitialized variable in ath9k_has_tx_pending()

(ath9k: optimize ath9k_flush). Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org Acked-by: Felix Fietkau n...@openwrt.org ___ 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

On 2013-12-13 10:48, Sebastian Moeller wrote: Hi Sujith, On Dec 13, 2013, at 10:27 , Sujith Manoharan suj...@msujith.org 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

Re: [ath9k-devel] [OpenWrt-Devel] ath9k (ad-hoc?) problems in compat-wireless trunk as of sept 6/2

On 2013-09-09 1:29 PM, Nicolás Echániz wrote: I have kept testing this and was able to reproduce the same problem every time. The performance perception when the network is at rush hour is very unstable so I tried to reproduce traffic conditions during late night. I sent multiple netperfs

Re: [ath9k-devel] [PATCH 2/2] ath9k: Run the LNA combining algorithm properly

On 2013-08-07 8:59 AM, Sujith Manoharan wrote: From: Sujith Manoharan c_man...@qca.qualcomm.com The LNA combining algorithm has to be run for cards that support the required diversity features, make sure that that correct conditions are met before enabing this algorithm. Signed-off-by:

Re: [ath9k-devel] ath9k AR9380 packets take long to be sent

On 2013-08-06 6:04 PM, Michael Braun wrote: On Tue, Aug 06, 2013 at 01:18:51PM +0200, Michael Braun wrote: Also, can you please test with the latest one (I just committed some more fixes). those have been running for for some hours and I could not reproduce the problem anymore,

Re: [ath9k-devel] sensitivity control for ath9k with mac80211

On 2013-07-19 4:58 PM, Sergey Ryazanov wrote: 2013/7/19 Ben Greear gree...@candelatech.com: On 07/19/2013 06:36 AM, Flavio Leonel wrote: Ok i know that but the command iw not permited set sensitivity limit how i can seting this limit on atth9k , this question.. I tried messing with this

Re: [ath9k-devel] AR9331 ath9k driver init fails when using mtd

On 2013-07-16 2:46 PM, Gerrit van der Bij wrote: Hi, I have a small project where I used a 32 Mbyte flash in a TP-Link MR-11U running OpenWrt AA. The device is based on the AR9331 chip. The kernel disables the SPI interface of the AR9331, so the flash is no longer memory mapped. To

Re: [ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

On 2013-07-09 10:50 AM, Oleksij Rempel wrote: How replacing AP with about MESH or AdHock+BATMAN? Why? That sounds like a recipe for disaster to me (at least for conference networks). The ath9k_htc stuff can't handle more peers in mesh/ad-hoc than clients in AP mode. In setting up a conference

Re: [ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA

On 2013-07-09 11:34 AM, Oleksij Rempel wrote: Am 09.07.2013 11:18, schrieb Felix Fietkau: On 2013-07-09 10:50 AM, Oleksij Rempel wrote: How replacing AP with about MESH or AdHock+BATMAN? Why? That sounds like a recipe for disaster to me (at least for conference networks). The ath9k_htc stuff

Re: [ath9k-devel] performance with ath9k, sparklan WPEA-127N, and Macbook pro

On 2013-06-20 6:05 PM, Adam Allred wrote: Hello, I am attempting to build an AP that can support airplay streaming between various mac devices. My current test bed is as follows: Macbook Pro 10,2 (13 Retina), with an Airport Extreme (0x14E4, 0x10F) card, which is using the BCM43xx driver

Re: [ath9k-devel] performance with ath9k, sparklan WPEA-127N, and Macbook pro

On 2013-06-20 6:49 PM, Adam Allred wrote: I picked it up off of http://ubuntuforums.org/showthread.php?t=1746326 and only tried it after I had a working connection, just to see if it would make a difference, since it's ubuntu and a AR92xx series card in that post. Performance is the same

Re: [ath9k-devel] Is there a way to connect pairs of wifi cards to achieve full duplex

On 2013-06-20 12:26 PM, David Goodenough wrote: On Wednesday 19 Jun 2013, Ben Greear wrote: On 06/19/2013 03:56 PM, Adrian Chadd wrote: .. just keep in mind that adjacent high power transmitters can actually leak enough RF to trigger ADC saturation and thus the device may actually not try

Re: [ath9k-devel] Is there a way to connect pairs of wifi cards to achieve full duplex

On 2013-06-20 8:13 PM, David Goodenough wrote: On Thursday 20 Jun 2013, Felix Fietkau wrote: On 2013-06-20 12:26 PM, David Goodenough wrote: On Wednesday 19 Jun 2013, Ben Greear wrote: On 06/19/2013 03:56 PM, Adrian Chadd wrote: .. just keep in mind that adjacent high power transmitters

Re: [ath9k-devel] Disable BAW sliding

On 2013-06-14 3:51 PM, shinnazar wrote: Hi all, Is there anybody who worked on BAW(Block Ack Window) sliding mechanism in ath9k? Is it possible to disable this mechanism? What would you want to do that for? It seems to me that all this would accomplish is to get the tx path stuck after a

Re: [ath9k-devel] [PATCH] mac80211: Use RCU protection in ieee80211_get_tx_rates()

On 2013-06-12 10:00 AM, Calvin Owens wrote: Copying the rate table should be done in an RCU read-side critical section. I think this approach is wrong. The sta entry is also under RCU protection (no locking for read access in that part of the code. In a normal driver tx path, no extra

Re: [ath9k-devel] [PATCH 7/7] ath10k: detect htt pending tx limit at runtime

On 2013-05-16 11:09 AM, Michal Kazior wrote: The real limit for sending htt tx is either msdu_id storage type (u16 - 65536 different values) or the HIF tx pipe queue length (2047 in case of our PCI HIF). The htt tx pipe does not use interrupts - it must be polled. It is polled either on RX

Re: [ath9k-devel] minstrel_ht: problems with HT40

On 2013-05-09 3:42 PM, Oleksij Rempel wrote: Hallo Felix, i found your patches for moving ath9k to minstrel_ht and decided to do some testing. For some reason, minstrel_ht exclude all HT40 rates in my network. With native ath9k rate controller I'm able to use HT40. Do you have any idea

Re: [ath9k-devel] minstrel_ht: problems with HT40

On 2013-05-09 5:09 PM, Oleksij Rempel wrote: Am 09.05.2013 16:41, schrieb Felix Fietkau: On 2013-05-09 3:42 PM, Oleksij Rempel wrote: Hallo Felix, i found your patches for moving ath9k to minstrel_ht and decided to do some testing. For some reason, minstrel_ht exclude all HT40 rates in my

Re: [ath9k-devel] AR9380 frequent disconnect and stucks in AP mode.

On 2013-05-07 2:03 PM, Bhavesh Kamani wrote: Hi Ben, I tried compat-drivers-3.9-rc4-2-su, then also same problem I faced. I also tried compat-wireless-2.6.39-1 and compat-wireless-3.6.8-1, but facing the same issue. In a day more than one clients are facing the same issue. In the

Re: [ath9k-devel] [PATCH 1/2] ath9k_htc: add STBC TX support

On 2013-05-04 8:50 AM, Oleksij Rempel wrote: Am 02.05.2013 22:15, schrieb Adrian Chadd: Well, let's dig into the firmware a bit more and tidy up how STBC is handled. Does it mean, i should change this patch and provide a patch for firmware too? I still do not think, changing peer caps i a

Re: [ath9k-devel] [PATCH 1/2] ath9k_htc: add STBC TX support

On 2013-05-04 1:08 PM, Oleksij Rempel wrote: Am 04.05.2013 12:02, schrieb Felix Fietkau: On 2013-05-04 8:50 AM, Oleksij Rempel wrote: Am 02.05.2013 22:15, schrieb Adrian Chadd: Well, let's dig into the firmware a bit more and tidy up how STBC is handled. Does it mean, i should change

Re: [ath9k-devel] [PATCH 1/2] ath9k_htc: add STBC TX support

On 2013-05-02 7:32 PM, Oleksij Rempel wrote: Am 02.05.2013 18:55, schrieb Adrian Chadd: On 2 May 2013 01:11, Oleksij Rempel li...@rempel-privat.de wrote: +#define WLAN_RC_TX_STBC_FLAG 0x20 /* TX STBC */ +#define WLAN_RC_RX_STBC_FLAG 0xC0 /* RX STBC ,2 bits */ I thought we covered this; why

Re: [ath9k-devel] 3.9.0-rc8+ (hacked) splat.

On 2013-05-01 6:01 PM, Ben Greear wrote: On 04/30/2013 11:05 AM, Ben Greear wrote: On 04/28/2013 08:05 AM, Ben Greear wrote: On 04/27/2013 01:58 AM, Felix Fietkau wrote: On 2013-04-27 1:46 AM, Ben Greear wrote: Was running around 200 stations against a VAP on this system, and then changed

Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets

On 2013-04-27 5:25 PM, Oleksij Rempel wrote: Collect statistics about recived duplicate and STBC packets. This information should help see if STBC is actually working. Tested on ar9285; Signed-off-by: Oleksij Rempel li...@rempel-privat.de I thought about this patch some more, and I'm

Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets

On 2013-04-28 4:54 PM, Ben Greear wrote: On 04/28/2013 05:51 AM, Felix Fietkau wrote: On 2013-04-27 5:25 PM, Oleksij Rempel wrote: Collect statistics about recived duplicate and STBC packets. This information should help see if STBC is actually working. Tested on ar9285; Signed-off

Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets

On 2013-04-28 5:15 PM, Ben Greear wrote: On 04/28/2013 08:08 AM, Felix Fietkau wrote: On 2013-04-28 4:54 PM, Ben Greear wrote: On 04/28/2013 05:51 AM, Felix Fietkau wrote: On 2013-04-27 5:25 PM, Oleksij Rempel wrote: Collect statistics about recived duplicate and STBC packets

Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets

On 2013-04-28 9:19 PM, Oleksij Rempel wrote: Am 28.04.2013 17:03, schrieb Oleksij Rempel: Am 28.04.2013 16:13, schrieb Oleksij Rempel: Am 28.04.2013 14:51, schrieb Felix Fietkau: On 2013-04-27 5:25 PM, Oleksij Rempel wrote: Collect statistics about recived duplicate and STBC packets

Re: [ath9k-devel] 3.9.0-rc8+ (hacked) splat.

On 2013-04-27 1:46 AM, Ben Greear wrote: Was running around 200 stations against a VAP on this system, and then changed the channel from 1 to 36 (by restarting hostapd with new config). Looks like null-pointer de-ref... Anyone seen anything similar? I've never seen this one. Please use gdb

Re: [ath9k-devel] [PATCH v2] ath9k: collect statistics about Rx-Dup and Rx-STBC packets

On 2013-04-27 9:06 PM, Adrian Chadd wrote: On 27 April 2013 11:53, Oleksij Rempel li...@rempel-privat.de wrote: (And then go and re-align things inside that struct so you don't waste space.) hmm.. what do you mean here? Structure alignment? Well, you typically want to have everything be

Re: [ath9k-devel] [PATCH] ath9k: apply coverage class on slottime too

On 2013-04-22 12:08 PM, Simon Wunderlich wrote: Hey Felix, just wanted to bump on this issue again, as it has not been applied yet - the patch seems still valid, and Mathias results appear to show that as well. What do you think? Looks ok to me, let's get it merged. - Felix

Re: [ath9k-devel] ath9k-issue with stop RX/TX DMA - correlation with WMM traffic classes?

On 2013-04-12 10:27 AM, Rougu wrote: Hi everyone, while I might be totally wrong with my observation, I still would like to share it, because this issue is lingering for years now and many users are waiting to a solid grip on it to fix it. I'm running several freifunk-nodes in Cologne,

Re: [ath9k-devel] ath9k-issue with stop RX/TX DMA - correlation with WMM traffic classes?

On 2013-04-12 6:57 PM, Jan Lühr wrote: Hallo Felix, Am 12.04.2013 um 17:41 schrieb Felix Fietkau: On 2013-04-12 10:27 AM, Rougu wrote: while I might be totally wrong with my observation, I still would like to share it, because this issue is lingering for years now and many users

Re: [ath9k-devel] [RFC] ath9k: Respect current txpower setting

On 2013-04-11 1:20 AM, Adrian Chadd wrote: On 10 April 2013 15:03, Tobias Steinicke tobias.steini...@net.t-labs.tu-berlin.de wrote: In routine ath_tx_fill_desc(), the txpower is only set to MAX_RATE_POWER. Now it respects the txpower from bss_conf and set it if it is (txpower * 2)

Re: [ath9k-devel] [PATCH] ath9k: Re-enable interrupts after a channel change failure

On 2013-04-02 2:03 PM, Robert Shade wrote: On Mon, Apr 1, 2013 at 1:40 PM, Felix Fietkau n...@openwrt.org wrote: Your patch is badly whitespace damaged. Ouch, must be the gmail web client. I'll resubmit a fixed one. Why the call to ath9k_hw_set_interrupts here? Simply because that's

Re: [ath9k-devel] [PATCH] ath9k: Re-enable interrupts after a channel change failure

On 2013-04-01 4:22 PM, Robert Shade wrote: Re-enable interrupts after a channel change failure, since ath_complete_reset will not be called. Also schedule a reset as a best effort method to recover the chip from whatever state caused the channel change failure. Signed-off-by: Robert Shade

Re: [ath9k-devel] Fixing the rate and rate relationship to OFDM

On 2013-03-27 7:49 PM, John Clark wrote: Many people seem to desire the bit rate to be the 'highest possible', and have that automagically set. What's wrong with the current behavior of picking the rate that causes the least wasted airtime? For some applications, I like to be able to set a

Re: [ath9k-devel] WiFi Failure with AR9280

On 2013-03-24 5:26 PM, Pannirselvam Kanagaratnam wrote: Hello, My WiFi connection drops while running the AR9280 on a Freescale MPC8315E platform in AP mode with hostapd. I get the following error within 15 seconds and the WiFi connection drops. However, I do not observe any issues when

Re: [ath9k-devel] Questions in 802.11 n timestamps traces for aggregated frames ?

On 2013-03-16 9:19 PM, abhinav narain wrote: guess aggr of 1462 bytes ?), but why are those seq. numbers never re-used ? Your traces don't give you the full picture, because looking at this as a per-frame thing is wrong. If both IEEE80211_TX_CTL_AMPDU and

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

On 2013-03-12 7:16 PM, Ben Greear wrote: On 02/22/2013 04:55 AM, Ben Greear wrote: On 02/22/2013 04:38 AM, Felix Fietkau wrote: On 2013-02-22 1:25 PM, Sujith Manoharan wrote: Felix Fietkau wrote: Please also check if the station(s) that the frames are queued for are in powersave state

Re: [ath9k-devel] Questions in 802.11 n timestamps traces for aggregated frames ?

On 2013-03-13 12:48 AM, abhinav narain wrote: Hi Felix, Adrian, /* This packet was aggregated but doesn't carry status info */ if ((info-flags IEEE80211_TX_CTL_AMPDU) !(info-flags IEEE80211_TX_STAT_AMPDU)) return; Any packet with

Re: [ath9k-devel] Questions in 802.11 n timestamps traces for aggregated frames ?

On 2013-03-11 7:20 PM, abhinav narain wrote: Is this being recorded on transmit, or transmit completion? I'm guessing this is transmit completion on the transmit side. Is this information coming from the driver, or from some completion status going up to mac80211? Partly

Re: [ath9k-devel] [PATCH] ath9k: Allow over-riding reg-domain.

On 2013-03-11 8:51 PM, Ben Greear wrote: On 03/11/2013 12:05 PM, John W. Linville wrote: On Mon, Mar 11, 2013 at 09:45:06AM -0700, gree...@candelatech.com wrote: From: Ben Greear gree...@candelatech.com Otherwise, can't get the Sparklan AR9380 NICs to be 5Ghz APs, since they are in

Re: [ath9k-devel] [PATCH] ath9k: Allow over-riding reg-domain.

On 2013-03-11 10:01 PM, Ben Greear wrote: On 03/11/2013 01:17 PM, Felix Fietkau wrote: On 2013-03-11 8:51 PM, Ben Greear wrote: On 03/11/2013 12:05 PM, John W. Linville wrote: On Mon, Mar 11, 2013 at 09:45:06AM -0700, gree...@candelatech.com wrote: From: Ben Greear gree...@candelatech.com

Re: [ath9k-devel] [PATCH] ath9k: Allow over-riding reg-domain.

On 2013-03-11 10:44 PM, Ben Greear wrote: On 03/11/2013 02:36 PM, Felix Fietkau wrote: On 2013-03-11 10:01 PM, Ben Greear wrote: On 03/11/2013 01:17 PM, Felix Fietkau wrote: I am not sure what you are suggesting. I enabled this override only when ONUS is selected because I wanted it clear

Re: [ath9k-devel] [PATCH] ath9k: Allow over-riding reg-domain.

On 2013-03-11 11:00 PM, Ben Greear wrote: On 03/11/2013 02:51 PM, Felix Fietkau wrote: On 2013-03-11 10:44 PM, Ben Greear wrote: On 03/11/2013 02:36 PM, Felix Fietkau wrote: On 2013-03-11 10:01 PM, Ben Greear wrote: On 03/11/2013 01:17 PM, Felix Fietkau wrote: I am not sure what you

Re: [ath9k-devel] Enabling tx-power-per-vif in ath9k?

On 2013-03-04 11:28 PM, Ben Greear wrote: It seems there is some mac80211 framework for handling per VIF tx-power settings now, but from what I can tell, this is not supported in ath9k. Correct. Any idea how feasible it is to do per-vif tx-power in ath9k? I think it would come down to

Re: [ath9k-devel] ts_tstamp field in ath_tx_status is set

On 2013-02-27 9:58 AM, abhinav narain wrote: Thanks Felix, I think I wasn't clear in asking my question. Sorry about that, is it possible you can answer one below ? On Tue, Feb 26, 2013 at 6:03 PM, Felix Fietkau n...@openwrt.org mailto:n...@openwrt.org wrote: On 2013-02-26 7:51 PM

Re: [ath9k-devel] ts_tstamp field in ath_tx_status is set

On 2013-02-27 4:26 PM, abhinav narain wrote: As the timestamp of 4 frames are the same or or the sum of bytes of 4 frames is 1542 bytes as the descriptor gives 1542 ? I thought ampdu 1500 bytes (4K or 8K) Is it because frames are split up ( before ath_tx_complete_buf()) on

Re: [ath9k-devel] ts_tstamp field in ath_tx_status is set

On 2013-02-26 7:51 PM, abhinav narain wrote: Thanks for the response, Felix ! I have some questions to ask : (1) So I should interpret the ath_tx_status descriptor as : 14 retransmissions occurred while transmission of 1542*4 bytes. Its not 14*4 retransmissions. Aggregates are formed by the

Re: [ath9k-devel] ts_tstamp field in ath_tx_status is set

On 2013-02-25 9:53 PM, abhinav narain wrote: You are right in that case, Adrian. *tsf ,retx count, rates and transmit attempts, sequence no, frame size* *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 706,1542]* *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 707,1542]* *[315063930,

Re: [ath9k-devel] [RFT] ath9k_htc - please test new images

On 2013-02-23 9:13 PM, Oleksij Rempel wrote: Am 23.02.2013 12:41, schrieb Adrian Chadd: On 23 February 2013 01:54, Oleksij Rempel bug-tr...@fisher-privat.net wrote: Hi Adrian, current driver has this check: htc_drv_init.c: priv-fw_version_minor != MINOR_VERSION_REQ) { htc_drv_init.c:

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

On 2013-02-22 6:26 AM, Ben Greear wrote: 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

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

On 2013-02-22 1:25 PM, Sujith Manoharan wrote: Felix Fietkau wrote: Please also check if the station(s) that the frames are queued for are in powersave state for some reason. That would prevent the tx path from throwing them in the hw queue, yet they'd still take up pending-frame slots. I

Re: [ath9k-devel] [PATCH] ath9k_htc: update RSSI values only when the device is associated

On 2013-02-01 1:50 PM, Bernhard Urban wrote: add an if-guard, otherwise iw(8) reports weird signal strengths. The behaviour was fine before this commit: 7c277349ecbd66e19fad3d949fa6ef6c131a3b62 Therefore, this patch is a partially revert of it. I think your commit message is a bit

Re: [ath9k-devel] [RFC 3/3] ath9k: add spectral scan feature

On 2012-12-05 11:40 AM, Simon Wunderlich wrote: I suggest experimenting around with those particular parameters. You should be able to coax out specific numbers of spectral scan events when you set the COUNT parameter to something other than 8. But polling that bit isn't needed. It should be

Re: [ath9k-devel] ath9k_tasklet() can be interrupted by a hardware IRQ

On 2012-11-20 11:05 AM, Felix Liao wrote: Hi Felix F, I'm Felix Liao from WatchGuard, I think we should spin_lock_irqsave and spin_unlock_irqrestore on sc_pcu_lock in the ath9k_tasklet() instead of spin_lock/spin_unlock, just to avoid the tasklet being interrupted by the hardware IRQ, do

Re: [ath9k-devel] [PATCH] ath9k_htc: update RSSI values only when the device is associated

On 2012-11-09 6:09 PM, Bernhard Urban wrote: add an if-guard, otherwise iw(8) reports weird signal strengths. The behaviour was fine before this commit: 7c277349ecbd66e19fad3d949fa6ef6c131a3b62 This patch is therefore a partially revert of it. Tested with TP-Link TL-WN722N Thanks to

Re: [ath9k-devel] [PATCH] ath9k: [DFS] add pulse width tolerance for ETSI

On 2012-10-31 2:32 PM, Hauke Mehrtens wrote: On 10/31/2012 12:23 PM, Zefir Kurtisi wrote: Add 5% width tolerance for radar patterns defined by ETSI. Signed-off-by: Zefir Kurtisi zefir.kurt...@neratec.com --- .../net/wireless/ath/ath9k/dfs_pattern_detector.c |7 ++- 1 files

Re: [ath9k-devel] [PATCH] ath9k: apply coverage class on slottime too

On 2012-10-30 1:07 PM, Simon Wunderlich wrote: From: Mathias Kretschmer mathias.kretsch...@fokus.fraunhofer.de According to 802.11-2007 17.3.8.6 (slot time), the slot time should be increased by 3 us * coverage class. The code only increased the ack timeout, which is fixed by this patch.

Re: [ath9k-devel] [PATCH] ath9k: apply coverage class on slottime too

On 2012-10-30 2:00 PM, Mathias Kretschmer wrote: On 10/30/2012 01:43 PM, Felix Fietkau wrote: On 2012-10-30 1:07 PM, Simon Wunderlich wrote: From: Mathias Kretschmer mathias.kretsch...@fokus.fraunhofer.de According to 802.11-2007 17.3.8.6 (slot time), the slot time should be increased by 3

Re: [ath9k-devel] [PATCH] ath9k: Test for TID only in BlockAcks while checking tx status

Signed-off-by: Simon Wunderlich s...@hrz.tu-chemnitz.de Nice catch, thanks! Acked-by: Felix Fietkau n...@openwrt.org ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Test for TID only in BlockAcks while checking tx status

On 2012-10-29 1:34 PM, Felix Fietkau wrote: On 2012-10-29 1:25 PM, Sven Eckelmann wrote: The ath9k xmit functions for AMPDUs can send frames as non-aggregate in case only one frame is currently available. The client will then answer using a normal Ack instead of a BlockAck

  1   2   3   >