On 2016-10-05 22:31, Rob Herring wrote:
> On Wed, Oct 5, 2016 at 1:36 PM, Felix Fietkau wrote:
>> 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
>>
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
>>> devicetree authors need to override the enabled bands.
>>>
On 2016-07-08 18:28, Toke Høiland-Jørgensen wrote:
> Felix Fietkau writes:
>
>> On 2016-07-08 17:53, Toke Høiland-Jørgensen wrote:
>>> Kalle Valo writes:
>>>
>>>> Toke Høiland-Jørgensen wrote:
>>>>> This switches ath9k over to using th
s has been
>>> removed completely, as has the qlen limit tunables (since there's no
>>> longer a queue in the driver to limit).
>>>
>>> Based on Tim's original patch set, but reworked quite thoroughly.
>>>
>>> Cc: Tim Shepard
>&g
On 2016-07-06 20:52, Toke Høiland-Jørgensen wrote:
> Felix Fietkau 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 packets. It removes the
limit).
>
> Based on Tim's original patch set, but reworked quite thoroughly.
>
> Cc: Tim Shepard
> Cc: Felix Fietkau
> Signed-off-by: Toke Høiland-Jørgensen
> ---
> Changes since v1:
> - Remove the old intermediate queueing logic completely instead of
>
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.
>>
>> But I'm not sure if
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 name of the file which con
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
>
> drivers/net/wireless/ath/ath.h | 2 ++
> drivers/net/wireless/
On 2016-06-17 15:48, Felix Fietkau wrote:
> On 2016-06-17 15:43, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau 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
&
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 +145,
On 2016-06-17 15:43, Toke Høiland-Jørgensen wrote:
> Felix Fietkau 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 driver to
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 mac802
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 a/drivers/net/wireless/ath/ath9k/main.c
> b/drivers/net/wireless/ath/ath9k
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
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
>
> Fix this by using the available IS_CHAN_HALF_RATE and IS_CHAN_QUARTER_RATE
> marcros instead.
>
> Signed-off-by: Helmut Schaa
> Cc: Felix Fietkau
> ---
> Just stumbled over that piece of code while looking into TX99, so
> this is only compile-tested.
>
>
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 mac8021
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
> ---
> @Felix, Sujith could you review? I am not su
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
>> We
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
We already have base functionality for AR5008-AR9002 provided in some
ar5008_phy.c, and ar5008_hw_attach_phy_ops is called for those chipsets
as well. P
On 2015-03-20 13:38, Oleksij Rempel wrote:
> Signed-off-by: Oleksij Rempel
> ---
> 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
> b/drivers/net/wireless/ath/a
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
> ---
> drivers/net/wireless/ath/ath9k/eeprom_4k.c | 18 ++
conf->enable_beacon to a
bitmask of enabled beacon slots.
Cc: sta...@vger.kernel.org
Signed-off-by: Felix Fietkau
---
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
On 2015-02-25 07:14, Jouni Malinen wrote:
> On Tue, Feb 24, 2015 at 06:54:47PM +0100, Thomas Hühn wrote:
>> Currently Minstrel_HT just skips EAPOL packets for its rate sampling on
>> non-mrr chips by testing: (info->control.flags &
>> IEEE80211_TX_CTRL_PORT_CTRL_PROTO)
>
> Yeah, I noticed that w
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.r
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
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
>> c
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
I think this is broken, since it doesn't allow you to re-enable dynack
through the same way as it was disabled.
I would recommend
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)
>> +
On 2014-05-12 19:49, John W. Linville wrote:
> On Wed, May 07, 2014 at 10:15:53PM +0200, Felix Fietkau wrote:
>> 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 ch
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
>> ---
>> Hi
>>
>> This is _definitely_ only a workaroun
On 2014-04-29 14:04, Tim Harvey wrote:
> On Tue, Apr 22, 2014 at 2:09 AM, Felix Fietkau 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.
>
can lead to instable connections.
To fix this only select 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
Signed-off-by
On 2014-04-17 02:40, gree...@candelatech.com wrote:
> From: Ben Greear
>
> Make sure we cannot ever assign beacon interval to zero.
>
> Signed-off-by: Ben Greear
> ---
> drivers/net/wireless/ath/ath9k/beacon.c | 4
> drivers/net/wireless/ath/ath9k/recv.c | 3 ++-
> 2 files changed, 6 in
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 multicas
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 callbac
On 2014-02-23 04:08, Marco André Dinis wrote:
> (After some hours :D ) I found the first bad commit
>
>
> ➜ wireless-testing $ git bisect good
>
> 723e711356b5a8a95728a890e254e8b0d47b55cf is the first bad commit
> commit 723e711356b5a8a95728a890e254e8b0d47b55c
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
On 2014-02-14 03:45, Sujith Manoharan wrote:
> From: Sujith Manoharan
>
> 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 this was added earlier.
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 t
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");
>>> +
duced by commit 10e2318103f5941aa70c318afe34bc41f1b98529 ("ath9k:
> optimize ath9k_flush").
>
> Signed-off-by: Geert Uytterhoeven
Acked-by: Felix Fietkau
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
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 w
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 netper
On 2013-08-07 8:59 AM, Sujith Manoharan wrote:
> From: Sujith Manoharan
>
> 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: Sujith Manoharan
>
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 anymo
On 2013-08-06 12:36 PM, Felix Fietkau wrote:
> On 2013-08-06 10:52 AM, Michael Braun wrote:
>> Hi,
>>
>> I've upgraded my OpenWRT based AP firmware from kernel 3.8 to kernel
>> 3.10.5 with compat-wireless 2013-06-27.
>> Since then I started to notice
On 2013-08-06 10:52 AM, Michael Braun wrote:
> Hi,
>
> I've upgraded my OpenWRT based AP firmware from kernel 3.8 to kernel
> 3.10.5 with compat-wireless 2013-06-27.
> Since then I started to notice that some packets take very long to be
> actually sent from AP to STA.
Which specific OpenWrt rev
On 2013-07-19 4:58 PM, Sergey Ryazanov wrote:
> 2013/7/19 Ben Greear :
>> 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 some months
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.
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
>
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 net
On 2013-06-21 5:41 PM, Adam Allred wrote:
> I think it's already on in the debian 3.9 kernel .config
> (CONFIG_MAC80211_DEBUGFS=y), and I do not see a parameter to turn it
> on via modinfo.
>
> Sorry to run down the rabbit hole...
Maybe you need CONFIG_CFG80211_DEBUGFS=y as well.
There's no runtim
On 2013-06-21 4:09 PM, Adam Allred wrote:
>> I cannot go lower than the phy0 directory in that path when setting a
>> debug mode in the modprobe conf file, I assume its because the driver
>> isn't compiled with debugging symbols. I'll re-compile tomorrow and
>> post the contents of rc_stats.
>
> S
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:
>> >> >
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 actual
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
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
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 n
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 rcu_read_
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 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.
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
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.
>
> I
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
&g
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 cap
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 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 are you
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 2
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:
>>>>> Collec
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 statis
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 workin
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
I thought about this patch some more, and I'm wondering what's the p
On 2013-04-27 9:06 PM, Adrian Chadd wrote:
> On 27 April 2013 11:53, Oleksij Rempel 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
> dwor
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
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
___
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
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 Col
On 2013-04-11 1:20 AM, Adrian Chadd wrote:
> On 10 April 2013 15:03, Tobias Steinicke
> 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) < MAX_RATE_POWER else set to MAX_RATE_POWER.
On 2013-04-02 2:03 PM, Robert Shade wrote:
> On Mon, Apr 1, 2013 at 1:40 PM, Felix Fietkau 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?
&g
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 S
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 s
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
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 IEEE80
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
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 wit
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
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
>>&g
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
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
>>>
>>> Otherwise, can't get the Sparklan AR9380 NICs to be
>>> 5Ghz APs, since they are in world-roaming doma
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?
>
>
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 put
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_
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 <mailto:n...@openwrt.org>> wrote:
>
>
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 b
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]*
> *[3150639
On 2013-02-23 10:05 PM, Adrian Chadd wrote:
> On 23 February 2013 12:47, Felix Fietkau wrote:
>
>>> - I use 3.8.0-rc7 from wireless-testing.git for testing.
>>> - htc_7010.fw is working.
>>> - htc_9271.fw do not working. it fails on authentication:
>&g
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
>> wrote:
>>>
>>> Hi Adrian,
>>>
>>> current driver has this check:
>>> htc_drv_init.c: priv->fw_version_minor != MINOR_VERSION_REQ) {
>>> htc_drv_init.c:
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 s
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 diagnos
1 - 100 of 302 matches
Mail list logo
